> So what we're saying is that we are going to completely reverse our > previous tree management policy?
Basically, yes. Although, due to coalescing, do you always have a full run of tests on the tip of m-i before merging to m-c? A better solution would be to let you trigger a full set of tests (w/o coalescing) on m-i before merging to m-c. We've been asking for a similar feature for tryserver (let us add new jobs to my push) for a long time. Perhaps if we made this change, we could get releng to implement that feature sooner rather than later, particularly if this change caused pain to other teams who pull from a broken m-c. I am not above effecting a sense of urgency in order to get bugs fixed. :) > Currently, m-c is supposed to be the tree that's safely unbroken, and we > know it's unbroken because the tests that we run on it have already been > run on the tree that merged into it, and you should almost never push > directly to it unless you're in a desperate hurry to hit a nightly. > > This change would mean that we expect to have merges of hundreds of > csets from inbound sometimes break m-c with no idea which one broke it, > that we expect to sometimes have permaorange on it for days, and that > it's better to push your widget/cocoa/ pushes directly to m-c than to > inbound. > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
