Ubuntu Wiki

DRAFT: Procedure will be announced to the QA and dev teams when wrinkles have been worked out.

Starting with Intrepid we will start tracking regressions between releases. Regressions make for a poor user experience and therefore often count as release blockers. Even when we decide it is unavoidable to ship with a known regression we should document it clearly.

Regressions will be marked on the Launchpad bug with one of 3 tags:

• regression-potential - A bug discovered in the development release that was not present in the stable release. If it is significant, it should also have a task added under the ubuntu-release-notes launchpad project to be tracked for inclusion in the release notes.

• regression-release - A regression in a new stable release. This may be a bug in a single package or functionality lost when changing the default application.

• regression-update - A regression introduced by an updated package in the stable release.

Regression that have been fixed should be marked with regression-fixed but the original regression tag should be left in place so we can track the evolution of these bugs. [or should we rely on bug history/regular poling /w archive?]

• [Leann] - I don't think it will be necessary to tag bugs regression-fixed. The reason is that regressions should have already been tagged regression-*. Once a bug with a regression-* tag has a status change to "Fix Released" that should indicate the regression has been fixed.

• [Brian] - I agree with Leann here
• [Steve] - That makes sense. Should only bugs in main be nominated to the ubuntu-release-notes project, as well as requiring some level of severity (high?)?

Regression data template

It is important to use this exact template so we can programatically extract the information.

== Regression details ==
Discovered in version:
Last known good version:

Future development

Regression tracking should eventually become a Launchpad feature.