User:Bhearsum/Beta Release Checklist

From MozillaWiki
Jump to: navigation, search

Draft for a beta release checklist.


Update the calendar

Usually we ship beta 1 at the beginning of the week, then in the second week to the fifth week, ship two betas per week for Desktop, one for Mobile. The last week will be the Release Candidate (RC) version (Desktop only) and should be on beta for the week before release.

Mobile What's New Page

A week before beta 1, identify 3 new features that you want to highlight in GP

Check worry list

Use a worry list to keep track of bugs that should land before each beta cycle and the status of new features. This could be especially useful for handoff to other release managers.

Prep for channel meetings

The release manager who owns the current beta usually runs the two channel meetings starting with beta 2. (During release week, best for the release owner to run it)

Check approval requests

Go to build

  • Prepare for starting the build by going through approvals (the night before).
  • Check treeherder to make sure the changeset you want to use looks good. Talk with the sheriffs if you need them to merge more changes. From the time of the merge, treeherder needs at least 3 hours to complete all its tests.
  • Prepare the build from ship-it.
  • Make sure the changeset you're using for the build looks good on treeherder.
    • For desktop, now that we are using build promotion, put the long commit number instead of the short one. You get it like this:
      • ~/dev/mozilla-beta: hg --debug id -r bbaf0ef3deea
      • (result:) bbaf0ef3deea8b2989eb5a23be9861cf3e08720f beta/tip
      • Use bbaf0ef3deea8b2989eb5a23be9861cf3e08720f for the changeset in ship-it
  • Check again the Tree Status: https://treestatus.mozilla.org/
  • Start the build from ship-it.
  • Check for potential issues at the beginning of the build (release runner checks, hg issues, etc)
  • Communicate with QE if they should test anything in particular
  • Check QE's results the next day (Sign off emails)
  • Signoff on Scheduled Change in Balrog.
  • The Beta will be pushed automatically at the scheduled time. If you change your mind about shipping it, revoke your signoff in Balrog.
  • If it's a android release, use the mozapkpublisher Python app to manage the upload of the apk
    • Once it is done, email r-d that the android version was pushed.
  • Check that the release has been marked as "Shipped" on ship-it (we don't push this button, releng does). https://product-details.mozilla.org/1.0/firefox_versions.json & https://product-details.mozilla.org/1.0/mobile_versions.json should have the correct version of the beta. This is used by the website and other applications.

Set EARLY_BETA_OR_EARLIER

We change a flag after Beta 4 (usually even if this can change since we introduced variable length cycles).

  • Check out the mozilla-beta repo (this takes over an hour, the first time)
  • change the build/defines.sh file to read EARLY_BETA_OR_EARLIER= (unset the flag, from 1 to null) (nothing at all after the =) The process is documented in the Release calendar.
  • push your change directly to mozilla-beta (An exception to the usual Tree Rules). If you don't have l3 permissions, please ask to your manager to help with this.
  • So, Beta 4 is still early beta. Beta 5 is "after early beta".

Check about NSS

  • good idea to check in around mid beta with someone who works on nss to see if they are planning an update, and if it needs to also be in ESR. Canonical list of NSS versions shipped in which Firefox versions: https://kuix.de/mozilla/versions/

Check what's new page

At Beta 4, check on desktop and mobile what's new content.

Desktop

Make sure releng is aware of any upcoming What's New pages. This should be already managed in a bug and localizers should have been aware earlier in the release cycle. Try Eric Renaud for content and testing plans and coordinate with QE.

Examples:

MailTo: release@m.c (RelEng team) to communicate the final decision on whether a What's New Page is planned or not.

Before beta to release merge day

A week before we merge beta to release (so, around beta 10 or so) please check that the sec team (jcj or keeler) has bumped the expiration times of the preloaded HPKP pinning and strict-transport-security lists, for 54, so that they don't expire before the next release (giving plenty of time for release dates to slip). Example: bug 1364240. This will be in the public release calendar.

Mobile

For mobile, try to come up with two or three important changes for this cycle (from the features list or preliminary release notes). This will go on the Play Store front page for the app. You should get them to Delphine and the l10n team as soon as possible in the beta cycle so that they can localize this content. (TO DO: We should add this to the aurora process wiki page too)

Example: https://bugzilla.mozilla.org/show_bug.cgi?id=1335255

Other daily tasks

As part of a beta release manager, you should watch the following information:

  • Manage uplift requests
  • Keep the tracked list bug under control, find new assignee, ping them, their manager, component owners, etc
  • Accept/reject tracking request for your release (and manage also aurora & nightly)
  • Deal with regressions impacting your release: https://mozilla.github.io/releasehealth/?channel=beta
  • Check for firefox-relnotes new requests in bugzilla
  • Manage the list "Tuesday Jan 17 -- Fixed in 53, Affecting 52, 51 or 50" emails generated by autonag
    • Look for bugs that are fixed in Nightly/Aurora and ping devs to nominate for uplift to Beta

Check downloads page

While QE signs off for update testing, you may also want to:

RC builds

At the end of the beta cycle we do a release candidate or RC build.

  • Before the RC build, relman should send email to r-d, requesting the m-b to m-r merge. Anything for uplift to your release that hasn't landed on beta after that point will need to land on m-r. It is worth reminding folks of this and you will also need to check m-b and m-r uplifts and tracking requests for this week.
  • Relman does the final email to push the RC build live after QE signoff, as with beta 1. (While QE does the signoff alone for the other beta releases).
    • anything you uplift after the beta to release migration, make sure it lands on both m-b and m-r
    • Build fennec (10 or 12) from mozilla-beta. Upload to play store beta as usual
    • Build desktop RC from mozilla-release (and push it to the beta channel)
    • product details won't be updated for (desktop) RCs
    • The partial builds for RC1 should be the 2 previous releases with the highest ADI (but choose >= version 43 due to sha-1 deprecation), plus the latest beta. For example, for 44.0, partial builds were: 43.0.4build3, 41.0.2build2, 42.0build2, 44.0b9build1. (Using 4 partials overloaded taskcluster)
    • Subsequent RCs: ??
  • Later in the week (Tuesday or Wed.; the earlier, the more time QE has to test) do the mobile RC build from m-r (We don't push this anywhere)
Retrieved from "https://wiki.mozilla.org/index.php?title=User:Bhearsum/Beta_Release_Checklist&oldid=1172681"