keeping track of regressions during the development cycle

[Matt Zimmerman]

On Thu, Jul 31, 2008 at 06:21:49PM +0200, Sebastien Bacher wrote:
> On jeu, 2008-07-31 at 16:27 +0100, Matt Zimmerman wrote:
> > I'm not sure what the ratio of regressions is on incoming bugs, or how
> > much effort it will be to identify them, but this sounds like a
> > reasonable starting point.  This will need to be documented and the
> > triage teams informed of the policy in order to try it out.
> 
> how do you define what is considered as a regression exactly? all the
> apport bugs which are not duplicate are potentially regressions for
> example, there is also components which get quite some changes during
> unstable cycles and different sets of bugs, nominating all of those to
> clean the list then would be quite some work and bug mail noise

A regression is a new bug, which wasn't present in previous versions of the
software.

Most of the time, we don't know whether a bug is a regression or not, and we
shouldn't assume that they are just because we haven't heard of them.

But where we can verify that a bug is a regression, e.g. was known to work
in the previous release, it should be flagged as such and treated specially.

-- 
 - mdz