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

[Blue Swirl <blauwirbel@gmail.com>]

On Thu, Aug 11, 2011 at 9:54 PM, Gerd Hoffmann <kraxel@redhat.com> 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

This would still give 80/20 rate at the expense of hard freeze only
affecting stable fork, yielding four releases per year.

> Don't be too strict about this, if there is a reason to slip (xmas holiday
> season, summer vacation time, kvm forum, $bignewfeature took a bit longer to
> stabilize, $whateverelse) just stretch the development phase (or soft
> freeze) a bit.  We would probably end up with 4-5 releases/year when
> following this model.
>
>>> I'm not convinced about merge window model at least how it's used with
>>> Linux kernel development.
>
> Agree.  A short two-week merge window would work out nicely only if we would
> run a qemu-next so most issues can be sorted beforehand.  I don't think we
> have the man power to actually do that.
>
>>> I'd rather
>>> try to keep the code base at (sort of) release quality at all times
>>> and merge changes every now and then.
>
> Agree.  I think we are not that bad here today.  I'm running qemu from fresh
> master checkouts quite alot and I rarely hit bugs.
>
> cheers,
>  Gerd
>