From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44779 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PNeYY-00070R-Bp for qemu-devel@nongnu.org; Tue, 30 Nov 2010 23:45:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PNQxf-0001LB-7F for qemu-devel@nongnu.org; Tue, 30 Nov 2010 09:13:40 -0500 Received: from mail-qy0-f173.google.com ([209.85.216.173]:57522) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PNQxf-0001C9-4n for qemu-devel@nongnu.org; Tue, 30 Nov 2010 09:13:39 -0500 Received: by qyk1 with SMTP id 1so1317386qyk.4 for ; Tue, 30 Nov 2010 06:13:34 -0800 (PST) Message-ID: <4CF50662.2050908@codemonkey.ws> Date: Tue, 30 Nov 2010 08:12:50 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] QEMU 0.14.0 release plan References: <4CF3E619.5000309@codemonkey.ws> <4CF4CEB9.8020607@redhat.com> In-Reply-To: <4CF4CEB9.8020607@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: "Justin M. Forbes" , qemu-devel On 11/30/2010 04:15 AM, Kevin Wolf wrote: > Am 29.11.2010 18:42, schrieb Anthony Liguori: > >> 0.13 was a mess of a release (largely due to my lack of time) and I'd >> like to get us back onto a predictable schedule. >> > Telling people six days in advance when the fork will be is hardly > predictable. :-) > Yeah, I've been mentioning the desire to do 0.14 by EOY so hopefully it wasn't a huge surprise but it's certainly a valid statement. > For example, in the block area there are currently a lot of interesting > patches on the list (AHCI, SCSI, block-queue, QED, Ceph) and there's no > way to integrate them in time if we don't want to blindly apply patches > and then see what breaks. > > What to do with them? The options I see are: > > 1. Move them all to 0.15 (when will it be?) > Every 6 months so it would be June 2011. > 2. Apply everything now, have a broken rc0 and hope to fix everything > in the short time until rc2 > 3. Fork 0.14 shortly before Christmas and move the release to January > > The usual approach for dealing with feature freeze deadlines seems to be > option 2, though I don't really like that one... > Yeah, obviously not the right thing to do. Even though it sucks, I'd really like to do 0.14 before the year ends. > For 0.15 I suggest that the fork date should be announced at least a > month in advance and that we have a longer RC phase. By having a short -rc cycle, I'm trying to avoid the last minute push to include a lot of functionality into a release which usually ends up in things getting included before they're ready. A short -rc cycle means that we get a .0 release that's a bit better than a git snapshot but ultimately is really just a point-in-time release verses a feature driven release. We can certainly try a one month -rc cycle for 0.15. With Justin helping, it might be much more useful than in the past. We could push the final 0.14.0 release to 12/30 and I can make sure to be around to handle -rcs. I suspect that the extra couple weeks over the holidays won't matter all that much but it gives everyone a bit more time before the tree freezes. That would put us around 12/17 for stable-0.14 fork. >> I think we should also try to implement an Ack process for stable. For >> instance, I think it would make sense for Justin to send out stable >> patch candidates regularly and require 3 community Acked-by's for the >> patch to go into stable. I'm not sure if this is too much process but >> by the same token, as long as we full the above rule, this should be a >> trivial step for folks to follow. >> > I think three Acks might be a bit too much, but requiring one or two > Acks probably makes sense. Though I think we need to consider that there > are areas where it would be easy to get five Acks, and other areas where > it's going to be hard enough to get at least one. > Certainly true. Regards, Anthony Liguori > Kevin >