Release Management/Uplift rules: Difference between revisions

Release Management/Uplift rules (view source)

29 bytes removed , Thursday at 15:39

minor corrections

458

edits

@@ Line 36: / Line 36: @@
 An important question for any uplift is: how severe is the issue, and how risky is the fix? We uplift low-risk fixes for high-severity issues. We do not uplift low-severity issues, high-risk changes, or new features — those ride the next train or wait behind a pref.
 * [https://firefox-source-docs.mozilla.org/bug-mgmt/guides/severity.html Severity] = user impact: how many users are affected and how badly (crash, data loss, broken top site, security exposure) vs. cosmetic or rare edge case.
-* "Risk" = the chance the patch itself introduces a new regression: size of the change, component risk (see best practices below), bake time, and test coverage.
+* "Risk" = the chance the patch itself introduces a new regression: size of the change, component risk, bake time, and test coverage.
 Rule of thumb:
@@ Line 92: / Line 92: @@
 == ESR Uplift (approval-mozilla-esrXX) ==
-We do an ESR minor releases every 2 weeks. These releases do not include new features and are reserved for stability/security fixes only. ESR uplift requests follow a similar uplift request process as Beta/Release.
+We do a ESR minor release every 2 weeks. These releases do not include new features and are reserved for stability/security fixes only. ESR uplift requests follow a similar uplift request process as Beta/Release.
 [[category:Release_Management|U]]
 [[Category:Release_Management:Processes|Uplift]]