Release Management/Uplift rules: Difference between revisions

Jump to navigation Jump to search
Move the guidelines upper (it is general for Firefox and FFOS)
(Move the guidelines upper (it is general for Firefox and FFOS))
Line 34: Line 34:
=Release Uplift=
=Release Uplift=
* 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
= Guidelines on approval comments =
* [Bug caused by] (feature/regressing bug #): If you this is a fallout from a feature/bug, or a backout please state the reason along with the bug number
* [User impact] if declined: In addition to the STR (steps to reproduce) reported in the bug if you can explain on a deeper level aspect of how an end user would be impacted with/without your change
* [Testing completed]: What kind of testing was completed here. Manual and/or automated ? Any details about what scenarios the tests cover? If the patch landed on a master/central branch or any other branch did we get verification from reporter or QA.
* [Risk to taking this patch]: No risk/Zero risk are unacceptable here. Even a single line of code change could be damaging!, yes we've seen that
** When saying something is "low","medium", "risky" please justify
** Eg : Low risk because its a one line CSS change impacting only settings page
** Eg : Medium, given the code complexity and integration with other areas of code that might be impacted. Expect regressions in areas like..
** Eg : risky, given the complex nature the bake time we have have on master/central or other branches. High rate of fallouts/regression. Could be mitigated by more manual testing in areas or running some targeted test cases..
* [String changes made]: Please answer this as "none" if no string changes were made


=Firefox OS gaia uplifts=
=Firefox OS gaia uplifts=
Line 54: Line 65:
* Any bug that needs to land on the 1.3 branch needs to get approval (even blockers : 1.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
* Once your patch has landed on master, set request approval-gaia-1.3: ? on patch attachment and fill in the approval request comment
= Guidelines on approval comments =
* [Bug caused by] (feature/regressing bug #): If you this is a fallout from a feature/bug, or a backout please state the reason along with the bug number
* [User impact] if declined: In addition to the STR reported in the bug if you can explain on a deeper level aspect of how an end user would be impacted with/without your change
* [Testing completed]: What kind of testing was completed here. Manual and/or automated ? Any details about what scenarios the tests cover? If the patch landed on a master/central branch or any other branch did we get verification from reporter or QA.
* [Risk to taking this patch]: No risk/Zero risk are unacceptable here. Even a single line of code change could be damaging!, yes we've seen that
** When saying something is "low","medium", "risky" please justify
** Eg : Low risk because its a one line css change impacting only settings page
** Eg : Medium, given the code complexity and integration with other areas of code that might be impacted. Expect regressions in areas like..
** Eg : risky, given the complex nature the bake time we have have on master/central or other branches. High rate of fallouts/regression. Could be mitigated by more manual testing in areas or running some targeted test cases..
* [String changes made]: Please answer this as "none" if no string changes were made


=Special cases=
=Special cases=
Account confirmers, Anti-spam team, Bureaucrats, canmove, Confirmed users, Module owners and peers, smwadministrator, smwcurator, Administrators, MozillaWiki team, Widget editors
731

edits

Navigation menu