Releases/Firefox 3.6.4/Checklist

• Meet and schedule release - Entire team [DONE]

• Decision on release date - Entire team [DONE]
  • Update Releases page - Project lead [DONE]
  • Update Releases/PRODUCT&VERSION with proposed schedule - Project lead [DONE]
  • Email dev-planning and release-drivers with proposed schedule - Project lead [DONE]

• 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, Build 1 - Dev lead
  • Hand off to QA for verifications - QA Lead

• Ready for builds
  • Email release-drivers when all code is in with formal "Go" - Project lead
    • For 1.9.0, include timestamp and bonsai URI down to the last checkin. Specify timezone in email as well (PST vs PDT).
    • For 1.9.1, include a changeset
    • Specify l10n cut off (1.9.0-only) as well

• 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

• 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.<application> (i.e. thunderbird or firefox), m.announce.prerelease, m.d.planning - Project lead
  • Notify mirrors of beta release - Project lead emails infra
  • Notify PR (melissa) of "we're shipping in a week" estimate - Project lead
  • 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

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

• 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/Japan/China as soon as release notes (and product-details bug) are ready - Project lead
    • Be sure to give them the estimated release date and time.
  • Alert webdev (wenzel/clouserw/morgamic) of when release is planned for (for product-details pushing) - Project lead

• Decision to release - Entire team
  • If yes, let IT (infra) know 24-48 hours ahead of time based on release policy - Project lead
  • Notify PR (melissa@m.c) 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

• Notify the world - Project lead
  • all -at- mozilla.com (so all staff knows)
  • m.dev.planning newsgroup
  • m.announce newsgroup (all product release announcements are expected here)
  • MDC Devnews
  • Post the Press Release

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