Multiple inbounds are not a great idea for smarter usage of our infra
capacity or for load balancing, but this proposal doesn't attempt to
address the former and avoids the latter by making the availability of
the two inbounds mutually exclusive, so, it looks good.
I also doubt that it's going to have a lot of bad impact on the infra
load because of the mutual exclusion. Hopefully we'll monitor the infra
load after switching to this model to keep an eye on how we're doing there.
Cheers,
Ehsan
On 2013-04-26 3: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
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
