From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754088Ab2DPMxx (ORCPT ); Mon, 16 Apr 2012 08:53:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62841 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753717Ab2DPMxv (ORCPT ); Mon, 16 Apr 2012 08:53:51 -0400 Message-ID: <4F8C1652.7000004@redhat.com> Date: Mon, 16 Apr 2012 15:53:38 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Alexander Graf CC: Benjamin Herrenschmidt , Paul Mackerras , Linus Torvalds , linux-kernel , KVM list , Marcelo Tosatti , Paul Mackerras Subject: Re: [GIT PULL] KVM updates for the 3.4 merge window References: <4F688F48.6090303@redhat.com> <1332461414.2982.90.camel@pasglop> <4F6EEEC1.4030608@redhat.com> <20120326213809.GA29788@bloggs.ozlabs.ibm.com> <4F7191E8.7020804@redhat.com> <20120330120107.GA28503@bloggs.ozlabs.ibm.com> <4F784C4D.3000409@redhat.com> <1333314138.30734.17.camel@pasglop> <4F796C18.2040209@redhat.com> <1333359979.30734.48.camel@pasglop> <3BB9812B-6FE2-4370-9D55-D273364BFFD1@suse.de> In-Reply-To: <3BB9812B-6FE2-4370-9D55-D273364BFFD1@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/16/2012 03:47 PM, Alexander Graf wrote: > On 02.04.2012, at 11:46, Benjamin Herrenschmidt wrote: > > > On Mon, 2012-04-02 at 12:06 +0300, Avi Kivity wrote: > >>> The current process is such that it takes absolutely forever for our > >>> patches to get in, which is a major PITA for something in such state of > >>> active development. > >> > >> If the patches were posted two weeks earlier, they would have gone in. > > > > I believe on our side they were, but Alex took a while to make up his > > tree ... oh well.. > > Yes, because to me the kvm-ppc-next tree basically is the same semantically as -next for Avi. It's where patches cook a while to make sure they actually work. Nobody tests KVM PPC patches against kvm's master tree. All testing (compile and execution) happens against kvm-ppc-next. > > That's why I don't see the point in having it cook again in Avi's tree. At the end of the day the patches will surely become way too chewy ;). kvm.git next is exposed to linux-next, where they get tested quite a lot. Granted it's mostly build testing, and people are unlikely to test kvm there, but they will test the non-kvm bits that creep in there. > The alternative would be that I don't have a -next tree, just collect patches and immediately send them to Avi. That way the main kvm tree would be broken more often, but at least we don't get these horrible synchronization latencies. That works too. Don't post immediately; 2-3 week batches would reduce noise. -- error compiling committee.c: too many arguments to function