Re: Assigning priorities to GNATS reports

[Mark Mitchell <mark at codesourcery dot com>]

--On Thursday, November 14, 2002 09:21:22 AM -0600 Wolfgang Bangerth 
<bangerth@ticam.utexas.edu> wrote:

> Now that the bug fixing phase for 3.2.1 is (mostly) done, what is the
> policy on setting priorities to bug reports if they are regressions? I
> think the last couple of weeks have shown that we can come up with large
> numbers of regressions and mark them as "high" until the last minute
> before the release. This way, there will always be known regressions if
> we  just go on sifting through the database.
I've been thinking about this.

All regressions should start out high.

Then, what I'd like to see (other than switching to a better defect
tracking system which has more formal support) is that we extend the:

[mainline regression]

notation.

In particular, if a bug is a regression against the current release
branch (3.2 in this case), put [3.2 regression] there.  If it's a
bug in the mainline put [3.3 regression] there.

The point of that is that when we make the 3.3 release branch, the
[3.3 regression] tags still make sense.  If we decide a defect isn't
important enough to fix, we'll either downgrade it from high, or,
perhaps, change the tag to [3.4 regression], meaning fix it in that
release.  (That might be appropriate for something that can more
easily be fixed once some functionality we expect in 3.4 will be
present.)

--
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com