RegressionTracking
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.