From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Stable branch releases? Date: Mon, 09 Mar 2009 16:39:55 +0200 Message-ID: <49B52A3B.6060301@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> <49B4F0EC.8020403@redhat.com> <49B51F37.8030906@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]:46362 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751018AbZCIOj7 (ORCPT ); Mon, 9 Mar 2009 10:39:59 -0400 In-Reply-To: <49B51F37.8030906@us.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: > Avi Kivity wrote: >> Anthony Liguori wrote: >>> 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? > > That's close to sounding like git-giberish to me but if you think > it'll do what you want it to do then it works for me :-) I was hoping someone (=you) would verify that it means what I think it means. > 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. > 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. -- error compiling committee.c: too many arguments to function