[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] QEMU 0.14.0 release plan
Re: [Qemu-devel] [RFC] QEMU 0.14.0 release plan
Wed, 1 Dec 2010 10:56:51 -0200
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 =
| Begin of 0.15 development phase
| Bug day
| Release qemu-0.15.0-rc1;
| Release qemu-0.15.0-rc2; should be final if no changes
| Release qemu-0.15.0
= Targeted Features =
= Blocker Bugs =
I've put this in:
And have also written:
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
> >> 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
> >> 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.