Release Management/ESR Landing Process
Goal: We'd like to have a lightweight process that prevents "surprise" ESR landings at the 11th hour and makes sure ESR patches are created very soon after their related mainline patches
The ESR repo: https://hg.mozilla.org/releases/mozilla-esr10/
More info about the ESR: https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal and https://www.mozilla.org/en-US/firefox/organizations/
What should land on mozilla-esr10: Security and some major stability fixes when they're landed/merged onto mozilla-beta, or fixes for regressions specific to the ESR
The associated flags:
approval-mozilla-esr10
- ?
- +
- -
tracking-esr10
- ?
- -
- 11+
- 12+
- 13+
- ...
status-esr10
- ?
- unaffected
- wontfix
- affected
- checkin-pending
- fixed
- verified
The process:
1) When an engineer believes that a stability bug needs to be addressed for the ESR, or a security fix that's landed on a branch affects the ESR:
- Set tracking-esr10 to ?
- Set status-esr10 to affected if an ESR patch is still being worked on
- Set approval-mozilla-esr10 to ? and status-esr10 checkin-pending if a patch is ready to land on mozilla-esr10
2) Members of both Security and Release Management teams will triage tracking-esr10=?, and if agreement is that it's needed for the ESR, the tracking flag will be set to the first version of mainline Firefox that the patch is present in and the approval-mozilla-esr10 flag will be set to +.
- In the case of an ESR-specific regression, we'll track for the next ESR release.
- Why are we using mainline versions to track the ESR? According to the ESR proposal, a chemspill uses a minor version number, thus throwing off our tracking flags. Additionally, engineers shouldn't have to know what version of the ESR we're on.
3) Once the mozilla-beta version matches the tracking-esr10 version, Security and Release Management teams will triage those bugs and make sure affected/checkin-pending fixes are landed at least 1 week prior to release so that we can go-to-build.
- Approval is required, so add "a={whoever set the approval-mozilla-esr10 flag to +}" to the commit message.
- After landing the patch, set status-esr10 to "fixed".
- Our beta period for the ESR will be to push this build to FTP a week early for qualification by enterprises.
ESR Triage Queries
ESR10
- ESR Nominations - track for an upcoming ESR release, or don't track at all
- ESR-10 approval requests - approve/deny, make sure 150+ is set
- Security bugs fixed on mainline, status not marked for ESR - mark the ESR as affected/unaffected
- Bugs marked as affected for ESR, but not tracked - track for a release or wontfix
- May need to land now - 150+ if necessary, or wontfix
- Also may need to land now
- Bugs that need to be fixed on ESR this cycle - follow up with the engineers
- Tracked, but not for a specific version - follow up and decide on what version of the ESR these fixes should go into
ESR17
- ESR17 Nominations - track for an upcoming ESR release, or don't track at all
- ESR-17 approval requests - approve/deny, make sure 150+ is set
- Security bugs fixed on mainline, status not marked for ESR17 - mark the ESR as affected/unaffected
- Bugs marked as affected for ESR, but not tracked - track for a release or wontfix
- May need to land now - 150+ if necessary, or wontfix
- Also may need to land now
- Bugs that need to be fixed on ESR17 this cycle - follow up with the engineers
- Tracked, but not for a specific version - follow up and decide on what version of the ESR these fixes should go into