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

• Co-ordinate with l10n Project lead
  • L10n lead signs-off l10n changes
  • When ready to ship visit the sign-off dashboard:
    • https://l10n-stage-sj.mozilla.org/shipping/milestones
    • Ensure you are logged in (if you haven't logged in before, use your LDAP username/password, then ask Axel to give you appropriate permissions to ship, Standard8 already has these).
  • Click the ship button for the release that you want to ship (this doesn't ship yet).
  • If there are pending sign-offs, and you can find sipaq or Pike, then get them signed off if possible.
  • Once you are ready:
    • save both the l10n-changeset and shipped-locale files.
    • Hit the "ship it"!
      • This closes l10n submissions for the release.
    • The shipped locales file should be used to update mail/locales/shipped-locales in the appropriate comm-* repository
      • (though generally this doesn't change, if it does, then additions should be considered as beta locales for at least one release) .
    • The l10n-changeset file should be used to update the appropriate l10n-thunderbird-changesets-* file in buildbot-configs/thunderbird.
  • If tweaks become necessary, talk to Axel.

• 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 locales if necessary)

• 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

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

• Create beta release notes, start and what's new pages; staging and live - Website Lead or Project Lead

• QA verifies snippets on betatest channel 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

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

• Beta period
  • Announce to thunderbird-drivers, m.d.a.thunderbird, m.d.l10n, m.d.planning - Project lead
  • Keep PR up to date with shipping effort - Project lead
    • Normally done via rebron on thunderbird-drivers.
  • Announce to AV/Firewall vendors - _Tsk_
  • 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

• File bug for bouncer entries - Project lead

• File bug for thunderbird-details and history update - Project lead
  • This stage is also used to alert Mozilla Europe (pascalc), Mozilla China (Jack Guo/Wil Clouser), and Mozilla Japan (Kohei). So be sure to give them the estimated release date and time.

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

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

• Decision to release - Entire team
  • If yes, let IT (infra) know 24-48 hours ahead of time based on release policy - Project lead
    • Email justdave, and/or infra -at- mozilla.com
  • Ensure PR knows (rebron) of "we're shipping in x days/hours/minutes" estimate - Project lead
    • Realistically, rebron is on tb-drivers and therefore should know anyway.

• Final Release
  • Bits to mirrors - Project lead sends "go email" at a period which allows 2-3 hours for mirror uptake and whoever is doing the push to do it at an appropriate time.
    • Push actual bits - Build lead
  • Verify bits on releasetest channel - QA Lead
  • Change redirects from beta pages to production - Build lead
  • Push website changes - Project lead
  • Push security advisories - Security lead
  • QA verifies website changes - QA Lead
  • Build pushes to release channel - Build lead
  • Verify 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.
  • twitter (use bit.ly with mzl.la account)

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