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. -- 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
