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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <d3828e13-3ca8-db6e-0ea7-4427a1be2815@redhat.com>
Date:   Wed, 15 Feb 2017 12:28:45 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Michael Ellerman <mpe@...erman.id.au>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Marcelo Tosatti <mtosatti@...hat.com>,
        Gleb Natapov <gleb@...nel.org>, KVM <kvm@...r.kernel.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        PowerPC <linuxppc-dev@...ts.ozlabs.org>
Cc:     linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
        Paul Mackerras <paulus@...abs.org>,
        Nicholas Piggin <npiggin@...il.com>
Subject: Re: linux-next: manual merge of the kvm tree with the powerpc tree

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.