Release Management/Beta Release Checklist: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (added a step to make sure to talk with releng about whatsnew pages)
(→‎Other activities: removed my what's new page write up as Liz added another one)
Line 48: Line 48:
** Look for bugs that are fixed in Nightly/Aurora and ping devs to nominate for uplift to Beta
** Look for bugs that are fixed in Nightly/Aurora and ping devs to nominate for uplift to Beta
** Look for bugs that haven't had much activity for a while and work with devs to find owners to fix.
** Look for bugs that haven't had much activity for a while and work with devs to find owners to fix.
* Follow up to see if there will be a What's New page and when it will be ready
** Details - TBD


[[Category:Release_Management]]
[[Category:Release_Management]]

Revision as of 19:43, 1 September 2015

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. The last week will be the Release Candidate (RC) version and should be on beta for the week before release.

Check worry list

Use a worry list etherpad 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 meeting

The release manager who owns the current beta usually runs the channel meeting.

Check approval requests

  • Good to do these in small batches every day.
  • Consider stabilizing the beta patches as much as possible over Nightly and Aurora channels.

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.
  • Make sure to create a new l10n milestone for each beta build.
  • Check Tree Status: https://treestatus.mozilla.org/
  • Start the build from ship-it.
  • Communicate with QE if they should test anything in particular
  • Check QE's results the next day
  • Release your new beta version (If QE signs off, this happens without RelMan's intervention)
  • update [product details]
  • add release notes

Set EARLY_BETA_OR_EARLIER

We change a flag for Beta 4 (usually).

  • 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 =)
  • commit locally with a useful commit message like this, "Post Beta 4: disable EARLY_BETA_OR_EARLIER a=me"
  • push your change directly to mozilla-beta (An exception to the usual Tree Rules

Check what's new page

At Beta 4 this may be a good time to 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. Examples:

Update PRODUCT DETAILS

Other activities

  • Regular follow up on tracked bugs with the following intentions:
    • Look for bugs that are fixed in Nightly/Aurora and ping devs to nominate for uplift to Beta
    • Look for bugs that haven't had much activity for a while and work with devs to find owners to fix.
Retrieved from "https://wiki.mozilla.org/index.php?title=Release_Management/Beta_Release_Checklist&oldid=1093274"