Release Management/Uplift rules

From MozillaWiki
Jump to: navigation, search


This page describes the rules applied by the Release Team to uplift (aka backport) a patch from a development branch to a more stable branch. For example, taking a patch that fixes a bug in Nightly and applying it to the aurora and beta branches.

All regular guidelines for changes apply.

General

  • Uplifts are requested in the Details page of the attachment, Flags section which should be updated.
  • 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 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", or "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) (This is no longer true; additions to an IDL would only cause problems for add-ons using binary XPCOM, which we no longer support) Do we have any restrictions left for uuid changes on beta?

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

Some issues are bad enough that we don't want to wait till the next major release. We do major releases every 6-8 weeks. Most fixes can wait that long. Candidates for uplift to release may be drivers of a dot release, or may be "ridealongs" nice but not crucial to have. If it would be a release blocker, it might be a good dot release driver.

Each dot release will mean annoyance for users, and will also result in an increased chance for some users of being "orphaned" on that version.

"Ridealongs" or any extra fixes increase the chance that we will cause a new regression that may need another fix and uplift, or even drive another dot release.

For uplift requests to release, please give as much data as possible to help with the decision. It is also helpful if you can specify if your fix affects desktop, fennec, or both.

  • Major top crash (above or near the level for oom crashes). Provide evidence of impact.
  • High volume startup crash.
  • Security issue that doesn't need a chemspill, but that is bad enough to drive a dot release
  • Functional regression with a broad impact (We can see from telemetry it's affecting many users, or we have many reports from support.mozilla.org, input.m.o, or other user reports)
  • Problem in a major feature
  • To uplift to release without relman approval, your change must be a part of a known-issue respin or NPOTB (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)
  • 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.