Re: linux-next: manual merge of the block tree

[Jens Axboe <jens.axboe@oracle.com>]

On Fri, Jun 27 2008, Ingo Molnar wrote:
> 
> * Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > > That way we could pull it into tip/x86 and give it some testing on 
> > > the x86 side, and resolve its integration effects. Would that be 
> > > possible?
> > 
> > Currently I have two branches for this - one is generic-ipi, which 
> > contains the generic bits and all the arch conversions. The other is 
> > smp_call_function, which kills the unused argument to 
> > smp_call_function() (and friends) and on_each_cpu(). If I separate out 
> > the non-x86 archs, I'll have trouble getting it all in for 2.6.27 as 
> > I'll be on vacation as of july 5th.
> > 
> > So it's not tied in with any block bits, but it does have all archs. 
> > Even if it's a bit of a weird thing to put the whole thing into the 
> > x86 tree, I don't mind if we do that. Heck, it's in the block repo to 
> > begin with :-)
> 
> i'll put this into tip/generic-ipi and wont put into the x86 topics 
> towards linux-next - i just want to see the effects in practice.
> 
> This is the 102th -tip topic, there's space for all :-)
> 
> > So if you could pull:
> > 
> > git://git.kernel.dk/linux-2.6-block.git generic-ipi
> > 
> > and
> > 
> > git://git.kernel.dk/linux-2.6-block.git smp_call_function
> > 
> > and merge them with the x86 changes, that would be fine. It's also the 
> > place where we currently have conflicts due to 32-bit and 64-bit stuff 
> > being merged, so it would help Stephen as well.
> 
> i have an even better, brilliant plan :-)
> 
> what we could do is that we could offer an auto-generic-ipi-next 
> integration branch that to Stephen that is tip/auto-x86-next plus 
> tip/generic-ipi.
> 
> in fact i've just implemented this. You can pull the resulting 
> tip/auto-generic-ipi-next tree from:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git auto-generic-ipi-next
> 
> [ note: just first raw merge and conflict resolution, not tested yet. ]
> 
> note that it embedds your tree in a Git way and we can update the 
> tip/generic-ipi branch in an append-only manner and it can go towards 
> Linus in whatever way you prefer. (as long as you do not rebase the 
> tree)
> 
> If you agree with this setup then this tree could be put after all these 
> -next branches:
> 
>   auto-core-next
>   auto-cpus4096-next
>   auto-ftrace-next
>   auto-genirq-next
>   auto-safe-poison-pointers-next
>   auto-sched-next
>   auto-stackprotector-next
>   auto-test
>   auto-test-fixes
>   auto-timers-next
>   auto-x86-next
> 
> and then it will merge without conflicts. It's auto-updated to all these 
> branches - i.e. when these branches are iterated then 
> auto-generic-ipi-next will be iterated as well.
> 
> how does this sound to you? Nothing changes to your work flow (just keep 
> those branches updated and let me know when i should pull from them), 
> but conflicts are auto-eliminated from Stephen's flow and the conflict 
> resolution workload and burden is put on those who generate them (the 
> x86 folks and you).

Sounds good to me :-)

-- 
Jens Axboe