From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels Date: Sun, 06 Nov 2011 20:11:02 +0100 Message-ID: <4EB6DBC6.2010404@redhat.com> References: <1320543320-32728-1-git-send-email-agraf@suse.de> <4EB65C5B.8070709@redhat.com> <4EB66036.4080102@redhat.com> <1320577728.1428.73.camel@jaguar> <4EB67486.1070105@redhat.com> <4EB67D17.7000701@redhat.com> <4EB680D9.2070706@redhat.com> <877C82F4-F07C-44AA-8722-3AF57CFC4597@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "kvm@vger.kernel.org list" , qemu-devel Developers , "linux-kernel@vger.kernel.org List" , Alexander Graf , Blue Swirl , Avi Kivity , =?ISO-8859-1?Q?Am=E9rico_Wang?= , Ingo Molnar , Linus Torvalds To: Pekka Enberg Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 11/06/2011 06:28 PM, Pekka Enberg wrote: > On Sun, Nov 6, 2011 at 7:15 PM, Alexander Graf wrote: >>> The difference here is that although I feel Alex's script is a >>> pointless project, I'm in no way opposed to merging it in the tree if >>> people use it and it solves their problem. Some people seem to be >>> violently opposed to merging the KVM tool and I'm having difficult >>> time understanding why that is. >> >> It's a matter of size and scope. Write a shell script that clones, builds and >> executes KVM Tool and throw it in testing/tools/ and I'll happily ack it! > > That's pretty much what git submodule would do, isn't it? Absolutely not. It would always fetch HEAD from the KVM tool repo. A submodule ties each supermodule commit to a particular submodule commit. > I really don't see the point in doing that. We want to be part of > regular kernel history and release cycle. But I'm pretty certain that, when testing 3.2 with KVM tool in a couple of years, I want all the shining new features you added in this time; I don't want the old end-2011 code. Same if I'm bisecting kernels, I don't want to build KVM tool once per bisection cycle, do I? Paolo