From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753942AbdBNNgG (ORCPT ); Tue, 14 Feb 2017 08:36:06 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49020 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753921AbdBNNe0 (ORCPT ); Tue, 14 Feb 2017 08:34:26 -0500 Subject: Re: linux-next: manual merge of the kvm tree with the powerpc tree To: Michael Ellerman , Stephen Rothwell , Marcelo Tosatti , Gleb Natapov , KVM , Benjamin Herrenschmidt , PowerPC References: <20170210145943.5bf98310@canb.auug.org.au> <60b17c77-fb90-20e7-8cc7-a5970d2e5691@redhat.com> <87k28tma8d.fsf@concordia.ellerman.id.au> Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Paul Mackerras , Nicholas Piggin From: Paolo Bonzini Message-ID: <4a43b8ed-bd08-f8e8-e749-178bb3bac815@redhat.com> Date: Tue, 14 Feb 2017 14:34:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <87k28tma8d.fsf@concordia.ellerman.id.au> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 14 Feb 2017 13:34:07 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: linux-next: manual merge of the kvm tree with the powerpc tree Date: Tue, 14 Feb 2017 14:34:01 +0100 Message-ID: <4a43b8ed-bd08-f8e8-e749-178bb3bac815@redhat.com> References: <20170210145943.5bf98310@canb.auug.org.au> <60b17c77-fb90-20e7-8cc7-a5970d2e5691@redhat.com> <87k28tma8d.fsf@concordia.ellerman.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <87k28tma8d.fsf@concordia.ellerman.id.au> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" To: Michael Ellerman , Stephen Rothwell , Marcelo Tosatti , Gleb Natapov , KVM , Benjamin Herrenschmidt , PowerPC Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Nicholas Piggin List-Id: linux-next.vger.kernel.org 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