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
