Thunderbird/Release Driving/Firedrills

From MozillaWiki
Jump to: navigation, search

This is the general checklist/procedure we should use for Firedrill releases. Firedrill releases are quick releases where we publish an update as soon as possible - a typical instance would be for a security vulnerability where a known exploit is available in the wild.


Initial Steps

  • Identify bug/issue.
  • Notify thunderbird-drivers/security-group.
    • Groups to agree that it requires a firedrill.
  • Fix bug and get it reviewed (this may require finding an appropriate developer, see below).
  • Land bug on affected trunk & branches.

Release Steps

Generally follow Thunderbird/Release_Driving/Maintenance_Release_Checklist with the following changes:

  • Land bug(s) on the relbranch for the previous maintenance release.
  • Build revisions are the same as for the previous maintenance release, plus the additional bug fix(es).
    • L10n revisions should also be kept the same in a firedrill situation.
  • Beta period is eliminated, QA does spot checks to verify validity of build and that the appropriate bug(s) have been fixed.
  • The security updates / release phase is effectively shortened as much as possible, so website updates etc will need to be done in parallel with build/QA testing.

Quality Steps

  1. verify the bug(s) on all platform they appear
  2. verify that the basic functionality from the area code works (ie a bug affecting AB , make sure you can still ADD/EDIT/Remove AD, that autocomplete works).
  3. verify that one can send / receive email
  4. test auto-update

Contacting Developers/Area Leads

Contact details are stored on the MoMo intranet. If someone is AFK then transfer ownership of an area as feels appropriate.