Re: [Qemu-devel] [RFC] Planning for 1.0 (and freezing the master branch)

[Blue Swirl]

On Sun, Aug 14, 2011 at 1:46 PM, Anthony Liguori <address@hidden> wrote:
> On 08/12/2011 03:46 PM, Blue Swirl wrote:
>>
>> On Thu, Aug 11, 2011 at 9:54 PM, Gerd Hoffmann<address@hidden>  wrote:
>>>
>>>  Hi,
>>>
>>>>> In general the idea is OK. Especially soft freeze could solve problems
>>>>> like those qemu-ga inclusion had.
>>>>>
>>>>> Two weeks for soft freeze would be close to OK but I think a month of
>>>>> hard freeze is too long. With the previous releases, the problems in
>>>>> stable were ironed out within a week or two. How about 2 + 2?
>>>>
>>>> I feel like 2 weeks was too short for this release and releases in the
>>>> past.
>>>
>>> Well, one reason for the release process not being that smooth is that a
>>> big
>>> pile of stuff was merged just before 0.15-rc0.  First because there was a
>>> noticable backlog due to maintainers vacation, and second because a bunch
>>> of
>>> people wanted there stuff be merged for 0.15.
>>>
>>> I think two weeks soft freeze and two weeks hard freeze should work
>>> reasonable well.  I think shorter release cycles will help too, so the
>>> pressure to get stuff in before the freeze is lower as the following
>>> release
>>> isn't that far away.
>>>
>>> So how about this:
>>>
>>>  - roughly four weeks development phase.
>>>  - two weeks soft freeze (aka no big stuff).
>>>  - two weeks hard freeze (aka bugfixes only).
>>
>> This 50% duty cycle would mean that for half of the time, people only
>> work within their forked trees and then try to merge these forks. I
>> think the rate should be something like 80% merging, 20% freeze, which
>> (with one month freeze) would be close to current speed of two
>> releases per year.
>>
>> I agree releasing more often is better, but for that to work, I'd go
>> for something like:
>> - 2 months development
>> - two weeks soft freeze
>> - fork stable rc0, release after 2 to 4 weeks
>
> Maybe something more like:
>
> 2 months development
> -rc0 goes out (master enters soft feature freeze)

Why an rc0 at this point? 0.15-rc0 was in a bad shape because it was
forked just after heavy development (ga etc). I'd nominate release
candidates only after soft freeze, then there would not be any major
changes. Though a rc0 could attract testing efforts from outside and
for those, the earlier the better.

> 2 weeks development in master, stabilization and careful consideration of
> new features
> -rc1 goes out (master enters hard feature freeze)
> 1 week stabilization
> -rc2 goes out
> 1 week stabilization
> -rc3 goes out, -rc3 becomes release

So at this point master would be released? What's the difference in
time between rc3 and release?

Overall this would only give a duty cycle of 67%. For 4 weeks total
freeze, the development would need to be 4 months for an 80% duty
cycle. But I think this version could work too.

> I think a shorter cycle could work better long term.  I think it needs to be
> done as part of the master branch though and I'd wait until 1.1 to implement
> it.
>
> Regards,
>
> Anthony Liguori
>