All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Alexander Graf <agraf@suse.de>
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: Mon, 29 Nov 2010 13:29:22 -0600	[thread overview]
Message-ID: <4CF3FF12.60707@codemonkey.ws> (raw)
In-Reply-To: <9B5DDDCA-051D-459E-8B68-40945B15C195@suse.de>

On 11/29/2010 12:10 PM, Alexander Graf wrote:
> On 29.11.2010, at 18:42, Anthony Liguori wrote:
>
>    
>> Hi,
>>
>> 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.
>>
>> Here's what I propose:
>>
>> 12/6 - fork off stable-0.14 tree; simultaneously release qemu-0.14.0-rc0
>>
>> For the stable-0.14 tree, I'd like to have Justin be in charge of collecting patches.  For stable-0.14 submissions, patches (or pull requests) specifically marked as [STABLE 0.14] should be sent to the mailing list that are tested against that tree.  Sending a patch to against master with a comment saying "this should probably go to stable too" is not enough.
>>
>> 12/10 - release qemu-0.14.0-rc1
>>
>> 12/15 - release qemu-0.14.0-rc2; this should be the final release candidate with no changes make for GA other than a version bump
>>
>> 12/17 - release qemu-0.14.0
>>
>> Post qemu-0.14.0, Justin will handle the stable tree and subsequent stable releases.
>>
>> The rules for stable will continue to be what they are now.  Only bug fixes that are patches committed in master are candidates for stable (except in rare circumstances where that is not viable).
>>
>> 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.
>>      
> 3 is quite a lot.
>    

Is 2 just right?

>> Thoughts?
>>      
> Please set up a mailing list we can just CC for stable candidates, so they don't get lost. Motivation for keeping track of stable stuff differs between developers and it's essential to make the kick-off easily accessible. It's worked out very well for Linux, so why not for us?
>    

Is the desire to filter mail or have private discussions that are not on 
qemu-devel?

If it's the former, a [STABLE] tag in the subject would work just as 
well.  If it's the later, I think it runs contrary to the goal of 
getting more people involved in stable.

Regards,

Anthony Liguori

> Alex
>
>    

  reply	other threads:[~2010-11-29 19:29 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 [this message]
2010-11-29 19:58     ` Alexander Graf
2010-11-29 20:14       ` Anthony Liguori
2010-11-30 10:15 ` Kevin Wolf
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=4CF3FF12.60707@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=agraf@suse.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.