Releases/Checklist

From MozillaWiki
< Releases
Revision as of 06:02, 11 January 2008 by Samuelsidler (talk | contribs)
Jump to navigation Jump to search

This is the general release checklist we should use for maintenance releases. We use this checklist to make sure we don't miss any community, development, QA, Build, Product team, or partner deliverables as we release new versions.

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.

This serves as a checklist to make sure we don't miss any community, development, QA, Build, Product team, or partner deliverables as we release this version.

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 lead:
  • Security/Dev lead:
  • Build lead:
  • QA lead:

Checklist

  • Meet and schedule release - Entire team
    • Email dev-planning and release-drivers to announce meeting (2 days in advance) - Project lead
    • Have meeting - Led by Project lead
  • Decision on release date - Entire team
    • 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)
    • Schedule meetings - Project lead
    • Alert developers of upcoming freeze - Project lead
  • Development code freeze - Dev lead
    • Email release-drivers & build@ when all code is in - Dev lead
  • Builds created (all locales) - Build lead
    • Email release-drivers when builds are created - Build lead
    • Email betatesters when builds are created - Project lead
  • QA verification - QA Lead
    • QA completes testing and maps it onto their test plan page (usually at 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 emails release-drivers when signed off - QA 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.announce.prerelease, m.d.planning - Project lead
    • Notify mirrors of beta release - Project lead emails Justin
    • Announce to AV/Firewall venders - Project lead
    • Announce to security group - Security lead
      • to security and security-announce aliases



^ I'm to here with updating


  • L10n
    • Owner signoff as needed
    • Trademark review as needed
    • L10n Build - Build
      • Capture the chosen nightly into the candidates directory
      • Package up the locales
    • Run Automated MetaDiff test - Build
    • L10N locale spot checks - QA Lead
    • Testing by people with language skills
    • Update the shipped-locales file with the final locales and platforms - Project Lead
    • Update the public wiki listing the shipped locales
  • Notify Affiliates
    • Mozilla Europe
      • Tristan Nitot - nitot -at- mozilla-europe.org
      • Peter Van der Beken - peterv -at- mozilla-europe.org
      • Pascal Chevrel - pascal.chevrel -at- mozilla-europe.org
    • Mozilla Japan
      • Gen Kanai - gen -at- mozilla-japan.org
      • dynamis -at- mozilla-japan.org
  • Vulnerability Notice - dveditz
    • Draft to Security Group/Security-anncounce
    • Advisories posted on release
    • NEW: notify CERT (?)
  • Other PR as needed - Product
    • Web site updates
  • Release Notes
    • Inputs to cbeard/basil - Dev/QA/Product
    • First Draft complete -
    • Review - Dev/QA/Product
    • Final release notes -
  • Final staging
    • Stage bits - Build
      • Tue (UK time): cf to stage files in private area of ftp server, and transfer for signing
      • Tue (MV time): preed/rhelmer to sign builds, juanb to email cf with go/no go on publishing builds
      • Wed (UK time): cf to check signing log, gather installers, final check, push live by 0400 PDT (1200 BST), configure bouncer
      • Wed (MV time): preed/rhelmer run releasetest verification (bouncer check), push updates when ready (~4pm)
    • Let IT know about release date 24-48 hrs ahead of time. - Project Lead
      • Releases should NOT be scheduled in the morning.
    • Version ID/Update path test - QA Lead
    • Make update paths/install bits live - Build
      • Coordinate with IT to make sure current versions are pushed to the mozilla-current rsync module
    • Run automated download checker - QA
    • Test live update/install bits - QA Lead
    • Dashboard stats tracking configuration/setup (oremj/webteam)
    • Post note to these places to annouce the release;
      • all -at- mozilla.com (so all staff knows)
      • drivers -at- mozilla.org (so drivers outside Mozilla Corp know)
      • mozilla.dev.planning newsgroup
      • mozilla.annouce newsgroup (all product release announcements are expected here)
    • Post the Press Release
  • Special CJK builds for Yahoo and Google
    • These are builds with yahoo specific search codes
    • The are due within 2 weeks of the main product release
    • Generate builds - Build
    • Test the builds - QA
    • Release the builds to the respective venders - Build