From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Stable branch releases? Date: Mon, 09 Feb 2009 22:07:39 +0200 Message-ID: <49908D0B.1040107@redhat.com> References: <49908368.4010707@us.ibm.com> <49908557.7050504@redhat.com> <49908668.1070909@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Anthony Liguori Return-path: Received: from mx2.redhat.com ([66.187.237.31]:43876 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753637AbZBIUHS (ORCPT ); Mon, 9 Feb 2009 15:07:18 -0500 In-Reply-To: <49908668.1070909@us.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: > Avi Kivity wrote: >> Anthony Liguori wrote: >>> Hi Avi, >>> >>> Since a number of people are using the maint/2.6.29 branch, perhaps >>> we could start doing releases from it? For instance, a kvm-74.1, >>> kvm-74.2, etc. set of releases. Likewise, when we start >>> maint/2.6.30, a new set of stable releases could follow. >> >> Yes, I want to do that. > > Ok, is there anything standing in the way of doing this? What would > prevent us from doing a stable release in the next few days even? Is > there anything we can do to help? > Nothing, really. There used to be the lack of a test suite but that's no longer the case. >> One question is what to call these releases, though. > > I'd like to see it be named kvm-XX.y or something like that to keep a > close association between what the base release was. For instance, > you wouldn't expect HPET support in kvm-74.3 but you may expect it if > it were kvm-stable-3 or something. Won't work - the kernel versions don't correspond to any kvm-xx release. Once a new release cycle is imminent, I only apply bugfixes to the tree that eventually goes into -rc1, and of course later updates are fixes only so it doesn't correspond to any kvm-xx release.. The kvm.git and kvm-userspace.git trees are really staging areas and I'd like to de-emphasise them if favor of the Linux and qemu trees. Maybe, once qemu starts making regular releases, we can name a combined kvm/qemu release after both trees (kvm-0.10.0/2.6.29-?)?? > >> I'd like to keep the kernel part synced with 2.6.x.y for as long as >> that's maintained. > > How do you deal with maint/2.6.29 right now in the kvm.git tree? Do > you sync that with the 2.6.x.y releases? Yes. As long as 2.6.29 is unreleased, maint/2.6.29 is Linus' tree. Any fixes to maint/2.6.29 only go in by way of Linus. Once 2.6.29 is released, maint/2.6.29 is synced to -stable (and commits only go in by way of -stable). Once 2.6.29.y is abandoned, I'm free to commit on my own. > >> Perhaps we can call these releases kvm-stable-x.y (though it would >> cause confusion with kvm-xx). > > If you're just suggesting introducing -stable, it really doesn't > matter to me. I don't think it's necessary FWIW. The problem is that x.y won't be a derivative of x, if x is a kvm-xx release. It's not just a string prefix. >> So, users of kvm-stable-x.y would be running the same code as users >> running Linux-2.6.x.y with the bundled kvm modules. > > I think the majority of utility in the release numbers are associated > with the userspace bits (maybe I'm a bit bias :-)). I don't think > most users care about the differences between 2.6.28 and 2.6.29 kernel > bits, but the different between kvm-74 and kvm-83 is very important > feature wise. So maybe we should name the release after the qemu version, or changeseg number, or snapshot date. I agree that most features come from qemu (and many kernel features depend on the actual host kernel, not just what kernel the modules were taken from). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.