This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Assigning priorities to GNATS reports
- From: Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>
- To: mark at codesourcery dot com
- Cc: bangerth at ticam dot utexas dot edu, gcc at gcc dot gnu dot org
- Date: Thu, 14 Nov 2002 20:41:44 +0100
- Subject: Re: Assigning priorities to GNATS reports
On 14 Nov, Mark Mitchell wrote:
> 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.)
I just changed all "mainline regressions" to "3.3 regressions".
What I'm unsure about is how to rate old regressions. For example,
the code compiled on gcc 2.95.3, but causes an ICE in all subsequent
compilers.
Do I rate it as a "2.95.3 regression" (since it's a regression from
2.95.3) or "3.0 regression" since the bug appeared in the 3.0-branch
or even "3.2 regression" since previous branches aren't maintained any
more?
Any suggestions?
Wolfgang Bangerth writes:
> PS: Looking at the number of bugs fixed for 3.2.1, I really lift my hat
> towards those who did it! Thanks!
Great work!
Wow, almost 100 bugs!
Best wishes,
Volker