I like that inbound2 would be open only when inbound is closed. That way you don't have to make a decision wrt which tree to push to.
sgtm. On Fri, Apr 26, 2013 at 3:17 PM, Ryan VanderMeulen <rya...@gmail.com> wrote: > As has been discussed at length in the various infrastructure meetings, one > common point of frustration for developers is frequent tree closures due to > bustage on inbound. While there are other issues and ideas for how to > improve the inbound bustage situation, one problem I'm seeing is that > multiple different issues with different solutions are being lumped together > into one discussion, which makes it hard to gain traction on getting > anything done. For that reason, I would like to specifically separate out > the specific issue of inbound closures negatively affecting developer > productivity and offer a more fleshed-out solution that can be implemented > now independent of any other ideas on the table. > > Specific goals: > -Offer an alternative branch for developers to push to during extended > inbound closures > -Avoid patch pile-up after inbound re-opens from a long closure > > Specific non-goals: > -Reducing infrastructure load > -Changing pushing strategies from the widely-accepted status quo (i.e. > multi-headed approach) > -Creating multiple integration branches that allow for simultaneous pushing > (i.e. inbound-b2g, inbound-gfx, etc) > > My proposal: > -Create an inbound2 branch identically configured to mozilla-inbound. > -Under normal circumstances (i.e. m-i open), inbound2 will be CLOSED. > -In the event of a long tree closure, the last green changeset from m-i will > be merged to inbound2 and inbound2 will be opened for checkins. > ---It will be a judgment call for sheriffs as to how long of a closure will > suffice for opening inbound2. > -When the bustage on m-i is resolved and it is again passing tests, inbound2 > will be closed again. > -When all pending jobs on inbound2 are completed, it will be merged to m-i. > -Except under extraordinary circumstances, all merges to mozilla-central > will continue to come from m-i ONLY. > -If bustage lands on inbound2, then both trees will be closed until > resolved. Tough. We apparently can't always have nice things. > > As stated above, I believe that this will solve one of the biggest > painpoints of long tree closures without adding tons of extra complexity to > what we're already doing and what developers are used to. The affect on > infrastructure load should be close to neutral since at any given time, > patches will only be getting checked into one branch. This proposal also has > the advantage of being easy to implement since it's simply a clone of an > existing repo, with a little extra sheriff overhead. It also helps to > mitigate the pile-up of pushes we tend to see after a long closure which > increase the likelihood of another long closure in the event of any bustage > due to a high level of coalescing. > > To be clear, this proposal is NOT intended to solve all of the various > problems that have been raised with respect to infrastructure load, good > coding practices, bustage minimization, good Try usage, etc. This is only > looking to reduce the impact such issues have on developer workflow and make > sheriffing easier after the tree reopens. > > Feedback? > _______________________________________________ > 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
