From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48312) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SawmC-0005wi-CN for qemu-devel@nongnu.org; Sat, 02 Jun 2012 18:26:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SawmA-0006bp-Bv for qemu-devel@nongnu.org; Sat, 02 Jun 2012 18:26:27 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:51735) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SawmA-0006aI-5S for qemu-devel@nongnu.org; Sat, 02 Jun 2012 18:26:26 -0400 Received: by pbbro12 with SMTP id ro12so4824035pbb.4 for ; Sat, 02 Jun 2012 15:26:24 -0700 (PDT) Message-ID: <4FCA9307.2090508@codemonkey.ws> Date: Sun, 03 Jun 2012 06:26:15 +0800 From: Anthony Liguori MIME-Version: 1.0 References: <4FC9E241.5020305@codemonkey.ws> <4FCA8E86.4000808@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] QEMU 1.2.0 Release Schedule List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Blue Swirl , qemu-devel On 06/03/2012 06:11 AM, Peter Maydell wrote: > On 2 June 2012 23:07, Anthony Liguori wrote: >> On 06/03/2012 04:16 AM, Blue Swirl wrote: >>> I think the previous freeze was a bit long, mainly the problem is how >>> to handle merging of different development trees (QOM vs. PPC for >>> example). So 2,5 weeks could be nice. >> >> Yes, I feel it was a little long also. > > I agree that the period when master was closed was too long, > but if we shorten the freeze period will we still have time > to collect all the bugfixes that crop up? I felt it was a bit too long because unlike the 1.0 release and previous 0.15 release, we didn't have any major issues that needed fixing during -rc. I attribute that to the fact that we did a little bit more planning up front and avoided surprises. > One option would be > to decouple these two things by actually branching for release > at some point so we can reopen master before release. I really don't want to do that. That's the method we used for the early part of our history. It resulted in a lot of people ignoring the releases entirely. Freezing master causes everyone to focus on the release instead of future looking development. That's a feature, not a bug :-) Regards, Anthony Liguori > > -- PMM >