Thunderbird/Release Driving/Final Release Checklist

From MozillaWiki
Jump to: navigation, search

Things to consider in in releases after TB 3.1

  • Offer a MU to beta channel testers either for the last beta or the first RC.

At around the time of final Beta

The final beta is generally also expected to be the feature freeze and API freeze, therefore there are a number of things that can happen.

Add-ons

Localisations (product)

  • Ensure string changes are finialised.
  • Open up for sign-offs as soon as possible, to encourage locales to update and complete their localisations.

Website

en-US

The first four of these need to be done asap, so that locales can start getting the pages translated:

  1. Details page - Done http://trunk.mozillamessaging.com/en-US/thunderbird/3.1/details/
  2. Home/Landing page - Done http://trunk.mozillamessaging.com/en-US/
  3. Product page - Done http://trunk.mozillamessaging.com/en-US/thunderbird/
  4. Features page - Done http://trunk.mozillamessaging.com/en-US/thunderbird/features
  5. What's New page - Done http://trunk.mozillamessaging.com/en-US/thunderbird/3.1/whatsnew/
  6. Release Notes - In Progress eta June 11, 2010 http://trunk.mozillamessaging.com/en-US/thunderbird/3.1/releasenotes/
  7. Write announcement texts - In Progress

Note: Start page (experimenting with content in en-US, current page can stay the same for Tb 3.1) http://trunk.mozillamessaging.com/en-US/thunderbird/3.1/start/

Localisations (website)

  • As soon as the first five of en-US are done, raise bugs on all the locales and get them working on updates.
    • The more time the locales have the better, as they are frequently pushed for time.

Release Candidates

Before the release

  • Determine the gecko version to use for the release
    • Normally prefer to use non-branched versions, without the pre.
  • Hook the tinderboxes onto that version, so that the nightlies are the same

Actual release

After rc1 release

  • Set useBetaChannel to 1 in release_thunderbird_<version>.py in buildbot-configs
    • So that update snippets get produced on both beta and release channels.
  • Update the patcher config file (e.g. moz192-thunderbird-branch-patcher2.cfg) to include the releasetest channel for the current update.

After release

  • Monitor feedback from release candidates
  • Keep an eye on crash-stats for potential issues

Final release

Preparation

  • Decision to go - the whole team.
    • Set date
    • Take into account:
      • l10n readiness
      • RC feedback
      • Website readiness
      • Holidays, best dates etc
    • Notify PR, release-drivers, thunderbird-drivers, bouncers, other builds list
  • File bug for bouncer entries
    • Get sentry updated
  • Finish revised web site
    • QA
  • Generate Major Updates on betatest & releasetest channels?
    • Ensure throttling is at 100%
    • Ensure updates are not offered to obsolete platforms, if they are, get aus updated.
    • QA
  • Re-tag the builds with the THUNDERBIRD_<version>_RELEASE tag
    • XXX do we need to rebuild the source file here?

Actual Release

  • Release Process
    • Bits to mirrors - Project lead sends "go email" - note that builds will take 1-2 hours to filter through to the mirrors.
      • Push actual bits - Build lead
    • Verify Major Update bits on releasetest channel - QA Lead
    • Push website changes - Project lead
    • QA verifies website changes - QA Lead
    • Build pushes to release channel - Build lead
      • Ensure MUs are fully throttled.
    • QA verifies release channel - QA Lead
    • Coordinate final drafts of Knowledge Base Articles - Support Lead
  • Notify the world - Project lead
    • all -at- mozilla.com (so all MoCo staff knows) (apparently this doesn't currently happen)
    • staff -at- mozillamessaging.com (so all MoMo staff knows)
    • m.dev.planning newsgroup
    • m.announce newsgroup (all product release announcements are expected here)
    • MDC Devnews
    • Company Update on Get Satisfaction
    • Email metrics mozilla.com with the new version details.

Post Release tidy up

  • Ensure [gs] bugs fixed in the major release have getsatisfaction updated with the fact.

Unthrottling MUs

  • Monitor feedback from release
    • Watch ADU numbers
    • Watch crash-stats
    • Watch feedback
    • Check add-on compatibility
  • Ensure localizations have localized the MU and in-product pages.
  • Decide if a .1 is necessary before unthrottling.
  • Decision to go - whole team
  • Unthrottle, possibly just a small % first to obtain feedback.
  • Keep watching numbers and feedback
  • Repeat as necessary
Retrieved from "https://wiki.mozilla.org/index.php?title=Thunderbird/Release_Driving/Final_Release_Checklist&oldid=253103"