Re: New definition of regression

[Richard Biener <rguenther at suse dot de>]

On Wed, 6 Mar 2013, Andrew Pinski wrote:

> I am not a fan of the new definition of a regression.  Yes the new
> definition helps out release managers but it does not help out our
> users at all.  In fact I think it hurts them more as some don't update
> as fast as the release managers think they do.  I still support a 4.3
> based GCC and only starting to roll out a 4.7 based GCC.  I think it
> is wrong to say memory/compile time hogs are not regressions any more
> just for the fun of it.
> 
> Also this was not discussed at all on the list or I did not see it
> being discussed.  This decision should not be taken lightly when it
> comes to some users of the compiler.

Compile-time/memory-hog regressions are still regressions.  We just
count them as a single regression if they are present on all actively
maintained branches.

Help us by analyzing the reason for the memory-hog / compile-time-hog
and open a separate regression bug for the _cause_ of the hog.  That
way we can determine in a more precise way when a regression was
introduced and we can even close such regressions at some point
(we can't with compile-time regressions - you are always left with
a few seconds "regression", no?).

That said, a compile-time / memory-hog regression should have
an analyzed algorithmic cause, not just "well, it's using more
time overall" or "it uses more peak memory".  Because that's
not useful information.

Just my 2 cents.

Btw, now that we no longer block our release by "more than 100
regressions" but by "no P1 regressions" the original reason for
introducing the catch-all bug is gone (other to make that P[23]
regression list not grow indefinitely as our versions progress).

Richard.