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).
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
