MozillaWiki

Compatibility/System Addon/Release Process: Difference between revisions

Page Discussion

Compatibility/System Addon/Release Process (view source)

Revision as of 17:29, 11 May 2022

1,726 bytes removed ,  11 May 2022
WIP of an updated version of the Release Process documentation.
m (DenSchub moved page Compatibility/Interventions Releases to Compatibility/System Addon/Release Process: This is about the WebCompat System Addon, and thus should be in the right namespace. Makes it easier to find.)
(WIP of an updated version of the Release Process documentation.)
Line 5: Line 5:
__TOC__  
__TOC__  


== Currently Released Interventions ==
Generally speaking, new interventions are landed in <tt>mozilla-central</tt> close to the start of each cycle's soft freeze period, and then ride the trains to Release. By essentially skipping the Nightly cycle, we speed up the process a bit, but we get some stability testing in Beta before the interventions are available to all users.


A usually up-to-date list of interventions currently shipped can be found with a search for [https://github.com/webcompat/web-bugs/issues?q=label%3Asitepatch-applied web-bugs issues labeled with "sitepatch-applied"], and on Bugzilla with a search for [https://bugzilla.mozilla.org/buglist.cgi?v1=%5Bwebcompat%3Asitepatch-applied%5D&f1=status_whiteboard&o1=substring&query_format=advanced issues with the "[webcompat:sitepatch-applied<nowiki>]</nowiki>" whiteboard tag].
In cases that are more urgent, we can speed up the process by


= Interventions Release Process =
* uplifting interventions into Beta at any time during the cycle,
* uplifting the interventions into Release to be shipped with the next dot-release,
* shipping an interventions add-on update out-of-band.


''Note: for simplicity, interventions and UA overrides will be referred to solely as interventions in this section.''
It is up to each release's Interventions Owner to decide if a WebCompat bug is important enough to warrant a fast process.


== Intervention Types ==
== The normal process: Letting interventions ride the train ==
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 Dennis Schubert 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, beyond WebCompat Addon module peer or owner approval.
For low-priority interventions, the simplest way to ship is to land them in the tree and have them ride the trains like any code change.


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.
# Build and test the interventions as usual. Submit a Pull Request to the <tt>mozilla-extensions/webcompat</tt> GitHub repository that does include new interventions, but do not include a version number bump yet.
# Bump the version number in your local clone of the repo, but do not commit the change yet.
# Export your changed sources into your <tt>mozilla-central</tt> checkout. Check the [https://github.com/mozilla-extensions/webcompat-addon#readme addon's <tt>README.md</tt>] for instructions on how to use the tooling.
# Make sure <tt>./mach lint browser/extensions/webcompat</tt> passes. Since the on-GitHub lints are not exactly the same (primarily, <tt>eslint</tt> is missing), it's a good idea to run that every time.
# Submit the patch to Phabricator. You do not ''need'' to manually specify a reviewer: the <tt>webcompat-reviewers</tt> group will be added automatically, sending a notification to everyone in the team.
# Land the patch. Wait until the patch got merged into <tt>mozilla-central</tt> to make sure it doesn't get backed out immediately.
# Export the same sources into your local checkout of <tt>android-components</tt>. There is tooling to help you with that as well, see [https://github.com/mozilla-extensions/webcompat-addon#readme addon's <tt>README.md</tt>]. [https://github.com/mozilla-mobile/android-components/pull/11938 Example Pull Request]. To make it easier to keep track of, attach a link to the pull request to the corresponding bug on Bugzilla. If you don't know someone who can review your patch, ask in <tt>#fenix-team</tt> on Slack.
# When the patch is merged, you can commit the version number change in the <tt>webcompat-addon</tt> repository. Make sure to run <tt>npm run autoformat</tt> before commiting, as that will apply your version number change to <tt>package.json</tt> and <tt>package-lock.json</tt> as well.
# Tag the version with <tt>git tag -a v100.0.0 -m 'v100.0.0'</tt>, and push both your version-bump-commit, and the new tag, to GitHub with <tt>git push origin main v100.0.0</tt>
# Make sure that for any intervention you added, you set the <tt>sitepatch-applied</tt> label GitHub or the <tt><nowiki>
[webcompat:sitepatch-applied]</nowiki></tt> whiteboard flag on Bugzilla. Likewise, remove those labels for all interventions you removed.


== Shipping Scenarios ==
== Uplifting new interventions into Beta ==
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:
For interventions that are a bit more urgent, you can skip one release cycle and uplift your intervention(s) into Beta. However, '''do not just request beta uplift''' for the patch you submitted to <tt>mozilla-central</tt>:


=== Desktop Releases ===
* It is possible that your patch was not the only change to the addon since the Beta branch got merged. This would cause conflicts, because your new patch won't cleanly apply to Beta.
* Version numbers won't make sense: If you're uplifting a patch for the addon version <tt>101.0.0</tt> into Beta 100, you might make version numbers more confusing, and you also will make rolling out of-of-band updates a bit more complicated.
* It generally is a good idea to limit your Beta uplift to only the important/urgent things. It might not be a wise idea to uplift everything, which might include logic changes, SmartBlock Fixes, and other changes into beta. Keep the risk as low as possible.


==== Low Priority ====
Instead, we generally build a separate patch just for Beta.
# 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]
## Export the sources into mozilla-central using the [https://github.com/mozilla-extensions/webcompat-addon#exporting-the-sources-to-mozilla-central export-mc jake command].
## Create a patch for mozilla-central, upload it to Phabricator, and have a WebCompat Addon module peer review that.
# That’s it. Let the code ride the trains.


==== High Priority ====
# Follow the "normal process", and get your interventions landed in <tt>mozilla-central</tt>. Wait for the next Nightly build, and make sure your interventions work as you expect.
{{todo| make sure this is up to date with the new mozilla-extensions github actions workflow when work is done|denschub}}
# In your local <tt>mozilla-central</tt> checkout, switch to the <tt>mozilla-beta</tt> branch/bookmark. If you've never done this before, check [https://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/unifiedrepo.html the documentation explaining how to work with the <tt>mozilla-unified</tt> repository].
# Apply the relevant changes to the Firefox sources.
#* If your patch is simple, you can apply the changes directly to your <tt>mozilla-beta</tt> tree.
#* If your changes are more complicated, it might be a good idea to use the export tooling in our GitHub repo. You can <tt>git checkout</tt> the tag corresponding to the version currently shipping in Beta, and then <tt>git cherry-pick</tt> individual patches from <tt>main</tt> into your temporary branch. There is no need to publish/merge that branch upstream, as your beta rollout should never include any interventions that aren't also in the <tt>main</tt> branch anyway.
# Publish the beta patch to Phabricator and have a webcompat-reviewer rubberstamp the patch. It is a good idea to add a clear indication into the commit message saying that this patch is meant for the Beta branch. <tt>Bug 1234567 - Beta - Uplift v101 Interventions into v100 Beta.</tt> is an example.
# Set the <tt>approval-mozilla-release?</tt> request flag, and explain in the comment why you think this patch should be uplifted to Beta.


Changes to the Interventions Add-on can be directly deployed to release-users, which allows for interventions that do not require a dot-release. System Addon rollouts go into effect immediately after launching it, with the first Firefox users picking up the update within an hour. The majority of users will have received the update within five days.
A release manager will see your request. If your request is approved, the release managers will push your patch. You do not need to land it, or do anything else!


A current overview of the high-level steps required to ship via ShipIt can be found [https://docs.google.com/document/d/1AsyiOPDMVjWhDUD0fcdNw-kgLn8iLX_5DSVOvQk8TtQ/ this Google Doc (Mozilla-internal)]. Ping :denschub if something needs to be rolled out urgently.
== Uplifting new interventions into Release ==


==== Fenix / Android Components ====
If you want your interventions to be available to users very quickly, you can uplift them into <tt>mozilla-release</tt> and have it shipped in the next dot-release.
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.


# Export the sources into the android-components repo using the [https://github.com/mozilla-extensions/webcompat-addon#exporting-the-sources-into-android-components export-ac export command].
# There is no fixed schedule for dot-releases, but you can reach out to the [[Release_Management/Release_owners|Release Owner]] and ask if a dot release is planned, and when it will be shipping. If there is a dot release coming up that fits your needs, let them know that you intend to ship WebCompat interventions in that release.
# 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. Any core member of the mozilla-mobile organization is happy to help, but :csadilek frequently reviews our changes, so he should be the first point of contact if possible.
# Get your interventions into <tt>mozilla-central</tt> first, using the "normal process" explained above. Make sure it works!
# That’s it. The new version will be used when the new android-components version is released (currently weekly).
# Then, you can follow the "uplifting into Beta" steps. The steps for Beta and Release are exactly the same, except that you're using a different branch/bookmark: <tt>mozilla-release</tt> instead of <tt>mozilla-beta</tt>.
# You can request uplift for Beta and Release at the same time, but since these are two different patches, you have to request both uplifts separately in two comments.


==== Firefox iOS ====
== Shipping interventions with an out-of-band System Addon Update ==


Firefox iOS has currently a [https://github.com/mozilla-mobile/firefox-ios/blob/41cc4065ea6f799bd0930e117c6ab3b2f8ee8447/Shared/UserAgent.swift very light UA override mechanism] (at the time of this writing).
'''To be done'''. :denschub is typing this at the moment.
 
We [[Firefox iOS UA Override|need to define]] in cooperation with the Firefox iOS Team on how to remove the pain for users. Most of the issues are identified through webcompat reporting.
 
=== 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
* [ ] 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.


= Interventions Release Rotations =  
= Interventions Release Rotations =  
Engineers on the Web Compatibility team will rotate on ownership of shipping new versions of our interventions addons, serving as an Intervention Release Owner (IRO). The process will follow a predictable 4 week schedule, mirroring the proposed 4 week [[Release_Management/Calendar|Firefox release schedule]], however, we will attempt to land the interventions 1 week before soft freeze (see the schedule above for dates). Another way to look at this is 2 weeks before release.


A tracking bug for the next release should be filed in Bugzilla (in the [[ & Tooling|Web Compatibility::Interventions]] component). Bugs for adding or removing interventions in the current release cycle should block this bug.
Engineers on the Web Compatibility team will rotate on ownership of shipping new versions of our interventions addons, serving as an Intervention Release Owner (IRO). The process will follow a predictable 4 week schedule, mirroring the [[Release_Management/Calendar|Firefox release schedule]]. However, we will attempt to land the interventions 1 week before soft freeze (see the schedule above for dates). Another way to look at this is 2 weeks before release.  


During bug diagnosis, if a site is identified as a low priority intervention candidate, a [https://github.com/webcompat/web-bugs/labels/action-needssitepatch label is added] for the next IRO to take care of during their rotation. Low priority interventions ride the trains without any need for uplifts or out of band shipping mechanisms. The expectation is that there will be a single regular low-priority release for each version of Firefox, driven by the IRO.  
A tracking bug for the next release should be filed in Bugzilla (in the [https://bugzilla.mozilla.org/enter_bug.cgi?product=Web%20Compatibility&component=Interventions <tt>Web Compatibility::Interventions</tt> component]). Bugs for adding or removing interventions in the current release cycle should block this bug.


High priority interventions should be flagged immediately to the IRO who will then begin the process necessary to ship an off-train intervention.
During bug diagnosis, if a site is identified as a low priority intervention candidate, a <tt>action-needssitepatch</tt> label is added for the next IRO to take care of during their rotation. High priority interventions should be flagged immediately to the IRO who will then begin the process necessary to ship an off-train intervention.
 
== Interventions Release Rotations ==
 
Engineers on the Web Compatibility team will rotate on ownership of shipping new versions of our interventions addons, serving as an Intervention Release Owner (IRO). The process will follow a predictable 4 week schedule, mirroring the proposed 4 week Firefox release schedule.
 
During bug diagnosis, if a site is identified as a low priority intervention candidate, a label shall be added for the IRO to take care of during their rotation. Low priority interventions ride the trains without any need for uplifts or out of band shipping mechanisms. The expectation is that there will be a single regular low-priority release for each version of Firefox, driven by the IRO.
 
High priority interventions should be flagged immediately to the IRO who will then begin the process necessary to ship an off-train intervention.


== Candidates for interventions ==
== Candidates for interventions ==
There is a [https://github.com/webcompat/web-bugs/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Aaction-needssitepatch list of sites] as well as a [https://bugzilla.mozilla.org/buglist.cgi?product=Web%20Compatibility&component=Interventions&resolution=---&list_id=15328531 Bugzilla bug query] for sites that need interventions. In addition, the [https://github.com/webcompat/web-bugs/issues?q=is%3Aissue+is%3Aopen+label%3Atype-uaoverride+ `type-uaoverride`] label may be useful to look at. During a rotation, you should look at both of these sites and determine which are the most important to work on and ship (or close, if appropriate).
Lists of currently deployed interventions across the products and channels are available here https://arewehotfixingthewebyet.com/.
In addition, there is also a [https://github.com/webcompat/web-bugs/issues?q=is%3Aissue+label%3Asitepatch-applied `sitepatch-applied`] label that helps to keep track of existing interventions. Take care to add this to bugs after shipping a site patch.
== IRO Rotation Responsibilities ==
* Authoring, testing, landing high priority intervention patches
* Authoring, testing, landing normal priority interventions
* Requesting testing of high risk interventions from the WebCompat QA team
* Coordinating QA verification and release stakeholders (Balrog, AC, etc) for high priority interventions
* Sending an intent-to-ship email for high priority intervention patches
* Landing patches in GitHub, Mozilla Central, and Android Components repos
* Requesting uplifts for interventions when necessary
* Backporting interventions from mozilla-central where necessary (see [https://github.com/mozilla/webcompat-addon/wiki/Backporting-a-mozilla-central-patch Backporting a Mozilla Central Patch]).
* Handling potential regression fallout from interventions
* Add sitepatch-applied labels to web-bugs issues, as relevant.
== Intervention Release Owner Schedule ==


For simplicity, we rotate on a per-release following the Nightly schedule at [[Release_Management/Calendar|Firefox Release Calendar]].
There is a [https://github.com/webcompat/web-bugs/issues?q=label%3Aaction-needssitepatch dedicated <tt>action-needssitepatch</tt> label on GitHub] as well as a [https://bugzilla.mozilla.org/buglist.cgi?product=Web%20Compatibility&component=Interventions&resolution=--- Bugzilla bug query] for sites that need interventions. During a rotation, you should look at both of these sites and determine which are the most important to work on and ship (or close, if appropriate).


=== Upcoming Releases ===
== Upcoming Releases ==


* [https://bugzilla.mozilla.org/show_bug.cgi?id=1752989 Version 102] - Ksenia 2022-05-26 2022H1
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1752989 Version 102] - Ksenia 2022-05-26 2022H1
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1752990 Version 103] - Tom 2022-06-23 2022H1
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1752990 Version 103] - Tom 2022-06-23 2022H1


=== Past Releases ===
== Past Releases ==


* Firefox 74 (v7) - Ksenia
* Firefox 74 (v7) - Ksenia
DenSchub
202

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1242355"