Sure, and I'll provide some right here.
Ingo, let me know what I need to do to change your behavior in
situations like the one I'm about to describe, ok?
Today, you merged in this bogus "regression fix".
commit ae3a0064e6d69068b1c9fd075095da062430bda9
Author: Ingo Molnar <mingo@elte.hu>
Date: Wed Apr 30 00:15:31 2008 +0200
inlining: do not allow gcc below version 4 to optimize inlining
fix the condition to match intention: always use the old inlining
behavior on all gcc versions below 4.
this should solve the UML build problem.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Did you actually read the UML build failure report?
Adrian Bunk specifically stated that the UML build failure regression
occurs with GCC version 4.3
Next, did you test this regression fix?
Next, if you could not test this regression fix, did you wait
patiently for the bug reporter to validate your fix? Adrian
responded that it didn't fix the problem, but that was after
you queued this up to Linus already.
This proves my main beef with you Ingo. You're way too trigger happy,
you merge things in too quickly, without checks and without
verifications.
To an arbitrary person reading the commit logs, the above
looks like you fixed something, when you actually didn't fix
anything.
And let's address this specific inlining optimization and all the
fallout it's generating. You said you merged this thing in because
you didn't want to "wait a year for such a useful feature." In
hindsight, that's exactly what we should have done, waited until we
could sort out all of these issues. Yes, even if it would take a
year.
Now we're forced to sort it out somehow, unless you can get beyond
your pride and revert the original change.
--
