Re: Stable branch releases?

[Avi Kivity <avi@redhat.com>]

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