Confirmed users
2,816
edits
Release Management/Tracking rules: Difference between revisions
Jump to navigation
Jump to search
m
Release Management/Tracking rules (view source)
Revision as of 19:14, 11 September 2017
, 11 September 2017Clarifying some triage and flagging issues
m (→Regression: relaxed rules of tracking a bit after discussion with relman team) |
m (Clarifying some triage and flagging issues) |
||
| Line 5: | Line 5: | ||
[[Releases/Flags|Tracking flags]] are set to manage a list of release critical bugs but also the bugs / features that the Release Team wants to keep on their radar. | [[Releases/Flags|Tracking flags]] are set to manage a list of release critical bugs but also the bugs / features that the Release Team wants to keep on their radar. | ||
= Regressions = | |||
*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. | |||
That should ensure that the bug will be triaged by relman and a team of engineering managers. | |||
If 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. | |||
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 = | = Not a regression = | ||
When dealing with new features, this case is common. | When dealing with new features, this case is common. | ||
Tracking is recommended if: | Tracking is recommended if: | ||
* The bug is | * The bug is (or fixes) a high volume crash. For example, bugs with keyword ''topcrash*'' are usually tracked. | ||
* | * High impact on web compatibility | ||
* Add-on compatibility implications | * Add-on compatibility implications | ||
* Introduced a new feature which may need to be backed out | * Introduced a new feature which may need to be backed out | ||
* The bug is sec-critical (or maybe sec-high as well; we should at least triage sec-high) | * The bug is sec-critical (or maybe sec-high as well; we should at least triage sec-high) | ||
* Anything you want help with because it involves several teams or is confusing while being high impact | |||
If there is no patch on a critical or high-impact bug report, the tracking is recommended. | |||
If | If the patch has already landed in Mozilla-central for a few days and an uplift request has been filled (or already applied), tracking is not necessary (except for high risk changes). | ||
= Misc = | = Misc = | ||
The tracking flag ''tracking-fennec'' is not managed by the release team. This flag is used by the mobile team. | The tracking flag ''tracking-fennec'' is not managed by the release team. This flag is used by the mobile team. | ||
Fennec bugs should be marked with status flags, the same as for Desktop. | |||
= Disabling a Feature = | = Disabling a Feature = | ||