Re: Stable branch releases?

[Anthony Liguori <aliguori@us.ibm.com>]

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