RegressionTracking

Revision 4 as of 2008-09-03 16:21:00

Clear message

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.

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.