Re: 3.4 regressions: are 2.95 regressions still actual

["Giovanni Bajo" <giovannibajo at libero dot it>]

Erik Schnetter wrote:

> I have to admit that this policy did puzzle me quite a bit some time
> ago.  At that time I was still using the released versions of gcc
> (instead of a daily CVS checkout), and I was even using the most
> recent release, not relying on my OS distributor to be up to date.
> So I encountered a bug, filed a report, and it was promptly closed a
> few hours later with a comment like "cannot be reproduced on the
> mainline; seems to have alreay been fixed."

We have a policy for that, which depends on the type of bug:

- If the bug is a regression (which means that it used to work but now it does
not), it usually stays open until either it's fixed or the branch for which it
applies is officially closed. For instance, if you have code which works in
2.95, doesn't work in 3.3.x but works in 3.4/3.5, the bug *will* stay open as a
3.3-only regression, unless there is a strong consensus that it's far too hard
and risky to fix it on the 3.3 branch (which is a rare event, I must say).

- If the bug is *not* a regression, which means that it's something that never
worked in GCC, but it does work on mainline, then it makes no sense to keep it
open. It never worked, so there is no existing code which is affected by it.
The bug is useless for GCC developers, as from their point of view it's
something that doesn't need to be touched: it will just work in the new
version. Plus, CVS branches are open for regression-fixes only, which means
that it's disallowed to commit bug reports for anything but regressions (unless
the RM wants to override this policy for some specific case).

If you disagree with what was done with your bug, just give me the PR number
and we can revisit the situation just now.

> What if someone decides to make another
> release from the release branch, say 3.3.4?  With the bug report
> closed, it won't stand a chance to be fixed.  Even if someone will
> decide to work on it.

We close regressions only when the branch is totally freezed, that is the SC
decided that there won't be any other release from that branch.

> I've seen other projects where bug reports for officially released,
> recent versions are not closed, but are marked as "fixed in 3.4"
> instead.  When the first 3.4 release happens, these bug reports get
> all closed.  That is always a big ego boost, because getting the
> release out means closing quite a few bug reports.

We use the target milestone for that, so when GCC is out we know
(approximately) how many bugs we did fix for that release.

> (Hypothetically,
> one could even check whether these bugs actually stayed fixed in the
> 3.4 branch.)

This is done through the testsuite. Sometimes things get fixed thanks to
changes which already have entries in the testsuite. Other times, some peculiar
ICE gets fixed just by chance, and in that case we close the report but we *do*
add a testcase to the testsuite.

Giovanni Bajo
just another bug master