Firefox Beta Release Checklist

From MozillaWiki
Jump to: navigation, search


Draft for a beta release checklist.

Before beta cycle begins

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.

Check Mobile What's New Page

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

During beta cycle

Staged Rollout - Dawn

For beta 55 we are trying a new staged rollout process. For now, here's a link to the current plan: https://docs.google.com/document/d/1TsZmxliz3i3FsCPXoPkCCqs6aFgmpYI0wc0vakLkfYg/edit

Dev edition builds

Starting with Firefox 55, we are shipping a dev edition build for each beta in parallel with beta builds. They have different branding and prefs. So, for each desktop beta, start a dev ed build in ship-it. QE doesn't need to sign off for this to ship (though they do some testing every couple of weeks - about as often as they tested aurora).

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 builds from ship-it.
    • for the desktop beta build, select an ETA later than the time you expect to go live (it can always be changed back later). WARNING: For RC builds, this should be the push-to-release date/time, NOT the push to beta
  • 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.


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:

End of cycle and move to release

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.

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 (as of Firefox 63) the last 4 shipped releases on mozilla-release (plus the last beta for x.0 RCs). For example, 63.0 build2 will suggest 63.0b14build1,62.0.3build1,62.0.2build1,62.0build2,61.0.2build1

They should be filled in automatically, but it's good to check that it's working correctly for RC and dot release builds.

    • Subsequent RCs: Much the same, but it is important to coordinate timing with #releaseduty and communicate with QA especially if timing is tight.
  • 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=Release_Management/Beta_Release_Checklist&oldid=1202571"