Proposing regression bugs process simplification.

[Jean-Baptiste Lallement]

Hello all!

Some of us on the QA Team, have been thinking about the current process
with regression tags. One of our goals is to make bug reporting and bug
triage as least complicated as possible. We have been reviewing the bugs
with a regression-* tag and it appears that we need a change to make it
simpler.

The report [1] gives an overview of the state of regression bugs. We
have found that many regression-potential bugs are filed against a
released version and need to be promoted or demoted and targeted to the
right release(s). At release time we should have evaluated what to
convert from regression-potential to regression-release, but it's hard
to keep track once the release is out and change all tags.

Most of the time the regression-potential tag is used as a backseat to
regression-release or interpreted as a 'regression to be confirmed'. So
using regression-potential requires extra work:
- mark it as regression-potential
- confirm it is a regression
  - nominate
- confirm it is *not* a regression
  - remove tag from bug
- when the release is out, verify all 'regression-potential'
  - change to 'regression-release' if correct
  - nominate
  - otherwise, remove tag.

We feel this could be made easier.

So, we have studied many ways to make it simpler and are proposing the
following change to the current process:
keep only 3 tags:
 - regression-release,
 - regression-updates
 - regression-proposed

depending on the pocket - and nominating / targeting to every release
the regression as it is today whatever the release is (development or
released). We think that's all what we need for a nice clean regression
work flow.

We have no firm position yet and would like your opinion to find out if
it makes sense. If it does, we would like to check all the -potential
bugs and use the new policy for natty.

We considered other options:

transforming the tag so that the Ubuntu version is explicit:

 - (a) regression-(release|update|proposed)-<Ubuntu version>
 - (b) regression-<Ubuntu version>-(release|update|proposed)

We considered this to make it unnecessarily more complex, given that we
already tag a bug with the Ubuntu version it was found in.

Additionally, this naming makes it more complex to search on LP: on (a)
we can search for all regressions, or all regression-maverick, or all
regression-maverick-<pocket>, but if we want all regression bugs, any
version, on 'proposed' we would have to give all possible combinations;
on (b) this is the same for Ubuntu versions.

Thanks in advance for your feedback.


[1] https://wiki.ubuntu.com/JeanBaptisteLallement/RegressionReport


-- 
Jean-Baptiste
irc: jibel