This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: state of 3.2.1-pre: how far from release?


> 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".

I think I came to this conclusion as well. However, I think the problem is 
that fixing these bugs came too late in the process. Many of these have 
been in the data base for a long time, and they need not be dug up only at 
the last minute.


> > 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.

That's not the point. If I continue, I may have seen every C++ report in a 
month or so, but I will not recall the exact numbers and synopses of other 
bugs I have in mind for duplicates. Just throwing more people at that will 
not help, these bugs will have to be fixed to close them, also if we 
don't mark them as regressions.

On the other hand, there are so many that really need to be looked at 
by people with the right platform. I should start pinging more people if I 
cannot reproduce something on the platforms I have. And we should start 
writing the platform name into synopsis if this is not reproducable 
cross-platform.


> > 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.

Sure, but the duplicates will not be closed and you end up with a database 
with a large amount of bugs. And the overall number of non-closed reports 
should not increase from release to release without bounds.


> 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".

Is there a way to just append some text, or do I have to send mail for 
this. The latter is inconvenient with cut-and-pasting the synopsis, 
sometimes mail being spam-blocked, etc...

Regards
  Wolfgang

-------------------------------------------------------------------------
Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]