[gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Robin H. Johnson]

Developer Interaction model with Git
------------------------------------
Aka, why merge lieutenants or co-ordinators might be useful

This is amongst the potential problems I see might pop up.

We have two developers, let's call them Alice & Bob.

Alice has a nice fast internet connection, 10Mbit upstream.
Bob has a really sucky internet connection, 128Kbit upstream.

Alice is doing this set of commands, as she has a fast connection:
- (work on an ebuild)
- repoman commit
- git pull (implicit merge)
- git push

Bob is doing this, as he has a slow intermittent connection
- (work on an ebuild)
- repoman commit
- loop the above many times
- git pull (implicit merge)
- fix conflicts as needed
- git push

If there are enough "Alice" developers, is it a possibility that Bob
will never have a chance to get his commit in?

All this requires, is that in the time it takes Bob to do 'git pull',
Alice manages to do 'git push' again.

Alice can thus deprive Bob of a fair chance to get his commit in.
Bob becomes an unhappy developer and gives up.

Is this a realistic problem you ask? As recently as one or two years
ago, we still have developers on 56K or worse modems at home.

A variant of the above problem also happens as the number of developers
grows, you're almost always out of date trying to push to a single
branch if it's moving fast enough.

If this does happen, what can we do about it?

We have two options:
Both of them imply that each developer will have a private branch,
dev/$FOO, that only they are able to commit into.

A hierarchy of merge lieutenants:
- This is basically the Linux kernel model. The ability to merge into
  master resides with a single person, and he pulls from other known
  specified developers, who serve to collect and fix conflicts as needed
  from the general developer population.
A merge co-ordinators that switches with time.
- This resembles the model used by Mozilla.
- Switches on a time basis; is generally some developer with a fast
  internet connection.
- Responsible for taking pull requests, merging, fixing conflicts or
  punting back, and pushing to the master branch.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1043 bytes --]

Am Sonntag 03 Juni 2012, 11:46:16 schrieb Robin H. Johnson:

> If there are enough "Alice" developers, is it a possibility that Bob
> will never have a chance to get his commit in?
> 
> All this requires, is that in the time it takes Bob to do 'git pull',
> Alice manages to do 'git push' again.

We definitely have to take care of this somehow. 

However, it would be nice to have some numbers to estimate how acute the 
problem will be. As I'm definitely not a CVS guru, what's the best way to 
extract commit times to the gentoo-x86 tree? 

(
What I'd ask for is as "raw data" - take all commits (say, for the last year), 
filter out Manifest-only stuff, make a text file with only the timestamps for 
each commit, ideally one per line and already in "seconds in epoch" format...

This, being pretty similar to whatever comes out in our labs, could then be 
postprocessed and visualized... :)
)

Cheers, Andreas

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Robin H. Johnson]

On Sun, Jun 03, 2012 at 12:22:01PM +0200, Andreas K. Huettel wrote:
> Am Sonntag 03 Juni 2012, 11:46:16 schrieb Robin H. Johnson:
> > If there are enough "Alice" developers, is it a possibility that Bob
> > will never have a chance to get his commit in?
> > 
> > All this requires, is that in the time it takes Bob to do 'git pull',
> > Alice manages to do 'git push' again.
> We definitely have to take care of this somehow. 
> 
> However, it would be nice to have some numbers to estimate how acute the 
> problem will be. As I'm definitely not a CVS guru, what's the best way to 
> extract commit times to the gentoo-x86 tree? 
dev.g.o:/space/temp/gentoo-commits-20120602T221900Z.tar.bz2

Grab that file, it covers approximate 150M seconds of commit history of
Gentoo.

Don't distribute to non-developers please, email addresses are NOT
obfuscated.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Michael Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/03/2012 12:22 PM, Andreas K. Huettel wrote:
> ( What I'd ask for is as "raw data" - take all commits (say, for
> the last year), filter out Manifest-only stuff, make a text file
> with only the timestamps for each commit, ideally one per line and
> already in "seconds in epoch" format...
> 
> This, being pretty similar to whatever comes out in our labs, could
> then be postprocessed and visualized... :) )
> 
> Cheers, Andreas
> 

robbat2 zipped gentoo-commits-ml for me to
dev.g.o:/space/temp/gentoo-commits-20120602T221900Z.tar.bz2

I'll take a look at the data this afternoon.

- -- 
- --
Gentoo Dev
http://xmw.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk/LPjIACgkQknrdDGLu8JDGCQD/dAoCqzzp2thApJtNyQ1EsSQl
AQx4OzTQ5Oy/iT9CSCMA/0j1YuuIXhouRRdbRHNYVhu0oBNbCVLOVGpDsHxRtRHB
=31xY
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Fabio Erculiani]

We may want to see if it's possible to make each ( pull & push )
transaction mutually exclusive one another (forcing repoman as git
wrapper and playing with git hooks? I don't know).
At first sight, it looks like a simple starvation problem, and there
are several anti-starvation protocols out there, the problem is if
these protocols can be applied to the git workflow.

Just brain-dumping...
-- 
Fabio Erculiani

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]

Robin H. Johnson schrieb:
> Developer Interaction model with Git
> ------------------------------------
> Aka, why merge lieutenants or co-ordinators might be useful
> 
> This is amongst the potential problems I see might pop up.
> 
> We have two developers, let's call them Alice & Bob.
> 
> Alice has a nice fast internet connection, 10Mbit upstream.
> Bob has a really sucky internet connection, 128Kbit upstream.
> 
> Alice is doing this set of commands, as she has a fast connection:
> - (work on an ebuild)
> - repoman commit
> - git pull (implicit merge)
> - git push
> 
> Bob is doing this, as he has a slow intermittent connection
> - (work on an ebuild)
> - repoman commit
> - loop the above many times
> - git pull (implicit merge)
> - fix conflicts as needed
> - git push
> 
> If there are enough "Alice" developers, is it a possibility that Bob
> will never have a chance to get his commit in?
> 
> All this requires, is that in the time it takes Bob to do 'git pull',
> Alice manages to do 'git push' again.
> 
> Alice can thus deprive Bob of a fair chance to get his commit in.
> Bob becomes an unhappy developer and gives up.
> 
> Is this a realistic problem you ask? As recently as one or two years
> ago, we still have developers on 56K or worse modems at home.

I have a slow upstream connection myself and still dont see any issues
with the workflow of alice from your example. It might be worse for a
56K modem like connection, but from my experience with sunrise (where we
already use git and use the workflow of Alice with our commit tool),
128kbit upstream with a faster downstream should be ok.
My guess would be, that this is more an issue for people, who do work on
the tree while being offline and who then have to resolve the conflicts,
when they get a connection again.

-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 380 bytes --]

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Dirkjan Ochtman]

On Sun, Jun 3, 2012 at 11:46 AM, Robin H. Johnson <robbat2@gentoo.org> wrote:
> A hierarchy of merge lieutenants:
> - This is basically the Linux kernel model. The ability to merge into
>  master resides with a single person, and he pulls from other known
>  specified developers, who serve to collect and fix conflicts as needed
>  from the general developer population.
> A merge co-ordinators that switches with time.
> - This resembles the model used by Mozilla.
> - Switches on a time basis; is generally some developer with a fast
>  internet connection.
> - Responsible for taking pull requests, merging, fixing conflicts or
>  punting back, and pushing to the master branch.

I think the current Mozilla situation isn't really covered here. As I
understand it, they use a model that's kind of in between "merge
lieutenant" and "merge co-ordinator". They have integration and
project branches, where basic commits first land. Then those branches
are generally merged into mozilla-central by any team member for that
branch.

But IMO, discussing this now is a kind of premature optimization. We
should try to just do the simple thing (everyone commits to the main
tree), and if there are too many push races we can re-evaluate the
issue. It might make sense for projects/herd that already do a lot of
work in an overlay to switch to using a branch which they could then
merge at once, of course.

Cheers,

Dirkjan

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Ulrich Mueller]

>>>>> On Sun, 3 Jun 2012, Dirkjan Ochtman wrote:

> But IMO, discussing this now is a kind of premature optimization.
> We should try to just do the simple thing (everyone commits to the
> main tree), and if there are too many push races we can re-evaluate
> the issue. [...]

And then what? Would returning to CVS be an option?

I for my part would be strongly opposed against a system that doesn't
allow individual devs to push to the tree, and that would involve
"merge lieutenants" or anything similar. So I think these issues must
be discussed before the transition, otherwise a situation could arise
where we were forced to switch to such a system for "technical
reasons".

Ulrich

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Robin H. Johnson]

On Sun, Jun 03, 2012 at 06:06:03PM +0200, Dirkjan Ochtman wrote:
> I think the current Mozilla situation isn't really covered here. 
Yes, I should have noted hybrids of the two models can easily exist.

> But IMO, discussing this now is a kind of premature optimization. 
agreed, it's NOT ideal. I evaluated it as what are the potential
problems i can foresee happening, that we haven't already discussed
and/or solved already.

I just wanted it to be noted before the migration does go live, so that
we're ahead of the planning if things DO go sour.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Dirkjan Ochtman]

On Sun, Jun 3, 2012 at 7:36 PM, Robin H. Johnson <robbat2@gentoo.org> wrote:
>> But IMO, discussing this now is a kind of premature optimization.
> agreed, it's NOT ideal. I evaluated it as what are the potential
> problems i can foresee happening, that we haven't already discussed
> and/or solved already.
>
> I just wanted it to be noted before the migration does go live, so that
> we're ahead of the planning if things DO go sour.

That makes a lot of sense. There are probably a bunch of
projects/teams where having their own branches makes some amount of
sense; but we should really try the free-for-all at first.

Cheers,

Dirkjan

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Rich Freeman]

On Sun, Jun 3, 2012 at 2:21 PM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> That makes a lot of sense. There are probably a bunch of
> projects/teams where having their own branches makes some amount of
> sense; but we should really try the free-for-all at first.

So, it sounds like we have a migrated tree already.  Why not just plan
a few days where we tell everybody to just mirror their work as an
experiment (it would be strongly encouraged but not mandatory if for
some reason a few can't go along with it).  So, devs would do their
work in cvs, and then just do the exact same commit in git and push
it.  The rsync mirrors would of course stay with cvs (this is just a
test).

Perhaps we might even make it a complete free-for-all with no rules at
first.  Then we can circle back on the list and discuss what did and
didn't work well.  That could include rebase-vs-merge, problems with
concurrency, and so on.

A test of some sort would cut down the risk of the unexpected when we
do the real migration.

Rich

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Kent Fredric]

On 3 June 2012 09:46, Robin H. Johnson <robbat2@gentoo.org> wrote:
 If there are enough "Alice" developers, is it a possibility that Bob
> will never have a chance to get his commit in?
>
> All this requires, is that in the time it takes Bob to do 'git pull',
> Alice manages to do 'git push' again.
>
> Alice can thus deprive Bob of a fair chance to get his commit in.
> Bob becomes an unhappy developer and gives up.

There's an easier solution here:

Bob pushes to a branch or to a public repo ( ie: github ) , and then
contacts Alice ( or somebody else ) who pulls their changes into the
tree on their behalf.

Its not "ideal" but better than nothing. And certainly better than
being stuck on SVN where this case is virtually guaranteed and with no
viable workarounds when it is encountered.



-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Dirkjan Ochtman]

On Sun, Jun 3, 2012 at 9:07 PM, Rich Freeman <rich0@gentoo.org> wrote:
> A test of some sort would cut down the risk of the unexpected when we
> do the real migration.

I understand the desire for this, but I don't think it will work. The
first few hours/days after the git migration are going to be painful
either way. If you run a test now, you'll get limited buy-in
(everyone's busy with other stuff), which would probably also be
rather biased (the most git/DVCS-averse devs are the least likely to
participate). You certainly won't be able to emulate the load of the
real tree.

IMO we should try to be cutting down barriers from the git migration,
not throwing up more. The process has taken long enough already; the
desire to control everything about the migration is part of why it's
taken so long. I lived through Mozilla's Mercurial migration, and it
was messy, too. That was probably worse, as there was less experience
with DVCS at the time, but it will still be messy.

Dirkjan

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Rich Freeman]

On Mon, Jun 4, 2012 at 2:48 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> IMO we should try to be cutting down barriers from the git migration,
> not throwing up more. The process has taken long enough already; the
> desire to control everything about the migration is part of why it's
> taken so long.

Fair enough.

We should also be asking ourselves what happens if something goes
really wrong and there are no commits for a whole two days.  I think
the answer is, not much.  As long as there are a few devs who can tend
to security issues or whatever I don't see it as an issue if we have
the odd glitch.

We do need to get the docs up so that we're at least somewhat
harmonized on conventions (authors vs committers, and so on).  Let's
not burn the first person to make a mistake at the stake either...

Rich

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Dirkjan Ochtman]

On Mon, Jun 4, 2012 at 2:38 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Mon, Jun 4, 2012 at 2:48 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
>> IMO we should try to be cutting down barriers from the git migration,
>> not throwing up more. The process has taken long enough already; the
>> desire to control everything about the migration is part of why it's
>> taken so long.
>
> Fair enough.
>
> We should also be asking ourselves what happens if something goes
> really wrong and there are no commits for a whole two days.  I think
> the answer is, not much.  As long as there are a few devs who can tend
> to security issues or whatever I don't see it as an issue if we have
> the odd glitch.

That's what I was thinking, too. :)

> We do need to get the docs up so that we're at least somewhat
> harmonized on conventions (authors vs committers, and so on).  Let's
> not burn the first person to make a mistake at the stake either...

Yeah, some initial tutorial of how to get going would probably help a
lot. For everything else, there's IRC (and hopefully most of what's
discussed there would soon find it's way into the HOWTO doc).

Cheers,

Dirkjan

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Brian Harring]

On Mon, Jun 04, 2012 at 03:49:31AM +0000, Kent Fredric wrote:
> On 3 June 2012 09:46, Robin H. Johnson <robbat2@gentoo.org> wrote:
>  If there are enough "Alice" developers, is it a possibility that Bob
> > will never have a chance to get his commit in?
> >
> > All this requires, is that in the time it takes Bob to do 'git pull',
> > Alice manages to do 'git push' again.
> >
> > Alice can thus deprive Bob of a fair chance to get his commit in.
> > Bob becomes an unhappy developer and gives up.
> 
> There's an easier solution here:
> 
> Bob pushes to a branch or to a public repo ( ie: github ) , and then
> contacts Alice ( or somebody else ) who pulls their changes into the
> tree on their behalf.
> 
> Its not "ideal" but better than nothing. And certainly better than
> being stuck on SVN where this case is virtually guaranteed and with no
> viable workarounds when it is encountered.


Kent, you did read Robin's email fully before commenting, right? ;)

You just proposed 'merge lieutenants', which Robin already covered in 
the originating email of this thread:
http://archives.gentoo.org/gentoo-dev/msg_f478e9cbb14feb01ad0771c5d24222c4.xml 


For the record, I'm against any form of merge lieutenant reliant on 
someone pulling shit in; automated (QA of some form) I'd be fine w/, 
although that's not simple machinery to slap into the proposals.

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.

~harring

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Michael Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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)?

And we have orphaned (maintainer-needed) and "everyone can fix it"
herds like desktop-*). This results in a large group of potential
bug-fixers (committers) and the potential of concurrent edits.
This can be managed by using bugzilla IN_PROGRESS as a lock state,
but I thats not very practicable/needs disciplin/is annoying.
But this is no regression compared to CVS, we just need to signal clashed.

Last assumed hot spot imho is package.mask with ~700 commits in the
last 4.5 months (one every 4.6 hours) and ~620 commits in
**/package.use.mask. Not that much.

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).

Michael


- --
Gentoo Dev
http://xmw.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk/NOFQACgkQknrdDGLu8JARlwEAldk7GAEqCrd5mSsDgC69e5uQ
aqivvwbDpNWSgfwJqwUA/jjlByEncXXPVia11BALSdDf1elrL/3qAf5ktCtxx/m0
=pJFc
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Brian Harring]

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

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Peter Stuge]

Brian Harring wrote:
> rather deal w/ that problem when it arrises, rather than trying to
> optimize for it now.

I'm strongly in favor of ripping off the bandaid, fast and hard!

Some hooks to block problematic pushes, and let people learn as
they go. It will take weeks to months for everyone to migrate,
if not their repos then at least their mindset. No amount of
preparation will reduce that significantly for all developers,
so too much preparation is just wasted effort.


//Peter

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

On Mon, 4 Jun 2012 15:57:53 -0700
Brian Harring <ferringb@gmail.com> wrote:

> 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 doesn't like a 'lesser evil' to me. I'd rather see those few
conflicts and fix them once in a while rather than having to lookup
multiple package.mask files with entries split in a semi-random manner.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Brian Harring]

On Tue, Jun 05, 2012 at 09:04:33AM +0200, Micha?? G??rny wrote:
> On Mon, 4 Jun 2012 15:57:53 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> 
> > 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 doesn't like a 'lesser evil' to me. I'd rather see those few
> conflicts and fix them once in a while rather than having to lookup
> multiple package.mask files with entries split in a semi-random manner.

The rate of package.mask commits was calculated yesterday- it's around 
4.5 a day.

Non issue, move along...
~harring