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: GCC 4.4.0 Status Report (2008-11-17)


On Thu, Nov 20, 2008 at 1:24 PM, Laurent GUERBY <laurent@guerby.net> wrote:
> On Thu, 2008-11-20 at 00:39 +0100, Steven Bosscher wrote:
>> On Mon, Nov 17, 2008 at 11:15 AM, Jakub Jelinek <jakub@redhat.com> 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 :).

I think all the missed-optimization and compile-time/memory-hog problems
are relevant for the quality metrics.  Of course it would be nice to not
accumulate them - that is, make the bugs P2 for the release the regression
appeared and P4 for further releases.  But that would require some
excessive bug-cloning (which would be nice sometimes, but we already
have ressource limits of properly managing the existing amount of bugs).

So in the end it may be appropriate to not account non-serious
optimization regressions for the serious regression list.  OTOH it forces
us to do a more proper job in fixing bugs before the release ;)

Richard.


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