Thunderbird/Release Driving/Firedrills
From MozillaWiki
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.
Contents
- 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
- verify the bug(s) on all platform they appear
- 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).
- verify that one can send / receive email
- 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.