On Thu, May 24, 2012 at 09:13:06AM +1000, Stephen Rothwell wrote:

quoted

2)
	Cherry-picked these guys into signal.git, along with the rest
of signal prereqs for them.  Merge with next/akpm-base yields a couple
of trivial conflicts in kernel/fork.c (with
	sched, mm: Rework sched_{fork,exec} node assignment
removing INIT_LIST_HEAD right next to the place where we add one; conflict
resolution being just keep the one Oleg adds and remove the one Peter removes)
and in kernel/irq/manage.c (with
	genirq: Be more informative on irq type mismatch
changing a couple of printks in there; conflict resolution: just remove
exit_irq_thread() in merged variant).  That's for-next-variant2.  With that
variant we get 5 more duplicates with next/akpm, obviously.

Stephen, which way would you prefer it handled?

So variant2 sits on top of variant1 and you are intending to push the
work in variant2 in this merge window anyway?   In that case variant2
makes sense.  The number of small conflicts don't matter to much (up to a
point anyway :-)).  Also, these cherry-picks are out of Andrew's tree,
right (so they are already in linuc-next)?  In which case I would
probably go with variant2.

Fine by me...  Pushed into for-next, should be on git.kernel.org shortly...