User:RyanVM/Job Visibility Policy Updates: Difference between revisions

Jump to navigation Jump to search
Remove some extraneous language and clarify typical practice for pinging in the event of bustage
(wording tweaks)
(Remove some extraneous language and clarify typical practice for pinging in the event of bustage)
Line 44: Line 44:
==== Breakage is expected to be followed by tree closure or backout ====
==== Breakage is expected to be followed by tree closure or backout ====
* Failures visible in the default view (other than those that are known intermittents/transient), must have their cause backed out in a timely fashion or else the tree closed until diagnosed.
* Failures visible in the default view (other than those that are known intermittents/transient), must have their cause backed out in a timely fashion or else the tree closed until diagnosed.
* Why? If Tier != 1 jobs were treated the same, they would:
* Sheriffs will generally ping in #developers on irc.mozilla.org when such a situation arises. If sufficient time passes without acknowledgement (typically ~5min), the regressing patch(es) will be backed out in order to minimize the length of the closure for other developers.
** Interfere with ability to sheriff the tree:
* If acknowledged, sheriffs will decide in conjunction with the developer whether backing out or fixing in-place is the most reasonable resolution. The sheriff maintains the right to backout if necessary, however.
*** Indistinguishable from Tier 1 failures.
*** Appear in the failure count/cause the tab to glow.
*** Slow down navigation of failures when using keyboard shortcuts.
** Cause extra workload for sheriffs by making them perform initial diagnosis/bug filing & then starring of the failure on every push until it is fixed an indeterminate amount of time later.
** Cause confusion for non-sheriffs using project branches/try-server, as well as on all trees at the weekends when there are no employed sheriffs.
* If your platform/test falls under the category of "someone should just file a bug and it will be investigated by our team later", then it unfortunately does not meet this requirement. From past requests this normally translates to "group X think this job type is important but we want to delegate the task of monitoring it to someone else".


==== Runs on mozilla-central and all trees that merge into it ====
==== Runs on mozilla-central and all trees that merge into it ====
Confirmed users
1,052

edits

Navigation menu