Thunderbird/Release Driving/Maintenance Release Checklist

This is the general release checklist we should use for Thunderbird maintenance releases.

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
• Security lead: dmose/dveditz???
• Build lead: gozer
• QA lead: _Tsk_
• Support Lead: Roland

Checklist

Initial Stages

• Meet and schedule release - Entire team

• 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
  • Hand off to QA for verifications - QA 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

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

Build & QA

• Builds created (all locales) - Build lead
  • Email release-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 release-drivers with notification - QA Lead

• Build snippets on betatest channel - Build lead
  • Email QA lead when finished - Build lead

• XXX Project lead creates beta release notes; staging and live - Project Lead

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

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

• "Go" to beta
  • Formal "Go" email sent to release-drivers - Project lead
  • Build snippets pushed to beta channel - Build lead
  • QA verifies snippets on beta channel - QA Lead

• Beta period
  • Announce to release-drivers, m.d.a.thunderbird, m.announce.prerelease, m.d.planning - Project lead
  • XXX Notify mirrors of beta release - Project lead emails infra
  • Notify PR (rebron) of "we're shipping in a week" estimate - Project lead
  • XXX Announce to AV/Firewall vendors - Project lead
  • Announce to security group - Security lead
    • to security-group and security-announce aliases
  • Monitor feedback - QA Lead, Project lead, Support Lead (get Satisfaction)
  • OPTIONAL (required only if release notes can't fully cover all issues) - Knowledge Base Articles - Draw up list & coordinate writing of pre-release drafts - Support Lead

Release Notes & Release

• Vulnerability notices - Security lead
  • Draft to Security Group/Security-announce
  • Notify CERT (as needed)

• XXX Draft release notes - Project lead
  • Confirm release notes with dev lead, QA lead, others as appropriate
  • Stage release notes, other website changes
  • Vet past marketing (jslater@m.c)
  • Alert Mozilla Europe (pascalc)/Japan (Kohei)/China (Jack Guo/Wil Clouser) as soon as release notes (and product-details bug) are ready - Project lead
    • Be sure to give them the estimated release date and time.
  • XXX Alert webdev (wenzel/clouserw/morgamic) of when release is planned for (for product-details pushing) - Project lead

• 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
  • Bits to mirrors - Project lead sends "go email" at least 8 hours ahead of time
    • Push actual bits - Build lead
  • Verify bits on releasetest channel - QA Lead
  • Push website changes - Project lead
  • Push security advisories - Security lead
  • QA verifies website changes - QA Lead
  • Build pushes to release channel - Build lead
  • 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)
  • 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

When you have completed these steps, rinse, repeat. Every month...