On Tue, Jun 05, 2012 at 12:36:04AM +0200, Michael Weber wrote:
> On 06/04/2012 03:25 PM, Brian Harring wrote:
> > While I do grok the potential issue of someone being a hog
> > (specifically via blasting commit by commit rather than building up
> > work locally, then pushing it in chunks), frankly... I'm not that
> > concerned about it, and would rather deal w/ it if/when it occurs.
> > The nature of our commits for the most part are standalone from
> > others- that's not true of the kernel/mozilla, thus why I don't
> > think their issues are necessarily ours.
> We already have maintainers and herds as responsible (sole editors)
> entities for locations (packages).
> But, we have arch teams editing ebuild/KEYWORDS, which alters
> Manifest/EBUILD lines. Resulting in potential clashes (not
> fast-forwardable), if the herd or maintainer does bumps or cleanups.
> Will these Manifest lines (and the arch team inflicted Manifest changes)?
Converting to git, we'll switch over to thin manifests- they're *just*
the checksums for the distfiles, no need for the rest since git
already provides that verification implicitly.
That just leaves conflict w/in ebuilds, which is a valid "the dev
needs to deal with this themselves" scenario imo.
> According to robbat2 data (gentoo-commit tarball) we have ~400k
> commits in gentoo-x86 (w/o proj,xml) in 4.7 years, that's 6.2 per hour
> But I've to look into the data to see trends (# developers, daylight).
One thing to note- that's *individual* commits, and probably a mildly
jacked up number due to the double tap requirement of commiting
manifests to CVS.
What I'm driving at is that there's a difference between
commits/revisions, and pushs; I expect our push rate to be less; I'd
be surprised if we're doing 1:1 commit/push rate. The conflict rate
should be less painful for people in that light, or at least has been
in my experience thus far.
Btw, good catch on package.mask. Hhadn't thought of that, that
*will* be the most contentious point. That can be dealt w/ via
having git on portage-1 profile format so we'd have package.mask as
directories (which Ciaran will validly hate, and I won't like
due to having to write the portage-1 -> PMS translater for
rsync distribution), or coming up w/ a different way to split the
commits across multiple files, rather than a single.
That's assuming package.mask becomes a significant conflict point
also. Frankly I'd rather deal w/ that problem when it arrises, rather
than trying to optimize for it now.