Re: [Qemu-devel] Release plan for 0.12.0

[Luiz Capitulino <lcapitulino@redhat.com>]

On Wed, 30 Sep 2009 08:05:16 -0500
Anthony Liguori <aliguori@us.ibm.com> wrote:

> Avi Kivity wrote:
> > On 09/30/2009 01:54 AM, Anthony Liguori wrote:
> >> Hi,
> >>
> >> Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0.
> >>
> >> I'd like to do a few things different this time around.  I don't 
> >> think the -rc process went very well as I don't think we got more 
> >> testing out of it.  I'd like to shorten the timeline for 0.12.0 a 
> >> good bit.  The 0.10 stable tree got pretty difficult to maintain 
> >> toward the end of the cycle.  We also had a pretty huge amount of 
> >> change between 0.10 and 0.11 so I think a shorter cycle is warranted.
> >>
> >> I think aiming for early to mid-December would give us roughly a 3 
> >> month cycle and would align well with some of the Linux distribution 
> >> cycles.  I'd like to limit things to a single -rc that lasted only 
> >> for about a week.  This is enough time to fix most of the obvious 
> >> issues I think.
> >>
> >> I'd also like to try to enumerate some features for this release.  
> >> Here's a short list of things I expect to see for this release 
> >> (target-i386 centric).  Please add or comment on items that you'd 
> >> either like to see in the release or are planning on working on.
> >>
> >> o VMState conversion -- I expect most of the pc target to be completed
> >> o qdev conversion -- I hope that we'll get most of the pc target 
> >> completely converted to qdev
> >> o storage live migration
> >> o switch to SeaBIOS (need to finish porting features from Bochs)
> >> o switch to gPXE (need to resolve slirp tftp server issue)
> >> o KSM integration
> >> o in-kernel APIC support for KVM
> >> o guest SMP support for KVM
> >> o updates to the default pc machine type
> >
> > Machine monitor protocol.
> 
> If we're going to support the protocol for 0.12, I'd like to most of the 
> code merged by the end of October.

 Four weeks.. Not so much time, but let's try.

 There are two major issues that may delay QMP.

 Firstly, we are still on the infrastructure/design phase, which
is natural to take time. Maybe when handlers start getting converted
en masse things will be faster.

 Secondly: testing. I have a very ugly python script to test the
already converted handlers. The problem is not only the ugliness,
the right way to do this would be to use kvm-autotest. So, I was
planning to take a detailed look at it and perhaps start writing
tests for QMP right when each handler is converted. Right Thing,
but takes time.