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 : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
