FWIW, I'm torn on this topic as a sheriff who has often had to wade
through the fallout of poorly-tested patches (I've landed a few myself
too!). It can be a massive pain when we're in periods of heavy load with
a lot of coalescing going on. It can lead to very long periods of tree
closure while backouts/retriggers happen and the mess gets sorted out.
However, my recollection is that the original idea of inbound was for
exactly this situation! We wanted to keep mozilla-central in a
relatively known-good and nearly always open state, which was far from
the case prior to inbound. In that sense, inbound has been a great success.
I think that for many cases, a green Try run on one platform can be a
good indicator of patch's ability to stick. I'd be OK with fewer jobs
being run by default on a Try push (though leaving an option for someone
who truly needs the full set). However, people are also going to need to
accept that with that reduced testing, we will probably need to be more
willing to accept more frequent inbound closures for bustage as there is
certainly platform-specific bustage that will be missed (the recent
WinXP debug m-oth leaks on a specific patch come to mind).
We as sheriffs should also be more willing to revert to known-good
changesets in the event of piled-up bustage with a green Try run on all
affected platforms as a condition for re-landing. I know Ed Morley has
done similar things where he has graciously re-landed backed out
changesets after green Try runs (as have I a couple times), but that
responsibility shouldn't necessarily fall on the sheriff. The burden of
proof should fall on the person pushing the patch.
Heck, this might even encourage people to check TBPL more often before
pushing, leading to less piling-up!
-Ryan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
