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: jbuck at synopsys dot com
- Cc: mark at codesourcery dot com, bangerth at ticam dot utexas dot edu, gcc at gcc dot gnu dot org
- Date: Fri, 15 Nov 2002 10:41:25 +0100
- Subject: Re: Assigning priorities to GNATS reports
On 14 Nov, Joe Buck wrote:
>
>> > 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?
>>
>> Call it a "[3.2 regression]"; i.e., use the oldest release that we are
>> still maintaining.
>
> It seems that there are two pieces of information we are interested in:
> the last gcc version where the test worked correctly, and the version
> or versions where it does not work. A regression that worked in 2.95.x,
> but that fails in all 3.x releases, is less severe than, say, a case
> that worked in 3.2 and fails in 3.2.1. The reason is that the question
> for the user is whether it's worthwhile to replace the old version with
> the new version; a compiler that is better than all recent versions, but
> that has not yet fixed every issue introduced after 3.0, is worth
> installing, but a compiler that has regressions against the previous point
> release probably should not be shipped at all.
How about the following:
[<branch-to-fix> regression (<branch-first>-<branch-last>)]
i.e., [3.2 regression (3.0-3.2)] means: the bug first occured in 3.0, it
should be fixed in the 3.2-branch, and is already fixed in mainline.
[3.2 regression (3.2-)] means: the bug first occured in the 3.2-branch, it
should be fixed in the 3.2-branch, and is still open in mainline.
Greetings,
Volker