Changes

Jump to: navigation, search

Release Management/Uplift rules

1,176 bytes added, 20:25, 17 October 2016
m
Release Uplift: added some criteria for uplift. To do: add example bugs for each point.
==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.  * Must 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=
Confirm
2,814
edits

Navigation menu