Re: Number of 3.3 hi-pri PRs going up

[Wolfgang Bangerth <bangerth at ticam dot utexas dot edu>]

> Two weeks ago, there were 72 high-priority PRs, four days ago there were
> 77, and today there are 80 *high-priority* PRs!  For a handful of those
> patches are pending, but most of them are just there waiting to be
> picked up and fixed by somebody.

Being one of the seemingly few with a good overview of what is there in 
GNATS, just a few thoughts:
- I believe that these numbers not really represent a setback in quality 
  in gcc. They more closely reflect that the bug database has been sitting
  around idly for a long time, and that we uncovered regressions from long
  ago that nobody knew about since nobody cared to look at the respective
  PRs. However, it is my firm belief that these regressions should be 
  fixed. We did not do so in the previous releases pretending not to know
  about them. Fixing them should significantly improve the quality of gcc.

- I think that we presently have a rather good overview of the state of 
  gcc. At least for the C++ part, it is fair to say that the number of
  regressions listed in gnats in un-analyzed reports is very small. I 
  think we have looked at almost every report that is in there, checked 
  it, and checked most of them against the new parser. So if the number of
  regressions is growing, then only due to newly incoming reports. 
  Turnaround time for new C++ reports is presently below one day, on
  average, I'd say.

- In a general perspective: the number of hi-pri regressions constitutes a
  non-vanishing fraction of the total number of open PRs (for C++: 80 out
  of 480). If we could fix them, we'd already be a significant step
  towards reducing the total number of unfixed bugs.

[Port maintainers:]
- The state of reports in the "bootstrap" and "target" categories is
  probably best described by "neglected". Since not many people can test
  them, it really requires more attention by the port maintainers. The 
  majority of our 1800 or so unfixed reports are in these categories, and
  many of them are in "open" state since their filing -- often two years
  or more ago. I have tried to make an effort to indicate in the synopsis
  of many of them for which target they are, but that doesn't seem to
  incite maintainers to look at them :-( If nobody cares about these
  reports, we could just as well delete them, since the bug database is
  worthless then.

Given our present perspective on the database, I'd say that at least for 
the C/C++/libstdc++/optimization part, the number of open reports is 
actually not so vast. I would think that if people started to really 
concentrate on fixing bugs, a significant amount (say, half of them) could 
actually closed within one or two months. Doing so would bring us into a 
much better position where it is simpler to justify doing the fancy stuff 
(new optimizations, etc) rather than the boring bug fixing. But then I 
know that this will not happen, unfortunately...

W.

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