Thunderbird/Release Driving/Firedrills: Difference between revisions
Jump to navigation
Jump to search
(Created page with '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 ins…') |
No edit summary |
||
| Line 1: | Line 1: | ||
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. | 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. | ||
__TOC__ | |||
* A test firedrill run was done, the details are here: [[Thunderbird/Release_Driving/Test_Firedrill]] | |||
== Procedure == | == Procedure == | ||
Revision as of 08:53, 2 March 2010
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.
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.