This page describes the rules applied by the Release Team to track or not a bug for a release. The Uplift rules page may also be helpful for understanding relman decision making.

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: Status flags + keyword

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-firefox56: unaffected 
status-firefox57: affected

Add the keyword "regression" to the keyword field.

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

Not a regression: Request tracking

Tracking requests are made by changing "tracking flags" -> "tracking-firefoxN" flag to "?" and updating "status-firefoxN" flag to "affected" on a bug in bugzilla.

When dealing with new features, this case is common.

Tracking is recommended if:

• You want to escalate quickly to get a fix in an important, unassigned bug. Relman and engineering managers will work to find an assignee.
• High volume crashes. For example, bugs with keyword topcrash* are usually tracked.
• High impact on web compatibility
• Add-on compatibility implications
• Introduced a new feature which may need to be backed out
• The bug is sec-critical

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).

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).

Release blocking issues

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". This is a judgement call by the release owner, based on how severe we think the impact is on users. And, generally something that would be a release blocker would also be a potential dot release driver.

Any of these might be a release blocker / dot release driver:

• A truly massive crash (with a signature higher in rank in crash-stats than OOM|small)
• A horrible startup crash
• a major browser/feature functionality bug that affects a large number of users
• An issue that has dozens of duplicate bugs reported (indicating high impact)
• a severe bug that affects all users on a particular platform (Mac, Linux, or particular hardware)
• a severe bug that affects all users in a particular locale/language (example, RTL issues, or IME keyboards)
• a bug that seriously impacts revenue
• a bug that means we aren't getting telemetry important for future planning or features
• severe perf issue that is affecting users in the wild
• a major privacy or data loss issue

Disabling a Feature

• separate bugs for "disable feature X" are always clearer than attaching patches/getting approvals in meta or other bugs with confusing summaries (e.g. it's hard to tell that bug 994589 resulted in a feature disabling after the fact without hunting through the comments, that bug is tracking something else overall)

• the "disabled" value of the status flags should be set on bugs whose functionality is being disabled, not on bugs where the disabling took place. For example, in this case, bug 619558 (and maybe other trackers?) should be marked "status-firefox31: disabled" (the feature is disabled on 31), and bug 994589 should be marked as "status-firefox31: fixed" (the crashes are fixed by the disabling - a comment indicating that is also useful).