Re: linux-next: manual merge of the tip tree with the arm tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx>
        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@xxxxxxxxxxxxxxxx>
 AuthorDate: Sun May 8 18:55:19 2011 +0100
 Commit:     Russell King <rmk+kernel@xxxxxxxxxxxxxxxx>
 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-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux