Changes

Jump to: navigation, search

Release Management/Uplift rules

1,506 bytes removed, 09:54, 19 October 2016
remove FxOS section
* 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=
 
==approval-gaia-v2.x/approval-gecko-b2gxx==
* 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
 
=== Criteria to request approval (Guidelines) ===
* Patch must be landed and Resolved on master/central
* 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
* functional-polish: Example, Notification tray displaying that your microphone is active, but onclick does not do anything. Ideally it should take 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
* Performance/crash-fixes : Depending on the risk evaluation and the reward we get. Uplifting these fixes will be highly considered depending on where we are in the release cycle
* If you are requesting approval on a gaia/gecko patch that needs to land on 2.x that
** Set approval-gaia-v2.x/approval-gecko-b2g37: ? 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]]
=Special cases=
287
edits

Navigation menu