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