hi RyanVM; I really like this proposal because it gives Mozilla a way for developers to continue doing checkins even during a prolonged mozilla-inbound closure. The experiment with birch as "b2g-inbound" has been really successful so far, which is good.
To easily experiment to see if the proposal helps, I have reserved "cypress" and filed bug#866314 to setup cypress running all the same builds/tests as inbound. Once cypress is ready, lets use cypress as "inbound2"... and try this proposal to see how it goes. Unless anyone has any concerns/objections, lets try have sheriffs use cypress-as-mozilla-inbound2 when we next hit a prolonged mozilla-inbound closure. (and yes, if we find this experiment helps, we can setup branches with real names instead of using birch, cypress!) tc John. On 4/26/13 12:17 PM, Ryan VanderMeulen 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
