Sorry for starting a new thread, but I screwed up the previous thread by
mashing together my replies to unrelated messages in a single message.
If you didn't read all the messages in all sub-threads you may have
missed my response. Most of my responses were in this message:
https://groups.google.com/d/msg/mozilla.dev.platform/9f3IVMp0KDs/mSfvnkkSDyEJ
That being said, I would like to update the proposal to take into
account some of the comments and suggestions made.
One modification is to explicitly request that developers, when pushing
to try, use trychooser syntax to specify which set of tests they would
like to be run. This should address the increased load issue. Note also
that from gps' data, it looks like build jobs on try take on average
less time (0.96 hrs/job) than build jobs on inbound (1.09 hrs/job). This
is kind of surprising to me because all try builds are clobber builds
and inbound builds are not, but there you have it. Perhaps the numbers
are skewed by the distribution of build platforms being different on try
vs inbound, but if that's the case, I would expect try to be more
representative of what would happen with the new process. Adding proper
support for "T" pushes [1] to trychooser would also help a lot here.
The second modification, suggested by Jesse, is to replace the "merge"
of try heads with a linear rebase. When I first suggested the "merge" I
was under the impression that hg allowed merging more than two heads but
it does not. Therefore it makes more sense to rebase the heads than to
merge them, to avoid introducing giant chains of two-parent merge
commits. If we ever switch to git we can consider going to octopus
merges, but that's not relevant for now. This change only affects the
mechanics of the merging, and shouldn't affect anything else about the
proposal - even the conflict resolution strategy (throw it back to the
developer) remains the same. I will still refer to this process as
"merging" since logically that's what it is. Also note that although
this sounds very similar to our current process of landing on inbound,
there is still a critical difference in that different heads are used to
independently test unrelated patches, eliminating the need for backouts
and reducing bustage pile-ups.
The third modification (also suggested by Jesse) is to add an "Auto"
tree in between Try and m-c. This can be thought of as a "staging" area
for doing the merge. The try heads would be merged to Auto, and then if
it is green, that merge becomes m-c. This ensures that m-c tip is
*always* green, which is an excellent property to have. The amount of
build resources used should be exactly the same, since no additional
tests will be required when pushing the merged head from Auto to m-c.
So to sum up, the process now looks like this:
From a developer's point of view:
1. Pull latest m-c
2. Commit local patch queue (patches with complete reviewer/approval
info, as if you were pushing to inbound)
3. Push to try as a new head, with appropriate trychooser syntax to
exercise the new patches without unnecessary builds/tests running.
4. If the try push is green, flag for merge by sheriffs and you're done.
5. If the try push is not green, fix your patch queue and go back to step 1.
Note that the above assumes you start with a tested and reviewed patch
queue. Obviously you are free to iterate on your patches on try before
this point as well, as long as you don't flag your try heads for merge.
From a sheriff's point of view:
1. Grab a list of all the try heads flagged for merge
2. Take m-c as the "base". For each head on the list, rebase the patches
onto the base, and update the base to be the head with the rebased
patches. If a patch has non-trivial merge conflicts, ignore the patch,
clear the flag, and notify the developer that they need to rebase it
themselves.
3. Push the result to the Auto tree, which will run a full set of tests.
4. If the tests are green, push to m-c (no tests need to run on m-c),
clear the flags from the try heads that were merged, and you're done.
5. If the tests are not green, attempt to identify the patches to blame.
This may require the assistance of the developers who wrote the patches.
Additional tests may be triggered on the try heads from step 1 to
provide more info.
6. If the bad patch(es) can be identified, go to step 6a. If the
identification step takes too long or is too hard, the sheriffs at their
discretion can go to step 6b.
6a. Remove the from the set of merged patches and re-push to Auto. Go
back to step 4.
6b. Declare that none of the patches will be merged until steps up to
look at the failures. Reset the flag on all of the try heads from step
1, and notify the developers. (Then go back to step 1 for the next round
of merging).
I'd like to get feedback in particular from the sheriffs on what they
think about this process, since I haven't heard very much from them, and
it probably affects their workflow the most.
Cheers,
kats
[1]
https://blog.mozilla.org/nnethercote/2013/03/27/an-interesting-use-of-the-try-server/comment-page-1/#comment-10089
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
