From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Stable branch releases? Date: Mon, 09 Mar 2009 12:35:24 +0200 Message-ID: <49B4F0EC.8020403@redhat.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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Glauber Costa , kvm-devel To: Anthony Liguori Return-path: Received: from mx2.redhat.com ([66.187.237.31]:44957 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753358AbZCIKf3 (ORCPT ); Mon, 9 Mar 2009 06:35:29 -0400 In-Reply-To: <499095B0.3000103@us.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: > Avi Kivity wrote: >> Glauber Costa wrote: >>> >>> As we're getting close to kvm-xxx anyway, maybe we could forget this >>> number >>> scheme, and adopt something that tracks linux. This way, you know >>> exactly what >>> kernel a released is based on. Something in the lines of kvm-29.1 >>> for updates >>> to the .29 series, (of course _this_ scheme is bad, because it >>> brings clashes) >>> >> >> It also ignores qemu, which is larger contributor to user visible >> features... >> >> Maybe stable releases should have separate packages for kvm and qemu: >> kvm-modules-2.6.29.1 and qemu-kvm-0.9.1.17. Users would pick the >> latest of each, and would only need to upgrade a component that's >> changed. > > Yes, this would be IMHO the best overall solution. Can we take > kvm-userspace maint/2.6.29 and call it qemu-kvm-0.9.1-1? Most users > don't need newer kernel modules if they have a relatively recent distro. > There's a slight snag here. The kernel module wants bits from the userspace package (the backward compatibility kit and makefiles); the userspace package wants some kernel bits (header files). I think we can work around it by using 'git symbolic-ref'. kvm.git would have a maint/2.6.29 branch, which would have an alias called maint/0.9.1. Similarly, kvm-userspace.git would have a branch called maint/0.9.1, with an alias called maint/2.6.29. Commits into one would automatically appear on the other. This sound reasonable? -- error compiling committee.c: too many arguments to function