Release Management/Feature Uplift: Difference between revisions

← Older edit

Release Management/Feature Uplift (view source)

Revision as of 15:53, 10 October 2019

581 bytes added , 10 October 2019

Add warning that the content needs an update

Pascalc

Confirmed users

1,255

edits

@@ Line 1: / Line 1: @@
+{{RELEASE_MANAGEMENT_UPDATE_NEEDED}}
 = Feature Uplift for Desktop and Mobile =
 In most cases new feature work should land on mozilla-central (m-c / Nightly). There may be cases when we choose to uplift a feature to Aurora or Beta. This document includes information to help guide the uplift decision and concerns that should be addressed before uplift.
@@ Line 11: / Line 12: @@
 == Considerations for uplift ==
-;Localization (l10n): No string changes are permitted on Aurora and Beta without agreement from l10n. Every effort should be made to maintain string freeze on these branches so as to minimize the impact on the l10n teams. If a feature requires string changes, the l10n team (pike, flod) must review before uplift. Suggested alternatives to string changes:
+;Localization (l10n): No string changes are permitted on Aurora and Beta without agreement from l10n. Every effort should be made to maintain string freeze on these branches so as to minimize the impact on the l10n teams. If a feature requires string changes, the [[L10n:Communication|l10n team]] must review before uplift.
-* land string changes on m-c if the it is known that the feature will be uplifted before the merge from m-c to mozilla-aurora
+;UUID changes: UUID changes are acceptable on Aurora but not acceptable on Beta (because they may break add-ons). If a feature requires UUID changes and uplift to Beta, the add-ons team (addons-team at mozilla dot com) must be consulted for assessing the impact to add-ons. If an exception to this rule is granted, the change must be communicated to add-on developers.
-* hard code strings and ship an English only feature - this is not generally acceptable but may be suitable in some cases
+;Marketing and Comms plan:If there is a reason for uplifting a feature, the feature should typically be accompanied by a marketing and comms plan. Work with these teams early to develop the plan.
-;UUID changes: UUID changes are acceptable on Aurora but generally not accepted on Beta (because they may break add-ons). If a feature requires UUID changes and uplift to Beta, the add-ons team (Jorge Villalobos) should be consulted for communicating the change to add-on developers.
-;Marketing and Comms plan:If there is a reason for uplifting a feature, the feature should typically be accompanied by a marking and comms plan. Work with these teams early to develop the plan.
 ;Uplift landings: If the feature is sufficiently complex, it may be preferable to have the lead engineer land the changes on all branches themselves vs relying on the sheriffs for uplift.
+;Informing others: It will likely be beneficial to inform other teams of the uplift. You are encouraged to do so via a post to [https://lists.mozilla.org/listinfo/dev-platform dev-platform] and by discussing the uplift during the [[Platform/#Meetings|Engineering meeting]].
 == Requirements for uplift ==
-;Ability to pref off: With less time to stabilize the feature, we need the ability to disable it quickly if the need arises. This is most easily accomplished by creating a pref to disable the feature.
+;Ability to pref off: With less time to stabilize the feature, we need the ability to disable it quickly if the need arises. This is most easily accomplished by creating a pref to disable the feature. Another option is to build the feature so that it can be disabled with <code>[https://developer.mozilla.org/en-US/docs/When_To_Use_ifdefs#_Feature_ifdefs_ ifdef]</code> statements.
 ; Automated tests: Automated tests are required before uplifting the feature. The point is to prove to the best of our ability that the feature is stable before landing it on one of our stabilization branches (Aurora and Beta).
 ; Quality Engineering (QE) agreement: Acknowledgement from QE that they can test the feature and preferably a test plan.
@@ Line 27: / Line 27: @@
 === Approval ===
 ;Release Manager: The [[Release_Management/Release_owners|release manager for the release]] is the decision maker for uplift*.
-;Firefox Senior Management: For a substantial, user facing desktop feature, Gavin Sharp, Madhava Enros, and Chad Weiner should sign off on the uplift.
+;Desktop changes - Firefox Senior Management: For a substantial, user facing desktop feature, Gavin Sharp, Madhava Enros, and Chad Weiner should sign off on the uplift.
-;Fennec Senior Management: For a substantial, user facing mobile feature, Mark Finkle, Brad Lassey, and Karen Rudnitski should sign off on the uplift.
+;Mobile changes - Fennec Senior Management: For a substantial, user facing mobile feature, Mark Finkle, Brad Lassey, and Karen Rudnitski should sign off on the uplift.
+;Platform changes - Module owner: For a substantial, user visible change to the platform, such as unprefixing CSS properties, adding new DOM properties, changing the behaviour of existing properties, the module owner should sign off on the uplift.
 <nowiki>*</nowiki>Note: In cases of disagreement where an escalation is required, Johnathan Nightingale, VP Firefox, will be the ultimate decision maker.