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.
> True.
> 
> 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
> averaged.
> 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.

~harring