Thunderbird/Security And Stability Releases/Rules

Warning: This page is now obsolete

The Thunderbird Security and Stability releases are for fixing security and stability issues post major releases without releasing a new major version. Typically these releases are restricted to security and stability fixes, sometimes they may include regression fixes if deemed appropriate by drivers.

General Rules for blocking

A bug may be considered blocking a security and stability release if:

• It is a significant security issue affecting users.
• The bug is found to be a significant or widely affecting regression from a previous release (either on the same release branch or possibly from a previous one).

General Rules for approval

Patches for approval must:

• Not affect strings in mail/locales and editor/ui.
• Not affect idl interfaces (which would break binary compatibility).
• The patch is not on a bug which has already been resolved as fixed for a release on that branch.
  • This is so that we can track the fact that we've done two fixes on the branch via different bugs.
• Land on trunk before requesting approval. Preferably to have some time baking before approval is requested.
• Be accompanied by a risk assessment as to the risk the patch poses and the reason we need to take it for the security releases when the approval is requested.

Patches are unlikely to be accepted if:

• They are not affecting security or stability.
• They are high risk.
• They have no tests (some patches may be accepted without tests if there is a good reason why there aren't any, and if they can be demonstrated to be well-tested, if you need support for writing tests, please ask in #maildev).

Blocking Flag Mechanics

blocking-thunderbirdx.y

(where x.y is the major release version)

These flags have several values that show whether a bug blocks a specific Thunderbird alpha/beta/final release or a maintenance ("dot") release and, if so, which release it is.

In all the states below, the version of Thunderbird affected is referred to in the flag name, so states for blocking-thunderbird3.1 affect Thunderbird 3.1

•  ? - This bug has been nominated to block a release.
• - (minus) - Drivers have determined this bug will not block release.
• needed - This bug will block a release, but it is unclear which release it will block.
• .1+ - This bug blocks the Thunderbird x.1 maintenance release.
• .2+ - This bug blocks the Thunderbird x.2 maintenance release.
• etc...

Nomination is restricted per our blocking flag policy https://wiki.mozilla.org/Thunderbird:Blocking_Flag_Policy. Values other than nomination may only be set by the thunderbird-drivers group.

(Each release, we'll add a new option to block the next maintenance release.)

status-thunderbirdx.y

A multi-state flag that has values that show the specific status on the appropriate Thunderbird branch.

•  ? - This bug needs to be triaged on the branch to determine if it is affected or wanted on that branch.
• unaffected - The branch is not affected by this bug.
• wontfix - There is no intention to fix this on the branch.
• wanted - This bug was is considered "wanted" on on the branch and may or may not block (see the blocking-thunderbirdm.n flag).
• .1-fixed - This bug was fixed on the branch in advance of the Thunderbird x.1 maintenance release.
• .2-fixed - This bug was fixed on the branch in advance of the Thunderbird x.2 maintenance release.
• etc... (more values will be added as needed).

Values may be set by any user with "canconfirm" privileges, with the exception of the "wanted" value, which may only be set by the thunderbird-drivers group.

General Process for landing bugs on Stable branches

(This only applies to patches affecting comm-*, mozilla-* patches should follow mozilla-* rules).

1. Generate a patch for trunk and request reviews as per the standard process.
2. Once reviews granted, land the patch on comm-central (if you don't have checkin privileges add checkin-needed to the keywords)
   • On checking the patch in the bug should be marked as FIXED, and the milestone field set to the next trunk milestone.
3. Once the patch has baked for a few days:
   • request approval-thunderbirdx.x.x (by setting the flag to ?)
     • x.x.x will be the next appropraite release for the security branch you are on, so for 3.1 releases it will be something like 3.1.x.
   • At the same time as requesting approval, explain the risk associated with the patch and why it should be taken for the security and stability branch.
4. If approval is granted, land on the appropriate branch for the release.
   • Once checked in, set the status-thunderbirdx.x field to '.1-fixed', '.2-fixed' as appropriate for the release the patch is being checked in for.
     • As earlier, replace x.x with the release you're fixing it for.

Status Tracking

• See branch bug tracking pages