Release Management/Uplift rules: Difference between revisions

Release Management/Uplift rules (view source)

Revision as of 05:46, 26 April 2015

2 bytes added , 26 April 2015

→‎Criteria to request approval (Guidelines)

Joshwalker

Confirmed users

811

edits

@@ Line 60: / Line 60: @@
 * 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 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 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 ny uplifting these will be highly considered depending on where we are in the release cycle
+* 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 a requesting approval on a gaia/gecko patch that needs to land on 2.x that
+* 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]]