[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] QEMU 0.14.0 release plan
From: |
Brian Jackson |
Subject: |
Re: [Qemu-devel] [RFC] QEMU 0.14.0 release plan |
Date: |
Thu, 2 Dec 2010 16:06:49 -0600 |
User-agent: |
KMail/1.13.2 (Linux/2.6.32-23-generic; KDE/4.4.2; i686; ; ) |
On Monday, November 29, 2010 11:42:49 am 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
Have you considered a frozen master style release like other projects use?
(Linux kernel, etc.)
Every project I follow that does this "branch stable keep master moving"
release thing has terrible releases every time. Patches don't make it back
into stable,etc... Basically a lot of the same stuff we saw for 0.13.
>
> 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.
>
> Thoughts?
>
> Regards,
>
> Anthony Liguori