Re: [Qemu-devel] [RFC] QEMU 0.14.0 release plan

[Luiz Capitulino]

On Tue, 30 Nov 2010 15:49:24 +0100
Kevin Wolf <address@hidden> wrote:

> Am 30.11.2010 15:12, schrieb Anthony Liguori:
> > On 11/30/2010 04:15 AM, Kevin Wolf wrote:
> >> Am 29.11.2010 18:42, schrieb Anthony Liguori:
> >>    
> >>> 0.13 was a mess of a release (largely due to my lack of time) and I'd
> >>> like to get us back onto a predictable schedule.
> >>>      
> >> Telling people six days in advance when the fork will be is hardly
> >> predictable. :-)
> > 
> > Yeah, I've been mentioning the desire to do 0.14 by EOY so hopefully it 
> > wasn't a huge surprise but it's certainly a valid statement.
> 
> Yeah, it's not a huge surprise, even though nobody could tell if it
> wouldn't be a week or two earlier or later. But it's the same pattern as
> we've had before with 0.13. Fork on very short notice and a RC phase
> that was planned to be short, and that results in a hurry to get
> everything in, in whatever state it may be.

I think there are two points here.

First, something we lack today is a very simple development plan before
(or during the first days of) a new development cycle. Something like
the following (in wiki format):

= Release Schedule =

{| border="1"
| 2010-12-18
| Begin of 0.15 development phase
|- 
| 2011-03-14
| Bug day
|-
| 2011-05-02
| Release qemu-0.15.0-rc1;
|-
| 2011-05-16
| Release qemu-0.15.0-rc2; should be final if no changes
|-
| 2011-05-23
| Release qemu-0.15.0
|}

= Targeted Features =

= Blocker Bugs =


I've put this in:

  http://wiki.qemu.org/Planning/0.15-example

And have also written:

  http://wiki.qemu.org/Planning/0.14

The other important point is that, our RCs don't get much tested. For a RC
cycle to be successful we need to limit patch scope and need to get the
tree tested.

> 
> >> For example, in the block area there are currently a lot of interesting
> >> patches on the list (AHCI, SCSI, block-queue, QED, Ceph) and there's no
> >> way to integrate them in time if we don't want to blindly apply patches
> >> and then see what breaks.
> >>
> >> What to do with them? The options I see are:
> >>
> >> 1. Move them all to 0.15 (when will it be?)
> >>    
> > 
> > Every 6 months so it would be June 2011.
> > 
> >> 2. Apply everything now, have a broken rc0 and hope to fix everything
> >>     in the short time until rc2
> >> 3. Fork 0.14 shortly before Christmas and move the release to January
> >>
> >> The usual approach for dealing with feature freeze deadlines seems to be
> >> option 2, though I don't really like that one...
> >>    
> > 
> > Yeah, obviously not the right thing to do.
> > 
> > Even though it sucks, I'd really like to do 0.14 before the year ends.
> 
> I don't quite agree with that (we have released 0.13 in October, so I'm
> not sure why it's so important to get the next release very soon), but I
> understand that I should have mentioned this before and not only now.
> Anything that will help avoiding option 2 as much as possible is fine
> with me.

Moving new stuff to 0.15 seems the better option to me, unless there's
agreement that it's in very good shape and that issues can be fixed in the
RC cycle.

> >> For 0.15 I suggest that the fork date should be announced at least a
> >> month in advance and that we have a longer RC phase.
> > 
> > By having a short -rc cycle, I'm trying to avoid the last minute push to 
> > include a lot of functionality into a release which usually ends up in 
> > things getting included before they're ready.
> > 
> > A short -rc cycle means that we get a .0 release that's a bit better 
> > than a git snapshot but ultimately is really just a point-in-time 
> > release verses a feature driven release.
> 
> The point is that we should pay attention that the quality of git master
> doesn't get worse shortly before a release because everything pushes his
> half-baked patches. Otherwise, if a release is only "a bit better" than
> git, it might not be better than a git snapshot when there's no release.
> 
> For a longer RC phase to work, it's obviously even more important that
> we take the freeze serious and treat it as a stable branch (in the
> future including the Ack process).

It's more than that, we have to get it tested. I think we don't.

PS: I'm receiving today's and yesterday's emails out of order, hope I'm
not mixing things up or duplicating someone's statements.

> I think that's one of the few things that has worked pretty well for
> 0.13. It might have been because everyone thought you'd release
> "tomorrow", so they didn't dare asking you to include more patches
> except for really important fixes - but I think this should be the
> regular process for RCs. After all they are "release candidates", not
> "some beta".
> 
> > We can certainly try a one month -rc cycle for 0.15.  With Justin 
> > helping, it might be much more useful than in the past.
> > 
> > We could push the final 0.14.0 release to 12/30 and I can make sure to 
> > be around to handle -rcs.  I suspect that the extra couple weeks over 
> > the holidays won't matter all that much but it gives everyone a bit more 
> > time before the tree freezes.  That would put us around 12/17 for 
> > stable-0.14 fork.
> 
> Sounds good. I should be able to get the block patches in until then
> even with a proper review and some testing.
> 
> Kevin
>