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

• 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

• Crash-stats updated with new version details - Project lead

Build & QA

• Builds created (all locales) - Build lead
  • Email thunderbird-drivers when builds are created - Build lead

• QA tests builds - QA Lead
  • QA completes testing and maps it onto their test plan page (usually at Releases/PRODUCTNAME_VERSION/Test_Plan on the wiki) - QA Lead
  • When signed off, email thunderbird-drivers with notification - QA Lead

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

• Build snippets on betatest channel - Build lead
  • Email QA lead (via thunderbird-drivers) when finished - Build lead

• QA verifies snippets and website and emails thunderbird-drivers when signed off - QA Lead

• 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 - Project lead
• XXX Notify mirrors of beta release - Project lead emails infra - Project lead

• XXX Draft release notes - Website lead with support from Project lead
  • Confirm release notes with dev lead, QA lead, others as appropriate
  • Stage release notes, other website changes

• Decision to release - Entire team
  • XXX If yes, let IT (infra) know 24-48 hours ahead of time based on release policy - Project lead
  • Notify PR (rebron) of "we're shipping in x days/hours/minutes" estimate - Project lead

• 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. QA verifies 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.