Compatibility/System Addon/Override Policies and Workflows: Difference between revisions

Compatibility/System Addon/Override Policies and Workflows (view source)

Revision as of 00:49, 19 April 2018

340 bytes added , 19 April 2018

→‎Generic Process of adding an override: Update site patch release process checklist

Miketaylr

Confirmed users

796

edits

@@ Line 13: / Line 13: @@
 * Trending sites should also be considered, even when they don't rank highly in global usage metrics.
-== Generic Process of adding an override ==
+== Checklist for shipping a site patch  ==
-While the code of our Go Faster Addon is hosted [https://github.com/mozilla/webcompat-addon on GitHub], additional steps need to be done for adding an override.
+The requirements to ship a site patch follow:
 # There should be an issue on GitHub or Bugzilla. In that bug, diagnosis needs to be done first to validate that the issue is indeed caused by a user agent detection (if you plan on adding an UA override), or can be fixed with injecting JS or CSS.
-# If a user agent detection issue is confirmed, there should be some investigations on the least invasive UA override possible.
+# A [https://bugzilla.mozilla.org/enter_bug.cgi?product=Web%20Compatibility%20Tools&component=Go%20Faster Web Compatibility Tools::Go Faster] Bugzilla bug must be opened, with the See Also field linking to the original Bugzilla or GitHub issue that contains the diagnosis and justification for a site patch.
-# When the "minimum viable product" was found, a pull request against the [https://github.com/mozilla/webcompat-addon GitHub repo] should be opened.
+# A patch is written and pull request opened against the [https://github.com/mozilla/webcompat-addon GitHub repo], seeking review from a [https://github.com/orgs/mozilla/teams/webcompat/members webcompat team member].
-# At the same time, a test case for validating the need of this override should be written. ['''Note''': this is an ongoing project and there will be more details on that in the future.] That way, we will get notified if the site got fixed and the user agent is no longer needed. ['''ToDo''': will our testing framework also include a time based notification so we don't forget that we need to remove old overrides?]
+# Once the site patch is validated locally and given an r+, the PR should get merged.
-# If both the override and the test are validated, the PR should get merged.
+# A patch should be generated against Mozilla Central in order to release a new version of the Go Faster addon, following [https://github.com/mozilla/webcompat-addon#exporting-the-sources-to-mozilla-central these instructions], including a minor version bump.
-# If the PR is merged, a new version of the Go Faster addon should be released and rolled out to the users.
+# The patch should be attached to the bug in Step 2 and a [[Modules/All#Firefox|Firefox module peer]] must give an r+ for landing.
+# A signed XPI built from the r+ patch for deploying should be attached to the bug in Step 2. See the [[Firefox/Go_Faster/System_Add-ons/Process#QA_and_Code_Review|Go Faster Process Document]] for further info.
-'''Note''': A peer/module review will be required to land in m-c. And there will need to be some signoff process from relman or PI before we roll this out. To be clarified.
+# A [https://mana.mozilla.org/wiki/display/PI/PI+Request PI Request] should be sent linking to the XPI for testing against the site being patched.
-['''ToDo''': clarify how.]
+# An intent to ship email must be sent and RelMan approval obtained, per the [[Firefox/Go_Faster/System_Add-ons/Process#Intent_to_Ship_and_RelMan_Approval|Go Faster Process]].
 == Types of Overrides ==