From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QsctR-0003Ku-DV for qemu-devel@nongnu.org; Sun, 14 Aug 2011 11:46:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QsctQ-0007UM-GI for qemu-devel@nongnu.org; Sun, 14 Aug 2011 11:46:29 -0400 Received: from mail-pz0-f42.google.com ([209.85.210.42]:34021) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QsctQ-0007UI-AK for qemu-devel@nongnu.org; Sun, 14 Aug 2011 11:46:28 -0400 Received: by pzk37 with SMTP id 37so7375299pzk.29 for ; Sun, 14 Aug 2011 08:46:27 -0700 (PDT) Message-ID: <4E47D1AC.70906@codemonkey.ws> Date: Sun, 14 Aug 2011 08:46:20 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E43DD21.9030907@us.ibm.com> <4E441DB7.9090501@codemonkey.ws> <4E444FA8.6040606@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Planning for 1.0 (and freezing the master branch) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Kevin Wolf , Stefan Hajnoczi , "Michael S. Tsirkin" , Marcelo Tosatti , "Justin M. Forbes" , qemu-devel , Gerd Hoffmann , "Edgar E. Iglesias" , Aurelien Jarno , Avi Kivity On 08/12/2011 03:46 PM, Blue Swirl wrote: > On Thu, Aug 11, 2011 at 9:54 PM, Gerd Hoffmann wrote: >> 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). > > This 50% duty cycle would mean that for half of the time, people only > work within their forked trees and then try to merge these forks. I > think the rate should be something like 80% merging, 20% freeze, which > (with one month freeze) would be close to current speed of two > releases per year. > > I agree releasing more often is better, but for that to work, I'd go > for something like: > - 2 months development > - two weeks soft freeze > - fork stable rc0, release after 2 to 4 weeks Maybe something more like: 2 months development -rc0 goes out (master enters soft feature freeze) 2 weeks development in master, stabilization and careful consideration of new features -rc1 goes out (master enters hard feature freeze) 1 week stabilization -rc2 goes out 1 week stabilization -rc3 goes out, -rc3 becomes release I think a shorter cycle could work better long term. I think it needs to be done as part of the master branch though and I'd wait until 1.1 to implement it. Regards, Anthony Liguori