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.
