Confirmed users
796
edits
m (fix nesting levels) |
(Add Interventions Release Rotations section) |
||
Line 167: | Line 167: | ||
* [ ] 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. | * [ ] 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 = | |||
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. | |||
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. | |||
High priority interventions should be flagged immediately to the IRO who will then begin the process necessary to ship an off-train intervention. | |||
== IRO Rotation Responsibilities == | |||
* Authoring, testing, landing high priority intervention patches | |||
* Authoring, testing, landing normal priority interventions (see Candidates for interventions section below) | |||
* 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 where necessary | |||
* Handling potential regression fallout from interventions | |||
* Add sitepatch-applied labels to web-bugs issues, as relevant. | |||
=== 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. | |||