Release Management/Uplift rules

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)

Guidelines on approval comments

• [Feature/regressing bug #]: If you this is a fallout from a feature/bug, or a backout please state the reason along with the bug number
• [User impact if declined]: In addition to the STR (steps to reproduce) reported in the bug if you can explain on a deeper level aspect of how an end user would be impacted with/without your change
• [Describe test coverage new/current, TBPL]: What kind of testing was completed here. Manual and/or automated ? Any details about what scenarios the tests cover? If the patch landed on a master/central branch or any other branch did we get verification from reporter or QA.
• [Risks and why]: No risk/Zero risk are unacceptable here. Even a single line of code change could be damaging!, yes we've seen that
  • When saying something is "low","medium", "risky" please justify
  • Eg : Low risk because its a one line CSS change impacting only settings page
  • Eg : Medium, given the code complexity and integration with other areas of code that might be impacted. Expect regressions in areas like..
  • Eg : risky, given the complex nature the bake time we have have on master/central or other branches. High rate of fallouts/regression. Could be mitigated by more manual testing in areas or running some targeted test cases..
• [String/UUID change made/needed]: Please answer this as "none" if no string changes were made

Firefox (Desktop and Mobile)

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

Firefox OS gaia uplifts

approval-gaia-v2.0

• As we've moved on from active feature development to stabilization mode on 6/9 for the 2.0 Release, we understand that their may be issues that don't necessarily block but can make a strong case for uplifts (refer to the criteria below).
• For such cases, we request folks to request approvals, which may be granted depending on the risk/reward analysis
• Please note, the closer we try to wrap up stabilization mode the more stricter we'd be on taking any non-needed changes and absolutely no changes in the last sprint of stabilization

Criteria to request approval (Guidelines)

• Patch must be landed and Resolved on master
• any non-blocking bug that has a high user impact
• a low risk Polish change : Visual polish - colors, sizes, icons, alignment, etc
• functional-polish: Example, Notification tray displaying that your microphone is active, but onclick does not do do anything. Ideally it should take to to microphone settings if I wanted to play with it..It's not really a bug, but it could be better. And it requires code changes, not just visual work.
• papercuts: It's for issues found during dogfooding/testing that are visually or functionally annoying or otherwise sub-par, but not enough to block the release
• If you a requesting approval on a gaia patch that needs to land on 2.0 that
  • Set approval-gaia-v2.0: ? and making sure to fill the populated set of questions [Approval Request Comment] that come up on the attachment

approval-gaia-v1.3

• Any bug that needs to land on the 1.3 branch needs to get approval (even blockers : 1.3+)
• Once your patch has landed on master, set request approval-gaia-1.3: ? on patch attachment and fill in the approval request comment

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)
• If patches only make changes to tests, test harnesses or anything else that does not affect the shipped builds, they may land with self approval (use a=testonly, a=npotb etc).

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.