Releases/Firefox 3.6.4/Checklist

From MozillaWiki
Jump to: navigation, search

Setup/Project Definition

  • Meet and schedule release - Entire team [DONE]
  • Decision on release date - Entire team [DONE]
    • Update Releases page - Project lead
    • Update Releases/PRODUCT&VERSION with proposed schedule - Project lead
    • Email dev-planning and release-drivers with proposed schedule - Project lead
  • Triage of blocking/approval requests as needed - Entire team (minus build) [DONE]
    • Schedule meetings - Project lead
    • Alert developers of blockers - Project lead
    • Alert developers of upcoming freeze - Project lead

Build 1

  • Development code freeze, Build 1 - Dev lead [DONE]
    • Hand off to QA for verifications - QA Lead
  • Ready for builds [DONE]
    • 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 [DONE]
    • Email release-drivers when builds are created - Build lead
  • QA tests builds - QA Lead [DONE]
    • 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 [DONE]
    • Email QA lead when finished - Build lead
  • QA verifies snippets and website and emails release-drivers when signed off - QA Lead [DONE]
  • 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 [DONE]
  • "Go" to beta [DONE]
    • 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 [ONGOING]
    • 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

Build 2

  • Development code freeze, Build 2 - Dev lead [DONE]
    • Hand off to QA for verifications - QA Lead [DONE]
  • Ready for builds[DONE]
    • Email release-drivers when all code is in with formal "Go" - Project lead [DONE]
      • For 1.9.1, include a changeset
  • Builds created (all locales) - Build lead [CURRENT]
    • 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
  • 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