lkml.org 
[lkml]   [2008]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Slow DOWN, please!!!
    From
    From: Ingo Molnar <mingo@elte.hu>
    Date: Thu, 1 May 2008 00:35:09 +0200

    >
    > * Ingo Molnar <mingo@elte.hu> wrote:
    >
    > > What we need is not 'negative reinforcement'. That is just nasty, open
    > > warfare between isolated parties, expressed in a politically correct
    > > way.
    >
    > in more detail: any "negative reinforcement" should be on the
    > _technical_ level, i.e. when changes are handled - not at the broad tree
    > level.

    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.


    \
     
     \ /
      Last update: 2008-05-01 00:55    [W:3.327 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site