297
edits
Release Management/Uplift rules: Difference between revisions
Jump to navigation
Jump to search
update patch uplift rules
m (actual fix now.... ugh!) |
(update patch uplift rules) |
||
| Line 3: | Line 3: | ||
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 beta branch. The [[Release_Management/Tracking_rules|release tracking rules]] page may also be helpful for understanding how release management makes decisions. | 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 beta branch. The [[Release_Management/Tracking_rules|release tracking rules]] page may also be helpful for understanding how release management makes decisions. | ||
All [https:// | All [https://firefox-source-docs.mozilla.org/contributing/how_to_submit_a_patch.html regular guidelines] for changes apply. | ||
=General= | =General= | ||
* Uplifts are requested in the ''Details'' page of the attachment, ''Flags'' section which should be updated. | * Uplifts are requested in the ''Details'' page of the attachment, ''Flags'' section which should be updated. | ||
* For a risky patch, don't hesitate to set the "qe-verify" flag to "+" to make sure someone will check if the bug is actually fixed. | |||
* For a risky patch, don't hesitate to set the | |||
* The name/nickname of the release manager who approved the uplift will be added in the commit message with ''a='' (example: ''a=foobar'') | * 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 = | = Guidelines on approval comments = | ||
* [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 | * [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 | ||
* [ | * [Is this code covered by automated tests?] Yes/No/Unknown | ||
* [ | * [Has the fix been verified in Nightly?] Was the fix verified in a nightly build, e.g. by the reporter or QA? | ||
** When saying something is "low", "medium", or " | * [Needs manual test from QE?] Yes/No | ||
** | ** [If yes, steps to reproduce] Either point to an existing comment listing STR or elaborate here directly. | ||
** | * [List of other uplifts needed] If this patch depends on other changes that are not present on the target branch, list them here (and request approval in the other bugs as well) | ||
** | * [Risk to taking this patch]: Low/Medium/High | ||
* [String | * [Why is the change risky/not risky? (and alternatives if risky)] | ||
** When saying something is "low", "medium", or "high" risk please justify | |||
** E.g.: Low risk because its a one line CSS change impacting only settings page | |||
** E.g.: Medium, given the code complexity and integration with other areas of code that might be impacted. Expect regressions in areas like... | |||
** E.g.: Risky, given the complex nature the bake time we have have on central or other branches. High rate of fallouts/regression. Could be mitigated by more manual testing in areas or running some targeted test cases... If the issue could be worked around by disabling a certain feature, or with a different, less-risky, patch for uplift, mention this here. | |||
* [String changes made/needed] Please answer this as "none" if no string changes were made. String changes need to be approved by a l10n driver since they impact the work of localization teams. | |||
= Firefox (Desktop and Mobile) = | = Firefox (Desktop and Mobile) = | ||
| Line 28: | Line 31: | ||
* Ideally reproducible by QA so easily verified | * Ideally reproducible by QA so easily verified | ||
* Has 'baked' on m-c and demonstrated decrease in crash or reproducibility | * Has 'baked' on m-c and demonstrated decrease in crash or reproducibility | ||
* No string changes | * No string changes, unless approved by l10n driver | ||
Changes can be: | Changes can be: | ||
| Line 34: | Line 37: | ||
* Top-crashers | * Top-crashers | ||
* Recent regressions | * Recent regressions | ||
* Low risk improvements early in the cycle | |||
* Enabling features that have been validated/tested by QA, or have already shipped e.g. through a normandy rollout. | |||
The closer to the release the more careful uplift should be done. | The closer to the release the more careful uplift should be done. | ||
==Release Uplift== | ==Release Uplift== | ||
Some issues are bad enough that we don't want to wait | Some issues are bad enough that we don't want to wait until the next major release. We do major releases every 4 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. | 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. | ||
| Line 44: | Line 49: | ||
"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. | "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, | 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, android, or both. | ||
Examples include: | |||
* Major top crash (above or near the level for oom crashes). Provide evidence of impact. | * Major top crash (above or near the level for oom crashes). Provide evidence of impact. | ||
* High volume startup crash. | * High volume startup crash. | ||
| Line 57: | Line 63: | ||
* 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). | * 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). | ||
** In that case, instead of setting the "approval-mozilla-beta" flag on the patch, you can add "[checkin-needed-beta]" in the bug's "whiteboard" field. | |||
=Security fixes= | =Security fixes= | ||