qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [RFC] Planning for 1.0 (and freezing the master branch)
Date: Thu, 11 Aug 2011 23:54:48 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Red Hat/3.1.11-2.el6_1 Thunderbird/3.1.11

  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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]