Stable branch releases?

Stable branch releases?

[Anthony Liguori]

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.

Regards,

Anthony Liguori

Re: Stable branch releases?

[Avi Kivity]

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.  One question is what to call these releases, 
though.

I'd like to keep the kernel part synced with 2.6.x.y for as long as 
that's maintained.  Perhaps we can call these releases kvm-stable-x.y 
(though it would cause confusion with kvm-xx).  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 have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: Stable branch releases?

[Anthony Liguori]

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?

>   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.

> 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?

> 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.

>   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.

Regards,

Anthony Liguori

Re: Stable branch releases?

[Glauber Costa]

On Mon, Feb 9, 2009 at 5:39 PM, Anthony Liguori <aliguori@us.ibm.com> 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?
>
>>  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.
>

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)

-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: Stable branch releases?

[Avi Kivity]

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.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: Stable branch releases?

[Anthony Liguori]

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.

Regards,

Anthony Liguori

Re: Stable branch releases?

[Avi Kivity]

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.
>

Right, that's another advantage of split repos.

I wonder about splitting the ordinary kvm-xx releases?  It means 
doubling the download/build/install cycle, but it will increase 
similarity to the stable releases.

-- 
error compiling committee.c: too many arguments to function

Re: Stable branch releases?

[Anthony Liguori]

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.
>>
>
> Right, that's another advantage of split repos.
>
> I wonder about splitting the ordinary kvm-xx releases?  It means 
> doubling the download/build/install cycle, but it will increase 
> similarity to the stable releases.

I was going to suggest that to but then wanted to avoid complicating 
things.  I think it's the right model.

Regards,

Anthony Liguori

Re: Stable branch releases?

[Avi Kivity]

Anthony Liguori wrote:
>>
>> I wonder about splitting the ordinary kvm-xx releases?  It means 
>> doubling the download/build/install cycle, but it will increase 
>> similarity to the stable releases.
>
> I was going to suggest that to but then wanted to avoid complicating 
> things.  I think it's the right model.

I have to get the package/build machinery to do that anyway.

-- 
error compiling committee.c: too many arguments to function

Re: Stable branch releases?

[Avi Kivity]

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

Re: Stable branch releases?

[Anthony Liguori]

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 :-)

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.  Ideally, we would move libkvm into the qemu tree and collapse 
the tree too so it looked very much like qemu does today.

Regards,

Anthony Liguori

Re: Stable branch releases?

[Avi Kivity]

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

Re: Stable branch releases?

[Anthony Liguori]

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

Re: Stable branch releases?

[Avi Kivity]

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.