lkml.org 
[lkml]   [2011]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: linux-next: manual merge of the tip tree with the arm tree

    * Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:

    > On Mon, May 16, 2011 at 11:40:56AM +0200, Ingo Molnar wrote:
    > > maintainers (and not assume lack of ack after 24 hours means acceptance), or
    >
    > Wrong, 72 to 96 hours. Sunday to Wednesday/Thursday.

    Not that this is really material (the argument is pretty much the same even had
    you waited 3 days), but you are already wrong about the 'Sunday' part, because
    you posted it to lkml on *Monday* 13:27 GMT:

    Message-ID: <20110509132738.GB16919@n2100.arm.linux.org.uk>
    Mon, 9 May 2011 09:27:52 -0400

    How hard can it be for you to look up the dates of the events before you accuse
    others of not listening?

    Then you committed/amdended it on Tuesday 7:20 GMT:

    commit 3490f584b9ba5a0b6f63832fbc9c5ec72506697b
    Author: Russell King <rmk+kernel@arm.linux.org.uk>
    AuthorDate: Sun May 8 18:55:19 2011 +0100
    Commit: Russell King <rmk+kernel@arm.linux.org.uk>
    CommitDate: Tue May 10 08:20:54 2011 +0100

    which is a mere 18 hours after it was mailed to lkml - and then you pushed it
    out to linux-next some time after that, probably on the next day, Wednesday,
    right?

    It does not matter one little bit that you'd have been 'ready to rebase' once
    more had some objection come in that short 2 days time window from Monday to
    Wednesday, or any of the dates after that.

    What i'm saying for the fourth time is that what you did here is not a proper
    Git workflow: we only push bits out into permanent branches (and expose them to
    conflicts, etc.) once they are final, and we only do that after making sure
    that maintainers who maintain the trees of the affected files are fine with it
    and make sure that there are no conflicts.

    Or, failing all that, if you are such a superhero kernel hacker who never makes
    any mistakes and never apologizes and can freely ignore well-established Git
    workflow best practices you should *at least* make sure you do not mess up and
    make sure the file you modify still builds on the architecture you are
    modifying:

    $ git checkout 3490f584b9ba # clocksource: convert x86 to generic i8253 clocksource
    $ make defconfig
    $ make -j2 bzImage

    arch/x86/kernel/i8253.c: In function ‘init_pit_clocksource’:
    arch/x86/kernel/i8253.c:133: error: implicit declaration of function ‘clocksource_pit_init’
    make[2]: *** [arch/x86/kernel/i8253.o] Error 1
    make[1]: *** [arch/x86/kernel] Error 2
    make: *** [arch/x86] Error 2
    make: *** Waiting for unfinished jobs....

    Or is that too much to ask for?

    Thanks,

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-05-16 13:09    [W:0.051 / U:0.204 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site