Re: Stable branch releases?

[Avi Kivity <avi@redhat.com>]

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.