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

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

[Anthony Liguori]

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.

Thoughts?

Regards,

Anthony Liguori

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

[Alexander Graf]

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.

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


Alex

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

[Anthony Liguori]

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
>
>    

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

[Alexander Graf]

On 29.11.2010, at 20:29, Anthony Liguori wrote:

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

I was thinking of a more sophisticated model. Maybe 1 maintainer + 1 user? Or 1 person who knows his way around the area + 1 more?

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

The desire is to have an easy to set tag. [STABLE] to me indicates that the patch is specifically made for stable. CC to stable@ tells me that the patch should go into stable as soon as it's submitted upstream and if it doesn't apply cleanly, the stable maintainer nags the author about a backport.


Alex

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

[Anthony Liguori]

On 11/29/2010 01:58 PM, Alexander Graf wrote:
> On 29.11.2010, at 20:29, Anthony Liguori wrote:
>
>    
>> Is 2 just right?
>>      
> I was thinking of a more sophisticated model. Maybe 1 maintainer + 1 user? Or 1 person who knows his way around the area + 1 more?
>    

+ 1 user?  cute :-)

2 Acks seems like a good place to start.

>>      
>>>> 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.
>>      
> The desire is to have an easy to set tag. [STABLE] to me indicates that the patch is specifically made for stable. CC to stable@ tells me that the patch should go into stable as soon as it's submitted upstream and if it doesn't apply cleanly, the stable maintainer nags the author about a backport.
>    

Okay, as long as stable is just there for CC and qemu-devel stays in the 
loop.  Can't do it right now but remind me again when Savannah is back up.

Regards,

Anthony Liguori

> Alex
>
>    

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

[Kevin Wolf]

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

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

[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.

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

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

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.

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

Certainly true.

Regards,

Anthony Liguori

> Kevin
>    

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

[Kevin Wolf]

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.

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

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

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

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

[Luiz Capitulino]

On Tue, 30 Nov 2010 15:49:24 +0100
Kevin Wolf <kwolf@redhat.com> 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
> 

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

[Randy Smith]

[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

On Tue, 30 Nov 2010, 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. :-)
> 
> 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...

I would suggest a very short release schedule similar to what Parrot
and Perl have been using. Release every month. If a feature isn't
ready for this month's release, the next release is just a month away
and it's no big deal. Rather than lay it all out here, you can read
about the process at
http://www.modernperlbooks.com/mt/2009/04/the-rapid-release-tautology.html.


[snip]

-- 
Randy Smith
http://www.vuser.org/
http://perlstalker.blogspot.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Brian Jackson]

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

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

[Nicholas A. Bellinger]

On Thu, 2010-12-02 at 16:06 -0600, Brian Jackson wrote:
> 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.
> 
> 

Being fimilar with the kernel development process but not fimilar with
pre qemu-kvm.git development process, I would tend to agree with you
here..

Aside from that question, the one thing that is really useful in the
kernel development world is having an automated process to CC
stable@kernel.org in order to signal that a bugfix commit from 'master'
should be propigated down into stable trees and/or branches works very
well.  This really simplfies the bug backport process, compared to say
each needing to do this by hand across a number of old stable versions.

This is how Greg-KH and kernel subsystem maintainers do things, and the
system works quite well with Greg tracking a handful of rolling stable
releases.  I am not sure if Anthony already has such an automated system
in place for QEMU yet, but I think it would really be helpful for
propigating master bugfixes back into stable code.

Best,

--nab