Release Management/ESR Landing Process: Difference between revisions

'''The ESR{{ESR_CURRENT}} repo:''' https://hg.mozilla.org/releases/mozilla-esr{{ESR_CURRENT}}/

'''The ESR{{ESR_NEXT}} repo:''' https://hg.mozilla.org/releases/mozilla-esr{{ESR_NEXT}}/

===What should land on mozilla-esr{{ESR_CURRENT}}/mozilla-esr{{ESR_NEXT}}===

Security and some major stability fixes when they're landed/merged onto mozilla-beta, or fixes for regressions specific to the ESR. In the first few cycles of ESR we may be more flexible on these criteria. As the versions progress we should limit this to the most critical security fixes.  

Exception: If patches only make changes to tests, test harnesses or anything else that does not affect the shipped builds, they may land with self approval (use a=testonly, a=npotb etc).

approval-mozilla-esr{{ESR_CURRENT}}: ''?'', ''+'', ''-''

 

 

tracking-esr{{ESR_NEXT}}: ''?'', ''-'', ''{{BETA_VERSION}}+'', ''{{NIGHTLY_VERSION}}+'', ...

status-esr{{ESR_CURRENT}}: ''?'', ''unaffected'', ''wontfix'', ''affected'', ''checkin-pending'', ''fixed'', ''verified''

status-esr{{ESR_NEXT}}: ''?'', ''unaffected'', ''wontfix'', ''affected'', ''checkin-pending'', ''fixed'', ''verified''

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 '''status-firefox-esr{{ESR_CURRENT}}''' (and if we're in the middle of supporting 2 versions, then also status-firefox-esr{{ESR_NEXT}}) to '''affected''' if an ESR patch is still being worked on

* Set '''approval-mozilla-esr{{ESR_CURRENT}}''' (and if we're in the middle of support 2 versions, then also approval-mozilla-esr{{ESR_NEXT}}) to '''?''' and '''status-firefox-esr{{ESR_CURRENT}}/{{ESR_NEXT}}''' to '''checkin-pending''' if a patch is ''ready to land on mozilla-esr{{ESR_CURRENT}}/{{ESR_NEXT}}''

2) Members of both Security and Release Management teams will triage tracking-firefox-esr{{ESR_CURRENT}}/{{ESR_NEXT}}=?, 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-esr{{ESR_CURRENT}}/{{ESR_NEXT}}''' 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-firefox-esr{{ESR_CURRENT}}/{{ESR_NEXT}} version(s), 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-esr{{ESR_CURRENT}} flag to +}" to the commit message.

* Our beta period for the ESR will be to push this build to FTP a week early for qualification by enterprises.

 

 

 

 

 

 

* [https://bugzilla.mozilla.org/buglist.cgi?o0=equals&f0=cf_tracking_firefox_esr{{ESR_CURRENT}}&v0=%3F ESR{{ESR_CURRENT}} Nominations] - track for an upcoming ESR release, or don't track at all

* [https://bugzilla.mozilla.org/buglist.cgi?o0=substring&f0=flagtypes.name&v0=approval-mozilla-esr{{ESR_CURRENT}}%3F ESR-{{ESR_CURRENT}} approval requests] - approve/deny, make sure {{BETA_VERSION}}+ is set

 

** [https://bugzilla.mozilla.org/buglist.cgi?keywords=sec-other%20sec-want%20sec-low&keywords_type=nowords&f4=cf_last_resolved&o4=greaterthan&v4={{ESR_BRANCH_DATE}}&f0=product&o0=nowordssubstr&v0=Boot2Gecko%20Testing20SeaMonkey%20Plugins%20iOS&f1=bug_group&o1=substring&v1=core-security&f3=cf_status_firefox{{ESR_CURRENT}}&o3=nowordssubstr&v3=unaffected%20verified%20fixed%20disabled&resolution=FIXED&o2=nowordssubstr&f2=cf_status_firefox_esr{{ESR_CURRENT}}&v2=unaffected%20wontfix%20verified%20fixed%20affected%20disabled&list_id=12669803 As the top, including Tbird, FxOS, excluding sec-lows]

 

 

 

* [https://bugzilla.mozilla.org/buglist.cgi?f1=cf_tracking_firefox_esr{{ESR_CURRENT}}&o1=equals&o2=nowordssubstr&f2=cf_status_firefox_esr{{ESR_CURRENT}}&v1={{BETA_VERSION}}%2B&v2=fixed%20verified%20disabled%20wontfix%20unaffected Bugs that need to be fixed on ESR{{ESR_CURRENT}} this cycle] - follow up with the engineers

* [https://bugzilla.mozilla.org/buglist.cgi?f1=cf_tracking_firefox_esr{{ESR_CURRENT}}&o1=equals&o2=nowordssubstr&f2=cf_status_firefox_esr{{ESR_CURRENT}}&v1=%2B&v2=%20fixed%20verified Tracked, but not for a specific version] - follow up and decide on what version of the ESR these fixes should go into

 

'''Note: not useful until Firefox {{ESR_NEXT}} is on Beta'''

* [https://bugzilla.mozilla.org/buglist.cgi?o0=equals&f0=cf_tracking_firefox_esr{{ESR_NEXT}}&v0=%3F ESR{{ESR_NEXT}} Nominations] - track for an upcoming ESR release, or don't track at all

 

** [https://bugzilla.mozilla.org/buglist.cgi?keywords=sec-other%20sec-want%20sec-low&keywords_type=nowords&f4=cf_last_resolved&o4=greaterthan&v4={{ESR_NEXT_BRANCH_DATE}}&f0=product&o0=nowordssubstr&v0=Boot2Gecko%20Testing20SeaMonkey%20Plugins%20iOS&f1=bug_group&o1=substring&v1=core-security&f3=cf_status_firefox{{ESR_NEXT}}&o3=nowordssubstr&v3=unaffected%20verified%20fixed%20disabled&resolution=FIXED&o2=nowordssubstr&f2=cf_status_firefox_esr{{ESR_NEXT}}&v2=unaffected%20wontfix%20verified%20fixed%20affected%20disabled&list_id=12669806 As the top, including Tbird, FxOS, excluding sec-lows]

 

 

 

=== Week 4 ===  

 

Mon:

# Kick off RC build in ship-it

# Send [[Release_Management/ESR_Landing_Process#Go_To_Build_for_ESR_Candidate|go to build e-mail]] for ESR candidate to release-drivers. (This happens automatically if you fill in the form in ship-it)

# Create release notes in Nucleus

Monday: ESR sign off on esr-localtest channel should have been received, so now email release-drivers list to request the push to esr-cdntest (more on these channels in [[Releases/Update_Channels]].

All happens after mainline release goes live (usually 8am Pacific time)

# You must have received sign off for esr-cdntest updates from QA

# Mark release notes as public in Nucleus

# Update [http://viewvc.svn.mozilla.org/vc/libs/product-details/history product details in SVN] ([[Release_Management/Release_Notes_and_Product_Details|instructions]]; add the version to history/firefoxHistory.class.php and update the constant in FIREFOX_ESR.php)

# Add release to [[Releases|historical releases page]]

# Post [[Release_Management/ESR_Landing_Process#Release_Announcement|release announcement]] to enterprise mailing list

# Update as needed the wiki template values - [[Release_Management/ESR_Landing_Process#CURRENT_TEMPLATE_VALUES]] - at the very least you are bumping the dot version of the current ESR

# File bugs in the BMO: Adminstration component to create and remove ESR related tracking flags and attachment flags at the boundaries between major versions. Examples can be found in this bugzilla query: https://bugzilla.mozilla.org/buglist.cgi?list_id=12657880&short_desc=esr%20flag&resolution=FIXED&query_format=advanced&short_desc_type=allwordssubstr

== Sample E-mails ==

=== Smoke Test Request ===

<pre style="white-space:pre-wrap;">

Subject: Request: Smoke Test Firefox {{ESR_NEXT}}esr

As we approach the ESR {{ESR_NEXT}} release date of {{FIREFOX_SHIP_DATE}}, we'd like your help in smoke testing the latest pre-release builds. Our request is not for full qualification of the builds but rather exploratory testing of internal websites and applications for which our QA team does not have access.

Please file bugs for any critical regressions that you find in Bugzilla and make sure to set the need-info? flag on release-mgmt at mozilla.com <mailto:release-mgmt at mozilla.com> in order to alert the release management team to the issues. Alternatively, you can directly email release-mgmt at mozilla.com <mailto:release-mgmt at mozilla.com> or this list.

Thank you for your continued support in ensuring high quality ESR releases.