Confirmed users
2,816
edits
m (→Regressions: Status flags + keyword: format fix for regression explanation) |
m (→Not a regression: Request tracking: More bullet points for tracking explanation) |
||
Line 22: | Line 22: | ||
Tracking is recommended if: | Tracking is recommended if: | ||
* | * You want to escalate quickly to get a fix in an important, unassigned bug. Relman will work to find an assignee. | ||
* High volume crashes. For example, bugs with keyword ''topcrash*'' are usually tracked. | |||
* High impact on web compatibility | * 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 | * The bug is sec-critical | ||
If there is no patch on a critical or high-impact bug report, | If there is no patch on a critical or high-impact bug report, then tracking is recommended. | ||
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). | 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). | ||
What does it mean for a bug to be tracked? Release management will triage it about once a week, will follow up with developers, QE, managers, project managers, and product teams to get it fixed, tested, and in affected releases as soon as possible. | |||
Not every regression can or should be tracked. We can trust to the regression triage team (which includes relman). | |||
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". | |||
= Misc = | = Misc = |