Release Management/Uplift rules: Difference between revisions

Jump to navigation Jump to search
fxos edits
(better place)
(fxos edits)
Line 49: Line 49:
* Must be a part of a known-issue respin or NPTOB (not part of the build) config changes needed to support build infra
* Must be a part of a known-issue respin or NPTOB (not part of the build) config changes needed to support build infra


=Firefox OS gaia uplifts=
=Firefox OS gaia/gecko uplifts=
 
==approval-gaia-v2.x=/approval-gecko-b2g37==
* For any gaia/gecko change's landing on the 2.x release, please request approval to land
* Please note, the closer we try to wrap up stabilization mode the more stricter we'd be on taking any changes


==approval-gaia-v2.x==
* As we've moved on from active feature development to stabilization mode on 6/9 for the 2.0 Release, we understand that their may be issues that don't necessarily block but can make a strong case for uplifts (refer to the criteria below).
* For such cases, we request folks to request approvals, which may be granted depending on the risk/reward analysis
* Please note, the closer we try to wrap up stabilization mode the more stricter we'd be on taking any non-needed changes and absolutely no changes in the last sprint of stabilization
=== Criteria to request approval (Guidelines) ===
=== Criteria to request approval (Guidelines) ===
* Patch must be landed and Resolved on master
* Patch must be landed and Resolved on master/central
* any non-blocking bug that has a high user impact
* any bug that has a high user impact
* String changes may not be approved after the string freeze dealine
* a low risk Polish change : Visual polish - colors, sizes, icons, alignment, etc
* a low risk Polish change : Visual polish - colors, sizes, icons, alignment, etc
* functional-polish: Example, Notification tray displaying that your microphone is active, but onclick does not do do anything. Ideally it should take to to microphone settings if I wanted to play with it..It's not really a bug, but it could be better. And it requires code changes, not just visual work.
* functional-polish: Example, Notification tray displaying that your microphone is active, but onclick does not do do anything. Ideally it should take to to microphone settings if I wanted to play with it..It's not really a bug, but it could be better. And it requires code changes, not just visual work.
* papercuts: It's for issues found during dogfooding/testing that are visually or functionally annoying or otherwise sub-par, but not enough to block the release
* papercuts: It's for issues found during dogfooding/testing that are visually or functionally annoying or otherwise sub-par, but not enough to block the release
* If you a requesting approval on a gaia patch that needs to land on 2.0 that
* Performance/crash-fixes : Depending on the risk evaluation and the reward we get ny uplifting these will be highly considered depending on where we are in the release cycle
** Set approval-gaia-v2.0: ? and making sure to fill the populated set of questions [Approval Request Comment] that come up on the attachment  
* If you a requesting approval on a gaia/gecko patch that needs to land on 2.x that
** Set approval-gaia-v2.x: ? and making sure to fill the populated set of questions [Approval Request Comment] that come up on the attachment  
[[File:Gaia-approval.png|800px|center]]
[[File:Gaia-approval.png|800px|center]]


==approval-gaia-v1.3==
 
* Any bug that needs to land on the 1.3 branch needs to get approval (even blockers : 1.3+)
* Once your patch has landed on master, set request approval-gaia-1.3: ? on patch attachment and fill in the approval request comment


=Special cases=
=Special cases=
Confirmed users
976

edits

Navigation menu