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    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site