1 |
On Sun, Jun 3, 2012 at 11:46 AM, Robin H. Johnson <robbat2@g.o> wrote: |
2 |
> A hierarchy of merge lieutenants: |
3 |
> - This is basically the Linux kernel model. The ability to merge into |
4 |
> master resides with a single person, and he pulls from other known |
5 |
> specified developers, who serve to collect and fix conflicts as needed |
6 |
> from the general developer population. |
7 |
> A merge co-ordinators that switches with time. |
8 |
> - This resembles the model used by Mozilla. |
9 |
> - Switches on a time basis; is generally some developer with a fast |
10 |
> internet connection. |
11 |
> - Responsible for taking pull requests, merging, fixing conflicts or |
12 |
> punting back, and pushing to the master branch. |
13 |
|
14 |
I think the current Mozilla situation isn't really covered here. As I |
15 |
understand it, they use a model that's kind of in between "merge |
16 |
lieutenant" and "merge co-ordinator". They have integration and |
17 |
project branches, where basic commits first land. Then those branches |
18 |
are generally merged into mozilla-central by any team member for that |
19 |
branch. |
20 |
|
21 |
But IMO, discussing this now is a kind of premature optimization. We |
22 |
should try to just do the simple thing (everyone commits to the main |
23 |
tree), and if there are too many push races we can re-evaluate the |
24 |
issue. It might make sense for projects/herd that already do a lot of |
25 |
work in an overlay to switch to using a branch which they could then |
26 |
merge at once, of course. |
27 |
|
28 |
Cheers, |
29 |
|
30 |
Dirkjan |