Release Management/Tracking rules: Difference between revisions

Release Management/Tracking rules (view source)

Revision as of 19:23, 11 September 2017

501 bytes removed , 11 September 2017

m

→‎Regressions: Status flags + keyword: format fix for regression explanation

Lizhenry

Confirmed users

2,816

edits

@@ Line 6: / Line 6: @@
 = Regressions: Status flags + keyword =
-*Please mark regressions with the keyword "regression" and the status flag.*
+'''Please mark regressions with the keyword "regression" and the status flag.'''
-For example, a bug which is a new regression in 57 should be flagged "status-firefox57: affected" and "status-firefox56:unaffected". It should also have "regression" in the keyword field.
+For example, a bug which is a new regression in 57 should be flagged:
+ status-firefox56: unaffected
+ status-firefox57: affected
-That should ensure that the bug will be triaged by relman and a team of engineering managers.
+Add the keyword "regression" to the keyword field.
-It will show up on this Release Health dashboard: https://mozilla.github.io/releasehealth/?channel=beta
-If you know the bug is a important regression, and you need to escalate quickly to get help across teams, then you can also request the bug to be tracked by relman. Release management will track the bug and follow up with developers and QE to get it fixed, tested, and in affected releases as soon as possible. Not every regression can or should be tracked.
+Bugs with these flags and keyword will be triaged by relman and a team of engineering managers.
+They'll show up on this Release Health dashboard: https://mozilla.github.io/releasehealth/?channel=beta
-For a very serious issue that would block either a release, or the release of a feature, relman can mark the tracking flag as "blocking".
 = Not a regression: Request tracking =

Release Management/Tracking rules: Difference between revisions

Release Management/Tracking rules (view source)

Revision as of 19:23, 11 September 2017

Navigation menu

Search