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