This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: state of 3.2.1-pre: how far from release?
- From: Joe Buck <jbuck at synopsys dot com>
- To: bangerth at ticam dot utexas dot edu (Wolfgang Bangerth)
- Cc: gcc at gcc dot gnu dot org, Joe dot Buck at synopsys dot COM
- Date: Tue, 5 Nov 2002 12:08:26 -0800 (PST)
- Subject: Re: state of 3.2.1-pre: how far from release?
> Volker Reichelt, I and several others have been sifting through a lot of
> old reports recently, and are probably responsible for the many open "high
> priority" C++ bugs. I think if we would go on doing so, we could go on
> forever changing more reports into "high" mode than can be fixed. I think
> hadn't we changed the priority of these reports, the question would not
> even have arisen. So if you ask me, i.e. a simple user of gcc, then go
> ahead and release the thing.
First, thanks for your work.
We have perhaps made a mistake, in the following sense: we are treating
all regressions equally. By our present criteria, we can write a noise
generator, and if it crashes all gcc versions but one, we must call it
priority "high".
Since Mark asked to use priority "high" to indicate a regression, I won't
challenge him on that one, but perhaps we can use the severity field as
well. At some point in the release process, we could consider only the
PRs with severity "critical", priority "high", and not marked as
"[mainline regression]" as blockers.
> However, there is a thing that is really worrying me: there are presently
> more than 1,800 non-closed reports, of which 570 are for C++ alone. I have
> been looking at a lot of them, but the sheer number is creating problems:
> I often think that this is a duplicate of something, but cannot seem to
> find the other one, etc.
We could certainly use more volunteers.
> If these numbers are allowed to grow, this will be getting out of hand.
The numbers can grow if releases are infrequent, because people will keep
re-reporting the same bugs.
> (By this I don't imply that gcc is in an overall bad shape. I think the
> contrary is true. This is just a management problem, and it needs to be
> addressed, because the database will become useless otherwise if there are
> too many open reports. In this context, I can also only stress again that
> it would be nice to have Bugzilla instead of GNATS, to make searching and
> filtering simpler. Another feature that I am greatly missing is a button
> to click, reading "I did confirm this report with recent CVS". This way I
> could see whether someone looked at this recently or whether it might be
> worthwhile re-checking some old report.)
Agreed about Bugzilla. In the meantime, one possibility is to use the
modified-time in the advanced query form. For PRs that haven't been
touched in a year, the volunteer can append a message to the audit trail:
either "confirmed present in x.y.z" or "no longer present".