Thunderbird/Release Driving/Firedrills

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.

• A test firedrill run was done, the details are here: Thunderbird/Release_Driving/Test_Firedrill

Procedure

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.