[Qemu-devel] [RFC] QEMU 1.2.0 Release Schedule

[Qemu-devel] [RFC] QEMU 1.2.0 Release Schedule

[Anthony Liguori]

Summary: GA on September 1st, shorten feature freeze to 2.5 weeks.

We've discussed a lot in the past moving to a quarterly release cycle.  More 
frequent releases will allow distributions to more easily ship newer versions of 
QEMU.

Here's the schedule (also available on the wiki):

http://wiki.qemu.org/Planning/1.2

| 2011-06-01
| Beginning of 1.2 development phase
|-
| 2012-07-01
| [[Planning/Sprint|Sprint]] 1
|-
| 2012-08-01
| [[Planning/SoftFeatureFreeze|Soft feature freeze]].  Major features should 
have initial code committed by this date.
|-
| 2012-08-15
| [[Planning/HardFeatureFreeze|Hard feature freeze]].  Tag v1.2.0-rc0, only bug 
fixes committed after this point
|-
| 2012-08-22
| Tag v1.2.0-rc1
|-
| 2012-08-29
| Tag v1.2.0-rc2
|-
| 2012-09-01
| Tag v1.2.0

Regards,

Anthony Liguori

Re: [Qemu-devel] [RFC] QEMU 1.2.0 Release Schedule

[Blue Swirl]

On Sat, Jun 2, 2012 at 9:52 AM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Summary: GA on September 1st, shorten feature freeze to 2.5 weeks.
>
> We've discussed a lot in the past moving to a quarterly release cycle.  More
> frequent releases will allow distributions to more easily ship newer
> versions of QEMU.

I think the previous freeze was a bit long, mainly the problem is how
to handle merging of different development trees (QOM vs. PPC for
example). So 2,5 weeks could be nice.

But in the same way, if we now try three months' cycle and it turns
out to be too short (vacations during summer in northern hemisphere),
maybe we can try four months' cycle (3 releases/year) next year.

>
> Here's the schedule (also available on the wiki):
>
> http://wiki.qemu.org/Planning/1.2
>
> | 2011-06-01
> | Beginning of 1.2 development phase
> |-
> | 2012-07-01
> | [[Planning/Sprint|Sprint]] 1
> |-
> | 2012-08-01
> | [[Planning/SoftFeatureFreeze|Soft feature freeze]].  Major features should
> have initial code committed by this date.
> |-
> | 2012-08-15
> | [[Planning/HardFeatureFreeze|Hard feature freeze]].  Tag v1.2.0-rc0, only
> bug fixes committed after this point
> |-
> | 2012-08-22
> | Tag v1.2.0-rc1
> |-
> | 2012-08-29
> | Tag v1.2.0-rc2
> |-
> | 2012-09-01
> | Tag v1.2.0
>
> Regards,
>
> Anthony Liguori
>

Re: [Qemu-devel] [RFC] QEMU 1.2.0 Release Schedule

[Anthony Liguori]

On 06/03/2012 04:16 AM, Blue Swirl wrote:
> On Sat, Jun 2, 2012 at 9:52 AM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>> Summary: GA on September 1st, shorten feature freeze to 2.5 weeks.
>>
>> We've discussed a lot in the past moving to a quarterly release cycle.  More
>> frequent releases will allow distributions to more easily ship newer
>> versions of QEMU.
>
> I think the previous freeze was a bit long, mainly the problem is how
> to handle merging of different development trees (QOM vs. PPC for
> example). So 2,5 weeks could be nice.

Yes, I feel it was a little long also.

> But in the same way, if we now try three months' cycle and it turns
> out to be too short (vacations during summer in northern hemisphere),
> maybe we can try four months' cycle (3 releases/year) next year.

Absolutely.

Regards,

Anthony Liguori

>>
>> Here's the schedule (also available on the wiki):
>>
>> http://wiki.qemu.org/Planning/1.2
>>
>> | 2011-06-01
>> | Beginning of 1.2 development phase
>> |-
>> | 2012-07-01
>> | [[Planning/Sprint|Sprint]] 1
>> |-
>> | 2012-08-01
>> | [[Planning/SoftFeatureFreeze|Soft feature freeze]].  Major features should
>> have initial code committed by this date.
>> |-
>> | 2012-08-15
>> | [[Planning/HardFeatureFreeze|Hard feature freeze]].  Tag v1.2.0-rc0, only
>> bug fixes committed after this point
>> |-
>> | 2012-08-22
>> | Tag v1.2.0-rc1
>> |-
>> | 2012-08-29
>> | Tag v1.2.0-rc2
>> |-
>> | 2012-09-01
>> | Tag v1.2.0
>>
>> Regards,
>>
>> Anthony Liguori
>>

Re: [Qemu-devel] [RFC] QEMU 1.2.0 Release Schedule

[Peter Maydell]

On 2 June 2012 23:07, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 06/03/2012 04:16 AM, Blue Swirl wrote:
>> I think the previous freeze was a bit long, mainly the problem is how
>> to handle merging of different development trees (QOM vs. PPC for
>> example). So 2,5 weeks could be nice.
>
> Yes, I feel it was a little long also.

I agree that the period when master was closed was too long,
but if we shorten the freeze period will we still have time
to collect all the bugfixes that crop up? One option would be
to decouple these two things by actually branching for release
at some point so we can reopen master before release.

-- PMM

Re: [Qemu-devel] [RFC] QEMU 1.2.0 Release Schedule

[Anthony Liguori]

On 06/03/2012 06:11 AM, Peter Maydell wrote:
> On 2 June 2012 23:07, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>> On 06/03/2012 04:16 AM, Blue Swirl wrote:
>>> I think the previous freeze was a bit long, mainly the problem is how
>>> to handle merging of different development trees (QOM vs. PPC for
>>> example). So 2,5 weeks could be nice.
>>
>> Yes, I feel it was a little long also.
>
> I agree that the period when master was closed was too long,
> but if we shorten the freeze period will we still have time
> to collect all the bugfixes that crop up?

I felt it was a bit too long because unlike the 1.0 release and previous 0.15 
release, we didn't have any major issues that needed fixing during -rc.  I 
attribute that to the fact that we did a little bit more planning up front and 
avoided surprises.

> One option would be
> to decouple these two things by actually branching for release
> at some point so we can reopen master before release.

I really don't want to do that.  That's the method we used for the early part of 
our history.  It resulted in a lot of people ignoring the releases entirely. 
Freezing master causes everyone to focus on the release instead of future 
looking development.  That's a feature, not a bug :-)

Regards,

Anthony Liguori

>
> -- PMM
>