On 4/3/2013 4:31 PM, Kartikaya Gupta wrote:
The developer workflow I'm proposing requires there be a tree that is
allowed to have multiple heads. The "try" tree we have now satisfies
this requirement, so I'm using that in my proposal, but we could just
as easily use inbound or some other tree provided it accepts multiple
heads. The process for landing a patch from the developer's point of
view would look like this:
1. Take the latest green m-c change, commit your patch(es) on top of
it, and push it to try.
2. If your try push is green, flag it for eventual merge to m-c and
you're done.
3. If your try push is not green, update your patch(es) and go back to
step 1.
The "eventual merge" step would be resolved by the sheriffs picking up
green flagged heads from try and merging them into m-c. If the
resulting m-c is broken, the tree is closed until fixed (see Scenario
D below) but people can continue landing on try while this happens.
I think the relative merits of this approach is easily decidable by
looking at two numbers:
1. How many of our patch landings would have non-trivial merge conflicts?
2. How much patch bustage is caused by interaction failures instead of
patch author/reviewer negligence?
Note that your proposal makes both of these cases strictly worse: in the
first case, you force the tree sheriffs (instead of developers) to spend
more time resolving conflicts; in the second, sheriffs have to spend
more time finding the cause of the bustage. Keep in mind that we have
about three sheriffs and about a hundred developers--so it is better to
optimize for sheriffs' time instead of developers' time (at the very
least, developers represent better parallelization opportunities).
I don't know these numbers. I can estimate the first point by pointing
out that the JS developers stopped doing JS development on a project
branch because merges were too painful, which suggests that this would
be a nontrivial amount. The second point I have no reference basis (most
of my development is on comm-central), but if you presume that the patch
was developed and reviewed in good faith for not breaking things, then
it would suggest that this is not altogether rare.
For what it's worth, I do recall there being release engineering talk
about some sort of "autoland" feature (which would automatically land
any patch that passed try or something), and I recall (my memory may
just be playing tricks on me) that it got to the prototyping phase but
was shelved because the "merge" part was too difficult/impossible. A
comment from anyone who worked on this would be helpful.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
