From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrZt7-0006Hs-HU for qemu-devel@nongnu.org; Thu, 11 Aug 2011 14:21:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QrZt6-0003ul-3r for qemu-devel@nongnu.org; Thu, 11 Aug 2011 14:21:49 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:52748) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrZt5-0003uX-U8 for qemu-devel@nongnu.org; Thu, 11 Aug 2011 14:21:48 -0400 Received: by yxt3 with SMTP id 3so1797165yxt.4 for ; Thu, 11 Aug 2011 11:21:46 -0700 (PDT) Message-ID: <4E441DB7.9090501@codemonkey.ws> Date: Thu, 11 Aug 2011 13:21:43 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E43DD21.9030907@us.ibm.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 , Avi Kivity , "Edgar E. Iglesias" , Aurelien Jarno , Gerd Hoffmann On 08/11/2011 12:30 PM, Blue Swirl wrote: > On Thu, Aug 11, 2011 at 1:46 PM, Anthony Liguori 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 >