On 08/11/2011 12:30 PM, Blue Swirl wrote:
On Thu, Aug 11, 2011 at 1:46 PM, Anthony Liguori<aligu...@us.ibm.com> wrote:
Hi,
I've posted an initial proposal for the 1.0 release on the wiki[1].
The release would be targeted for December 1st. Unlike previous releases,
I'm proposing that instead of forking master into a stable branch and
releasing from there, we stop taking features into master and all work on
stablizing master.
Historically, we forked stable for the releases simply because it was the
least intrusive way to get us on a somewhat reasonable release schedule. I
think especially since we're targeting a 1.0, we're ready to get a bit more
serious about releases.
Even more historically, with CVS, not forking was the only way.
Indeed :-)
3) Feature development can still happen in maintainers trees. I think this
is an important step to moving to a merge-window based development model
which I think will be our best way to scale long term.
Obviously, this will only work well if all the maintainers participate so
I'd really like to hear what everyone thinks about this.
[1] http://wiki.qemu.org/Planning/1.0
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. Conversely, I feel like more than 2 weeks on a different branch
is too long because people move on to shinier things.
That's why I'm proposing 4 weeks of hard freeze w/o opening up a new
development branch. That gives us more time to iron out any issues and
makes sure people still keep focusing on stability.
I want to move to 4 weeks primarily because I want to increase the
amount of release testing we do. We haven't had a really active set of
stable releases in a long time so for the most part, the .0 or .1
release is what people are going to be using. I think that means that
we should put a bit more effort into making .0 be as strong as it can be.
I'm not convinced about merge window model at least how it's used with
Linux kernel development. There will be a lot of breakage during the
merge window. Major changes at the same time would need major rebasing
efforts since they would be developed and merged within same time
frame. Also pretty strong coordination would be needed. We don't have
the luxury of infinite army of monkeys lead by genius who has
dedicated his entire life to the project like kernel has. I'd rather
try to keep the code base at (sort of) release quality at all times
and merge changes every now and then.
That's why I started with a 4 week freeze proposal :-) It gives us a
chance to try it out. If it works well, maybe we try 6-8 weeks for 1.1.
If it doesn't, we can drop back down to 2.
As long as we're not making massive changes, I think its a good idea to
experiment a bit.
Regards,
Anthony Liguori
