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

''Note: for simplicity, interventions and UA overrides will be referred to solely as interventions in this section.''

There are two types of interventions that we ship in Firefox: high priority and low priority. As a general rule of thumb, a low priority intervention will fix a long-standing bug. A high priority intervention will fix a regression in a top site. In case of confusion, please get in touch with Mike Taylor for clarification as to which class we’re dealing with.

High priority interventions require shipping out-of-band via Balrog ([https://bugzilla.mozilla.org/show_bug.cgi?id=1571535 or Normandy in the future]), and as such, require a more in-depth QA and Relman release process, at least for Fennec and Desktop. The process for Release Fenix is currently undefined.

All interventions should first land in the [https://github.com/mozilla-extensions/webcompat-addon Mozilla webcompat-addon repo] on GitHub and be accompanied by a version number bump in the addon’s manifest.json. There may be high priority situations where it’s more desirable to land in Mozilla Central first. In these cases, the patches must be backported to GitHub as soon as the intervention is shipped.  

Once the intervention is reviewed by a [[https://wiki.mozilla.org/Modules/All#WebCompat_Addons WebCompat Addon module peer]] and landed, one or more of the following shipping scenarios is followed, depending on the affected platforms and products:

# Make sure the version number in manifest.json is incremented.

# Land the updated addon version in Mozilla Central via a bug in [https://bugzilla.mozilla.org/buglist.cgi?product=Web%20Compatibility&component=Interventions&resolution=---&list_id=15330878 Web Compatibility::Interventions]  

# That’s it. Let the code ride the trains.

{{todo| make sure this is up to date with the new mozilla-extensions github actions workflow|mike}}

# File a bug to ship the addon via Balrog in the [https://bugzilla.mozilla.org/buglist.cgi?product=Web%20Compatibility&component=Interventions&resolution=---&list_id=15330878 Web Compatibility::Interventions] component

## File a bug to remove the addon from Balrog in the [https://bugzilla.mozilla.org/describecomponents.cgi?product=Firefox&component=System%20Add-ons%3A%20Off-train%20Deployment#System%20Add-ons%3A%20Off-train%20Deployment Firefox::System Add-ons: Off-train Deployment] component. This should happen when the next addon version rides to release, otherwise it will be overridden by the older version in Balrog. e.g., [https://bugzilla.mozilla.org/show_bug.cgi?id=1587186 Bug 1587186].

The process for Fennec will match Desktop, except the patches need to be written against the ESR branch.  

The system addon is served as a component. Currently [https://github.com/mozilla-mobile/fenix/blob/f5f0cb8d9caf556db586b248856a17e7052a4fa3/buildSrc/src/main/java/Dependencies.kt#L138 Fenix pulls in the latest version], which means the updated addon should be served in the next Google Play Store update.

{{todo| depending on how updated android components are released in Fenix, there may not be a difference between high and low priority releases. But if there is, we need to find out how to ask for an urgent version release...ideally before we need it}}

* [ ] Verify addon version has been incremented

* [ ] WebCompat QA marks each Bugzilla bug associated with the release as VERIFIED

When the new addon version is released everywhere and there will be no more changes to that version, there are a couple of follow-up steps to do in preparation for the next release cycle.