| 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 |
Archives