Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Brian Harring <ferringb@...>
Subject: Re: Git braindump: 2 of N: developer interaction (merge co-ordinators)
Date: Mon, 4 Jun 2012 15:57:53 -0700
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


Replies:
Re: Git braindump: 2 of N: developer interaction (merge co-ordinators)
-- Michał Górny
References:
Git braindump: 2 of N: developer interaction (merge co-ordinators)
-- Robin H. Johnson
Re: Git braindump: 2 of N: developer interaction (merge co-ordinators)
-- Kent Fredric
Re: Git braindump: 2 of N: developer interaction (merge co-ordinators)
-- Brian Harring
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Git braindump: 2 of N: developer interaction (merge co-ordinators)
Next by thread:
Re: Git braindump: 2 of N: developer interaction (merge co-ordinators)
Previous by date:
About forcing rebuilds of other packages issue
Next by date:
Re: Re: metadata/md5-cache


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.