Revision as of 08:54, 27 February 2014

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.

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

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:

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

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

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

@@ Line 4: / Line 4: @@
 All [https://developer.mozilla.org/en-US/docs/Developer_Guide/How_to_Submit_a_Patch 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.
 =Aurora Uplift (approval-mozilla-aurora)=