On Thu, 2008-11-20 at 00:39 +0100, Steven Bosscher wrote: > On Mon, Nov 17, 2008 at 11:15 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote: > > Quality Data > > ============ > > > > Priority # Change from Last Report > > -------- --- ----------------------- > > P1 13 - 4 > > P2 114 - 27 > > P3 3 +- 0 > > -------- --- ----------------------- > > Total 130 - 31 > >
> > [...] There are more bugs like this (maybe 12, 16 in total or so). I think > that if you keep counting this kind of PRs in the "Quality Data", it > gives a much darker (and, frankly, quite flawed) indication of the > quality of the compiler. In fact, if you judge the state of GCC 4.4 > based on the Bugzilla regressions list, it is in surprisingly good > state compared to GCC 4.3 (I don't know how many bugs GCC 4.4 has that > are not regressions, of course). > > In business-speak, one would probably say that just the number of > regressions is not a good Key Performance Indicator ;-) May be the summary could include a few more lines to distinguish by keyword family then by priority. Here is a first cut of families limited to three so as to keep the report readable: 1/ "real bugs" = has at least one of wrong-code, rejects-valid, ice-on-valid, ice-checking, ABI, build, assemble-failure, link-failure 2/ "other bugs" = the rest with at least one keyword 3/ "no keyword" = so to be added, I assume cannot be P1/P2/P3 I assume a few reports in category 2 should be considered for release like: - essential documentation or release note missing or incorrect - wrong-debug with large impact - compiled code performance regression likely to be seen widely - compile time regression likely to be seen widely These should be candidate for P1 and family 2 and 3. My 0.02 c :). Laurent
