Thunderbird/Release Driving/Beta Release Checklist

This is the general release checklist we should use for Thunderbird Alpha and Beta releases, and also Release Candidates.

It is based largely on Releases/Checklist but adapted specifically for Thunderbird.

It is organized by major functional activity in roughly chronological order. At the end of each bullet is the owner of the checklist item from within the Release Team.

Team

• Project/Dev lead: Standard8
• Build lead: gozer
• QA lead: _Tsk_
• Website lead: rebron
• Support Lead: Roland

Checklist

Improve our processes! File bugs for improvements against bug 540394

Initial Stages

• Meet and schedule release - Entire team
  • Project lead organises meeting/discussing. May typically be at driver meetings, but other mediums can be used if felt necessary - Project lead

• Decision on release date - Entire team
  • Update Releases page - Project lead
  • Update Releases/PRODUCT&VERSION with proposed schedule - Project lead
  • Email thunderbird-drivers and post on Status Meeting (including weekly) with proposed schedule - Project lead

• Triage of blocking/approval requests as needed - Entire team (minus build)
  • Schedule meetings - Project lead
  • Alert developers of blockers - Project lead
  • Alert developers of upcoming freeze - Project lead

• Development code freeze - Dev lead

• Co-ordinate with l10n - Project lead
  • Ensure shipped-locales is updated (set to just en-US for Alpha)
  • Ensure relevant l10n-changesets files are updated.

• File bugs relating to the new alpha/beta release - Project lead

• Ensure in-tree extensions (Venkman, DOMI) have correct maximum version numbers - Project lead
  • Note: DOMI has a general rs=sdwilsh for update to current version on trunk.

• Ready for builds
  • Email thunderbird-drivers when all code is in with formal "Go" - Project lead
    • In Email include:
      • comm-* revision
      • mozilla-* revision
      • dom-inspector revision
      • LDAP CVS tag
      • L10n revisions
      • New Locales (also specify beta/release)

• Email contacts with release schedules & build details - Project lead

• Notify QA testers of pending release - QA lead

• Update for new versions - Project lead
  • Crash-stats (use admin interface)
  • AMO (Standard8 has permission for non a.b.* additions)
  • Bugzilla

Build & QA

• Builds created (all locales) - Build lead
  • Email thunderbird-drivers when builds are created - Build lead
  • And when snippets are available on beta channel (if not done in the previous email) - Build lead

• Unit tests results analysed by developers - (driven by) Project Lead

• QA tests builds - QA Lead
  • QA completes testing of builds - QA Lead
  • QA completes testing of updates - QA Lead
  • When signed off, email thunderbird-drivers with notification - QA Lead

• Verify against Virus vendors and announce to AV/Firewall vendors - _Tsk_

• If any of those fail, email thunderbird-drivers with a formal "stop" notification and a second "go" notification when the process is started again - Project Lead

Release Notes & Release

• File bug for bouncer entries (if not already) - Project lead
  • Note: Bouncer entries are required for Release Candidates as well as alphas & betas.
  • Ask IT to add the beta release to Sentry a few days in advance. justdave and a few others can do it.

• Draft release notes - Website lead or Project lead
  • Stage release notes, other website changes
  • Confirm release notes with PR (rebron), QA lead, others as appropriate

• Decision to release - Entire team
  • If yes, notify mirrors of beta release about 24-48 hours ahead of time. Email infra - at - mozilla.com to let them know about the push to mirrors - Project lead
  • Notify PR of "we're shipping in x days/hours/minutes" estimate - Project lead
    • This is normally done via rebron on tb-drivers with no special messages.

• Final Release, in order:
  1. Bits to mirrors - Project lead sends "go email".
     • Typical mirror saturation is 1 to 2 hours, the email should take account of this.
     • Push actual bits to ftp / releases - Build lead
  2. Push website changes - Project lead
  3. Verify website changes - QA Lead
  4. Build pushes to beta channel - Build lead
  5. Verify bits on beta channel - QA 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)
  • tb-planning
  • tb-enterprise (maybe, depends on release & feedback wanted).
  • m.dev.apps.thunderbird, m.dev.apps.calendar, m.dev.l10n, m.dev.planning newsgroups
  • MDC Devnews
  • Email metrics mozilla.com with the new version details.
  • twitter (use bit.ly with mzl.la account)