Confirmed users
2,816
edits
Release Management/Uplift rules: Difference between revisions
Jump to navigation
Jump to search
m
Release Management/Uplift rules (view source)
Revision as of 20:25, 17 October 2016
, 17 October 2016→Release Uplift: added some criteria for uplift. To do: add example bugs for each point.
m (→Beta Uplift (approval-mozilla-beta): note about idl files and a question) |
m (→Release Uplift: added some criteria for uplift. To do: add example bugs for each point.) |
||
| Line 47: | Line 47: | ||
==Release Uplift== | ==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. | ||
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? Provide evidence of impact | |||
* 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 | |||
=Firefox OS gaia/gecko uplifts= | =Firefox OS gaia/gecko uplifts= | ||