linux-next: manual merge of the kvm tree with the powerpc tree

Paolo Bonzini pbonzini at redhat.com
Wed Feb 15 22:28:45 AEDT 2017


On 15/02/2017 12:16, Michael Ellerman wrote:
>> However, the reason was that this is simply not how topic branches
>> should work: topic branches should be the base for other work, they
>> shouldn't contain _all_ the work.
> 
> I think that's an overly specific definition of what a topic branch is.
> 
> It's just a branch related to some "topic", in this case powerpc kvm,
> where commits can go so they can be shared between two trees.

Right.  However, in the specific case of working across maintainers, I
think there is an interest in minimizing the number of files that are
updated in two trees.  That limits conflicts.

Typically in x86 land people send a series with generic+KVM patches,
Thomas Gleixner picks the generic ones and places them in a topic branch
that we both pull from.  I then apply the KVM patches independently.
It's worth noting that x86 arch maintainers don't care that much about
what's going on in arch/x86/kvm/, and especially they delegate all
testing to me.  So I guess that may be the source of the disagreement.

If you would like to unify testing of non-KVM and KVM code for
arch/powerpc, it doesn't make much sense for Paul to send his patches to
me at all.  Instead, _I_ should prepare topic branches for Paul whenever
I make sweeping all-arch changes to KVM, that he can include in his pull
requests to you.  It'd feel weird though.

Paolo

>> As far as I understand, there was no reason for you to get B1.
>
> Well no reason other than it's ~1300 lines of code in my arch, which I
> would like to go through my normal testing procedures.


More information about the Linuxppc-dev mailing list