From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Stable branch releases? Date: Mon, 09 Mar 2009 10:56:06 -0500 Message-ID: <49B53C16.10706@us.ibm.com> References: <49908368.4010707@us.ibm.com> <49908557.7050504@redhat.com> <49908668.1070909@us.ibm.com> <5d6222a80902091149u3675673dk1619abab6b6580bb@mail.gmail.com> <49908DCC.1090901@redhat.com> <499095B0.3000103@us.ibm.com> <49B4F0EC.8020403@redhat.com> <49B51F37.8030906@us.ibm.com> <49B52A3B.6060301@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Glauber Costa , kvm-devel To: Avi Kivity Return-path: Received: from e6.ny.us.ibm.com ([32.97.182.146]:55965 "EHLO e6.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751258AbZCIP4L (ORCPT ); Mon, 9 Mar 2009 11:56:11 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n29FvJir001189 for ; Mon, 9 Mar 2009 11:57:19 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n29Fu93Q165328 for ; Mon, 9 Mar 2009 11:56:09 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n29FsmQR000803 for ; Mon, 9 Mar 2009 11:54:48 -0400 In-Reply-To: <49B52A3B.6060301@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > > I was hoping someone (=you) would verify that it means what I think it > means. I'm the wrong person to ask :-/ >> In terms of actual releases, I'd really like to see a kvm-0.10.0-0 >> release based on the qemu-0.10.0 release that didn't contain any >> kernel modules. > > Pretty soon I'll fork maint/2.6.30, that's a good time for forking > kvm-userspace.git. I could fork at the point qemu-0.10.0 was released. > > Unfortunately, the last qemu merge pulled in post-0.10.0 bits. I > guess I could back them out. It isn't going to be pretty. From a stable maintenance point-of-view, having the kvm stable tree based on stable_0_10 will make your life a lot easier since you only have to worry about tracking kvm-specific stable fixes. Fixing up the tree now will be painful. You could either merge back the older tree or revert changes in the QEMU tree until you get to release_0_10_0. Then merging against stable_0_10 would be pretty easy. None of it is very bisect friendly though :-/ >> Ideally, we would move libkvm into the qemu tree and collapse the >> tree too so it looked very much like qemu does today. > > I have a script that takes qemu-userspace.git and rewrites it to > multiple repositories (one per subdirectory, basically, plus one > top-level). That allows us to keep the bios, testsuite, external > module compat kit, etc. Great. I know you dislike it conceptually, but it's worth considering splitting out the KVM bios changes into patches as part of the patch queue that's in qemu SVN. It can potentially help the distros manage the KVM and QEMU bios builds in the same mechanism. What do you plan to do about non-stable KVM releases? Regards, Anthony Liguori