Confirmed users
796
edits
Compatibility/System Addon/Override Policies and Workflows: Difference between revisions
Jump to navigation
Jump to search
Compatibility/System Addon/Override Policies and Workflows (view source)
Revision as of 19:02, 10 July 2020
, 10 July 2020Add Interventions Release Process section
m (Tweak heading levels depth) |
(Add Interventions Release Process section) |
||
| Line 93: | Line 93: | ||
In addition, the injection file has to be registered in the array located in [https://github.com/mozilla/webcompat-addon/blob/master/src/data/injections.js rc/data/injections.js]. Details on available parameters can be found [https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/content_scripts in the MDN web docs]. | In addition, the injection file has to be registered in the array located in [https://github.com/mozilla/webcompat-addon/blob/master/src/data/injections.js rc/data/injections.js]. Details on available parameters can be found [https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/content_scripts in the MDN web docs]. | ||
= Interventions Release Process = | |||
''Note: for simplicity, interventions and UA overrides will be referred to solely as interventions in this section.'' | |||
=== Intervention Types === | |||
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. | |||
Low priority interventions should be landed in the [https://github.com/mozilla-extensions/webcompat-addon Mozilla webcompat-addon repo] on GitHub and upstreamed to the relevant tree once per release. These do not require outside collaboration or approval to ship (except for the case of Fennec ESR, which will require Relman uplift to the ESR branch while it exists as a supported product), beyond WebCompat Addon module peer or owner approval. | |||
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. | |||
=== Shipping Scenarios === | |||
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: | |||
==== Desktop Releases ==== | |||
===== Low Priority ===== | |||
# 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. | |||
===== High Priority ===== | |||
{{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 | |||
# Attach an XPI for the WebCompat QA team to test locally using the following naming convention: webcompat-N.N.N.unsigned.xpi | |||
# When testing, QA can use an unbranded build, or Nightly. | |||
# Describe how QA can test and verify the intervention in a comment | |||
# QA will test and leave a comment with their findings: either sign-off, or describing unexpected behavior that needs to be investigated. | |||
# Request the signed addon be staged to the release-sysaddon channel by :rdalal | |||
# Ask QA to verify the release-sysaddon update works (instructions here), and the intervention works as expected | |||
# Once QA signs off, request Relman for signoff in Balrog (a needinfo request in the bug is sufficient) | |||
# Once the addon ships to release: | |||
## Land the addon in Mozilla Central and request Beta uplift | |||
## 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]. | |||
==== Mobile Releases ==== | |||
===== Fennec ESR ===== | |||
The process for Fennec will match Desktop, except the patches need to be written against the ESR branch. | |||
'''Low Priority''': Relman will need to approve ESR uplift for the next ESR release once the patch has landed in the ESR branch. This happens in Bugzilla by requesting ESR approval for the patch. | |||
'''High Priority''': Follow the same steps as Desktop High Priority. | |||
===== Fenix / Android Components ===== | |||
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. | |||
# File an issue and open a pull request against the [https://github.com/mozilla-mobile/android-components Android Components repo] on GitHub which contains the updated addon and request review. Currently Dennis Schubert and Mike Taylor can review and merge, as well as any core member of the mozilla-mobile organization. | |||
# That’s it. The new version will be used when the new android-components version is released (currently weekly). | |||
{{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}} | |||
==== Final Checklist when shipping a release ==== | |||
* [ ] Verify addon version has been incremented | |||
* [ ] Verify new intervention(s) appears in about:compat as expected | |||
* [ ] Close all Bugzilla bugs with interventions associated with the current release | |||
* [ ] WebCompat QA has signed off on XPI | |||
* [ ] Balrog folks have uploaded XPI | |||
* [ ] Relman has signed off on XPI in Balrog | |||
* [ ] Fennec ESR uplift request, when relevant | |||
* [ ] Desktop ESR uplift request, when relevant | |||
* [ ] m-c beta or ESR uplift request, when relevant | |||
* [ ] Intent to Ship email is sent to release-drivers@ mailing list for high priority releases | |||
* [ ] WebCompat QA marks each Bugzilla bug associated with the release as VERIFIED | |||
==== Checklist for follow-ups after landing/deploying everywhere ==== | |||
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. | |||
* [ ] Tag the version on GitHub with `git tag -a v8.0.0 -m 'v8.0.0'` and push the tags with `git push --tags` so we have a persistent record of "what shipped when" on GitHub as well. | |||
= Open points for further discussion = | = Open points for further discussion = | ||