Release tracking rules

This page describes the rules applied by the Release Team to track or not a bug for a release.

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

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

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

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

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