From: Avi Kivity <avi@redhat.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Glauber Costa <glommer@gmail.com>, kvm-devel <kvm@vger.kernel.org>
Subject: Re: Stable branch releases?
Date: Mon, 09 Mar 2009 12:35:24 +0200 [thread overview]
Message-ID: <49B4F0EC.8020403@redhat.com> (raw)
In-Reply-To: <499095B0.3000103@us.ibm.com>
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
next prev parent reply other threads:[~2009-03-09 10:35 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-09 19:26 Stable branch releases? Anthony Liguori
2009-02-09 19:34 ` Avi Kivity
2009-02-09 19:39 ` Anthony Liguori
2009-02-09 19:49 ` Glauber Costa
2009-02-09 20:10 ` Avi Kivity
2009-02-09 20:44 ` Anthony Liguori
2009-02-11 12:10 ` Avi Kivity
2009-02-11 13:13 ` Anthony Liguori
2009-02-11 13:18 ` Avi Kivity
2009-03-09 10:35 ` Avi Kivity [this message]
2009-03-09 13:52 ` Anthony Liguori
2009-03-09 14:39 ` Avi Kivity
2009-03-09 15:56 ` Anthony Liguori
2009-02-09 20:07 ` Avi Kivity
2012-04-11 17:07 Ian Campbell
2012-04-11 18:41 ` Keir Fraser
2012-04-11 23:11 ` Wei Huang
2012-04-12 8:13 ` Keir Fraser
2012-04-11 18:49 ` Stefano Stabellini
2012-04-12 10:47 ` Ian Jackson
2012-04-12 14:59 ` Ian Campbell
2012-04-12 16:04 ` Keir Fraser
2012-04-12 16:30 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49B4F0EC.8020403@redhat.com \
--to=avi@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=glommer@gmail.com \
--cc=kvm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.