This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: 3.4 regressions: are 2.95 regressions still actual
Zack Weinberg wrote:
>> I assume that bugzilla is supposed to reflect the state of the head
>> branch. Bugs reported for releases are only of interest if they can
>> be confirmed in the head (or are regressions). That might be a good
>> policy for developing gcc, but it is not obvious at all from a user's
>> perspective. I like the idea of getting some appreciation in the
>> form of remembering my report until there is a version of gcc
>> released that has the bug fixed.
>
> This, IIRC, is what the RESOLVED/VERIFIED/CLOSED distinction in
> bugzilla is supposed to handle; like an awful lot of bugzilla's
> features, we are not using it, and I'm not sure why.
Because, in my opinion (and not only mine), those states are totally useless,
given our development flow. This was discussed on the Bugmaster list, and I
think also on this list. Theoretically, the developer should move the bug to
RESOLVED, a QA member (like, bug masters) should double check and move it to
VERIFIED, and when the version containing it is shipped they should go to
CLOSED. Given that we have a testsuite to make sure that things stay fixed,
this would be a maintanance trouble with no obvious advantage. Till now, the
only reason that was brought for the use of such states is:
>> I like the idea of getting some appreciation in the
>> form of remembering my report until there is a version of gcc
>> released that has the bug fixed.
I'm sorry for Erik, but we can't go through more maintanance to "show
appreciation" (?). I'm not sure why it should be taken as a lack of
appreciation if I close the bug immediatly because it's already fixed. In fact,
every once in a while, after I quickly close a bug as "already fixed in
mainline", I happen to get personal mails from the bug submitters praising the
GCC developers and looking forward to the new version. Erik also says:
>> Bugs reported for releases are only of interest if they can
>> be confirmed in the head (or are regressions).
I'm not sure what Erik would expect. I think this applis for EVERY software in
the world. If you use the latest version and you report a bug which is already
fixed (maybe because someone else reported it, for instance), the best the
developers can and will do is check that your bug was fixed and tell you to
wait till next version (or grab it off CVS). And this is exactly what we do.
Either I close the bug immediatly, I suspend it, or whatever else state change
I can do, things are not gonna change: the bug is fixed, it will stay fixed
because of the testsuites, Erik will have to either use a develpoment vesion of
GCC (if/when feasable), or wait for a new release to come out. Really, I can't
see why we should go through this additional maintenance effort.
Are there serious points which should make us use other states to keep the bugs
"around" somehow until a release is out? I can't see any, and given our
previous discussions on the subject, I'm fairly sure many people can't as well.
Instead, Gaby's point of trying to backport as many non-intrusive patches as
possible to active branches is interesting. I'm willing to spend time on
discussing and studying and elaborating on how we (bugmasters) can keep track
and help with this issue.
Giovanni Bajo