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

[Anthony Liguori <anthony@codemonkey.ws>]

On 08/11/2011 12:30 PM, Blue Swirl wrote:
> On Thu, Aug 11, 2011 at 1:46 PM, Anthony Liguori<aliguori@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

>