Release Management/Uplift rules

This document is a draft.

This page describes the rules applied by the Release Team to uplift a patch in one of the release.

All regular guidelines for changes apply.

General

• If a patch is considered as risky and impact both aurora and beta, please make sure that the other responsible is aware of the uplift.
• For a risky patch, don't hesitate to set the keyword "verifyme" to make sure someone will check if the bug is actually fixed.
• The name/nickname of the release manager who approved the uplift will be added in the commit message with a= (example: a=foobar)

Aurora Uplift (approval-mozilla-aurora)

• Can accept IDL (with UUID bump) changes as we do not lock down binary for addons until Beta
• No string changes unless late-l10n awareness and OK given
• Must be landed on mozilla-central, or reason given for direct-to-branch uplift
• No new feature landing
• No disruptive important refactoring
• No massive code changes

Beta Uplift (approval-mozilla-beta)

• Must be landed on mozilla-central as well as mozilla-aurora, or reason given for direct-to-branch uplift
• Ideally reproducible by QA so easily verified
• Has 'baked' on m-c/aurora and demonstrated decrease in crash or reproducibility
• No string changes
• No changes to UUID in .idl files (will break addon compatibility)

Changes can be:

• Performance improvement (proven, need real numbers)
• Top-crashers
• Recent regressions

The closer to the release the more careful uplift should be done.

Release Uplift

• Must be a part of a known-issue respin or NPTOB (not part of the build) config changes needed to support build infra

Special cases

• In the context of add-on SDK modifications, when an uplift is requested, it is normal not to find the land in m-c (because the m-c changeset is not posted in the bug report)

Security fixes

As described in Security/Bug_Approval_Process If the bug whiteboard contains a deadline, the uplift should be granted only after this date.