Thunderbird/Release Driving/Next Major Release Policy

Warning: This page is now obsolete

This page details the general policies that Thunderbird drivers use for the next major release of Thunderbird. For security and stability releases, see this page.

Blocking Items

Bugs

Thunderbird drivers will mark a bug as blocking the next major release if they feel that it falls under one of the following categories:

• It is a build related bug that stops Thunderbird from being built and released.
• It is a security issue that could cause significant issues for our users if we shipped with it.
• It is a significant usability regression from a previous release.
  • This could come in several forms, e.g. crash regressions, user experience regressions.
• It is a new issue in overall usability resulting from a new feature that has landed.

Features are generally not blockers, although drivers may have requirements that a major release contains certain features before it is released.

Drivers may change the blocking status on a bug at any time, they will typically include a comment explaining the reasoning.

Drivers may deny blocking on bugs that were previously accepted as blocking as a release draws nearer and priorities are re-considered.

Setting of Blocking Flags

The blocking flag for the release will be designated as blocking-thunderbirdx.y (where x.y is the major version for that release).

A blocking flag may be set to ---, ?, -, or alphaN+, betaN+, final+, needed+ or .N+ (where N is a specific number relating to a sub-release):

• "---" means no value has been set yet
• "?" means this bug has been nominated for consideration of blocking status
• "-" means this bug has been denied blocking
• a value with "+" in it, means this bug has been accepted for blocking status.
  • The full text of the flag indicates which specific sub-release it blocks.
  • If it is marked as "needed+" then the specific release it blocks has not been determined yet.

Setting of the blocking flags is restricted to various people as determined by the Blocking Flag Policy

Extensions

The drivers consider some add-ons as soft-blockers for a release; this means they are highly desirable to be compatible, but in limited circumstances a release may not be held on them.

Generally these are highly used add-ons or add-ons promoted within Thunderbird itself. The current list of add-ons are:

• Lightning
• Extra Folder Columns
• Compact Header

Drivers may change this list at any time as is felt appropriate.

Wanted Flags

In addition to the blocking status, the drivers also have the option to set wanted status. Typically this will be for bugs that are highly desirable for a particular major release; bugs that are more generally wanted will use the more generic "wanted-thunderbird" (note: no version specified) flag.

Setting of wanted flags

The wanted flag for the release is part of the status-thunderbirdx.y flag (where x.y is the major version for that release).

A status flag may be set to ---, ?, "unaffected", "wanted", "wontfix" or xxx-fixed (where xxx relates to a specific release):

• "---" means no value has been set yet
• "?" means this bug has been nominated for consideration of status
• "unaffected" is typically used once a release branch has been formed and this bug is considered not to affect that release branch.
• "wanted" the drivers feel this is a significant bug wanted for the release.
• "wontfix" the drivers have decided not to fix this issue on the release branch.
• "xxx-fixed" is typically used once a release branch has been formed and is used to designate the release in which this bug has been fixed.

Restriction of landings into the release (approval required)

Once development for a major release has transitioned to a stabilization phase, all patches will need specific approval from the Thunderbird drivers. The only exceptions to this rule are:

• Minor test-only fixes.
• NPOTB patches.

The approval criteria for patches is:

• The patch must be:
  • A backout or pref-off
  • Safe fixes for new regressions
  • Security/stability fixes.
• Patches should have tests if possible.
• New code is not acceptable.
• Minor fixups (e.g. build config) or other small improvements will not be accepted (unless they are related to new regressions).

All patches must have an explanation of why they are required for the release accompanying the request, and the risks around taking the patch. Otherwise the drivers may deny the request until that is given.

Tracking of Bug statuses

Tracking of various bug statuses for a release is managed through the links provided from the bug tracking page.