qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: "Justin M. Forbes" <jmforbes@linuxtx.org>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [RFC] QEMU 0.14.0 release plan
Date: Tue, 30 Nov 2010 11:15:21 +0100	[thread overview]
Message-ID: <4CF4CEB9.8020607@redhat.com> (raw)
In-Reply-To: <4CF3E619.5000309@codemonkey.ws>

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. :-)

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?)
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...


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. After all, 0.13 was
a bit of a mess because nobody knew when it would be released, but in
the end I don't think the additional time to stabilize in stable-0.13
hasn't hurt.

I admit that three months was really a bit long, but I think if we
planned for more than 10 days from the fork to the release (maybe a
month?), we would have much less trouble with predictability.

> I think we should also try to implement an Ack process for stable.  For 
> instance, I think it would make sense for Justin to send out stable 
> patch candidates regularly and require 3 community Acked-by's for the 
> patch to go into stable.  I'm not sure if this is too much process but 
> by the same token, as long as we full the above rule, this should be a 
> trivial step for folks to follow.

I think three Acks might be a bit too much, but requiring one or two
Acks probably makes sense. Though I think we need to consider that there
are areas where it would be easy to get five Acks, and other areas where
it's going to be hard enough to get at least one.

Kevin

  parent reply	other threads:[~2010-12-01  5:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-29 17:42 [Qemu-devel] [RFC] QEMU 0.14.0 release plan Anthony Liguori
2010-11-29 18:10 ` Alexander Graf
2010-11-29 19:29   ` Anthony Liguori
2010-11-29 19:58     ` Alexander Graf
2010-11-29 20:14       ` Anthony Liguori
2010-11-30 10:15 ` Kevin Wolf [this message]
2010-11-30 14:12   ` Anthony Liguori
2010-11-30 14:49     ` Kevin Wolf
2010-12-01 12:56       ` Luiz Capitulino
2010-12-02 16:13   ` Randy Smith
2010-12-02 22:06 ` Brian Jackson
2010-12-02 22:44   ` Nicholas A. Bellinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CF4CEB9.8020607@redhat.com \
    --to=kwolf@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=jmforbes@linuxtx.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).