Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1580540

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

From Paolo Bonzini <pbonzini@redhat.com>
Newsgroups linux.kernel
Subject Re: linux-next: manual merge of the kvm tree with the powerpc tree
Date 2017-02-14 14:40 +0100
Message-ID <taLuO-2sF-21@gated-at.bofh.it> (permalink)
References <t9aGZ-6Ul-7@gated-at.bofh.it> <t9gjo-23D-13@gated-at.bofh.it> <taGYb-7UK-31@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw



On 14/02/2017 09:45, Michael Ellerman wrote:
>> If possible, please pull only up to "powerpc/64: Allow for relocation-on
>> interrupts from guest to host" and cherry-pick the top two patches
>> ("powerpc/64: CONFIG_RELOCATABLE support for hmi interrupts" and
>> "powerpc/powernv: Remove separate entry for OPAL real mode calls") into
>> your next branch, but leave the rest for my tree only.
>
> I don't see how that helps anything.
> 
> In fact it guarantees a mess because those two commits would now go to
> Linus via my tree (cherry picked) and via Paul's as part of his second
> merge of the topic branch.
>
> So unless you can give me a good reason I'll merge the tip of the topic
> branch into my next, as planned.

Yes, Paul's second merge did guarantee a mess, so go ahead.

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.  So the right workflow would have been:

- Paul submits topic branch A to you

- you merge A

- Paul merges topic branch A into his "next" branch

- Paul applies KVM-specific patches B1 on top of his "next" branch.

- Paul sends pull request to me (with A + kvmppc work).

As far as I understand, there was no reason for you to get B1.

The last two patches (let's call them B2) also didn't need to go through
the kvm-ppc branch at all.  You could have applied them directly on top
of A.  Linus then would get A and B2 from you, and A and B1 from me:

                  base -→ A -----→ B1
                          ↓        ↓
                   ppc -→ ▪        ▪ ←- kvm
                          ↓        |
                          B2       |
                          ↓        ↓
                      torvalds/linux.git


If necessary, things could have been arranged so that Linus got A and B2
from you, and all three of A/B1/B2 from me:

- Paul submits topic branch B2 to you, based on topic branch A

- you merge B2

- Paul merges B2 and I get it from him

The result would have been:

                  base -→ A -----→ B1
                          ↓ ↘      ↓
                   ppc -→ ▪   B2 → ▪
                          ↓ ↙      ↓
                          ▪        ▪ ←- kvm
                          ↓        ↓
                      torvalds/linux.git

Paolo

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: linux-next: manual merge of the kvm tree with the powerpc tree Michael Ellerman <mpe@ellerman.id.au> - 2017-02-14 09:50 +0100
  Re: linux-next: manual merge of the kvm tree with the powerpc tree Paolo Bonzini <pbonzini@redhat.com> - 2017-02-14 14:40 +0100
    Re: linux-next: manual merge of the kvm tree with the powerpc tree Michael Ellerman <mpe@ellerman.id.au> - 2017-02-15 12:20 +0100
      Re: linux-next: manual merge of the kvm tree with the powerpc tree Paolo Bonzini <pbonzini@redhat.com> - 2017-02-15 12:30 +0100

csiph-web