mozilla-inbound backout policy subject to change (become similar to autoland)

Sebastian Hengst aryx at gmx.de
Thu Aug 23 20:55:21 UTC 2018


The job visibility policy [1] says that tier 2 is observed but unmanaged 
while the documentation on tier 2 platforms [2] explains that changes 
causing issue for tier 2 are not immediately backed out but get reverted 
if no fix is found.

The job visibility policy and the classification of jobs as tier 2 is 
currently under review.

Having jobs permafail without an enforced ETA for a fix causes those 
failures to accumulate and makes the jobs not observable anymore. For 
that reason and to be able to get a quick overview of the state of 
mozilla-central and Try pushes, merges to mozilla-central aim for merge 
candidate revisions without issues on Tier 2. If the developer whose 
push started tier 2 failures doesn't answer messages from the sheriffs 
about the issue, there is no ETA for a fix and the change gets reverted.

Prolonged permafailures on tier 2 have never been allowed in the last 3 
years.

[1] https://wiki.mozilla.org/Sheriffing/Job_Visibility_Policy
[2] 
https://developer.mozilla.org/en-US/docs/Mozilla/Supported_build_configurations

Sebastian

-------- Original-Nachricht --------
Betreff: mozilla-inbound backout policy subject to change (become 
similar to autoland)
Von: Sebastian Hengst <shengst at mozilla.com>
Datum: 2018-06-19 15:04
> Hi,
> 
> If you don't push code to mozilla-inbound, you can stop reading now.
> 
> TL;DR: We would like to change the mozilla-inbound backout policy to be 
> like autoland’s.
> 
> In order to decrease tree closure times for inbound, allow for more 
> frequent merges from inbound to m-c, and ensure consistent policies 
> across our integration branches, we propose that mozilla-inbound adopt 
> the same policy as autoland for how issues with a push (failures, 
> exception loops, ...) are handled. Rather than asking the developer to 
> investigate and fix the issue with a follow-up push if possible, 
> sheriffs will instead backout the patch and notify developers in the bug 
> and IRC if possible.
> 
> If your patch touches so much code that it is always at risk of 
> bitrotting or is urgent (e.g. Release Management wants it ASAP), talk to 
> the sheriffs in the #sheriffs channel on IRC
> before you push and get their approval to push (this is for checking
> that mozilla-inbound will have a recent "good" state for merges).
> 
> If your patches got backed out, you can reapply them locally with |hg 
> graft -fr <revset>| and fix them with |hg histedit| or |hg commit 
> --amend| before pushing.
> 
> Sebastian
> Sheriff Trainer & Code Quality Engineer
> 




More information about the firefox-dev mailing list