From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Planning for the 0.11.0 release Date: Mon, 22 Jun 2009 18:57:25 -0500 Message-ID: <4A401A65.3080804@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: "qemu-devel@nongnu.org" , kvm-devel Return-path: Received: from e4.ny.us.ibm.com ([32.97.182.144]:55401 "EHLO e4.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751955AbZFVX5Y (ORCPT ); Mon, 22 Jun 2009 19:57:24 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n5MNqMeJ019187 for ; Mon, 22 Jun 2009 19:52:22 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5MNvRkD236490 for ; Mon, 22 Jun 2009 19:57:27 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n5MNt6la024040 for ; Mon, 22 Jun 2009 19:55:06 -0400 Sender: kvm-owner@vger.kernel.org List-ID: Hi, It's getting to be about the time to start thinking about the 0.11.0 release. 0.10.0 was released on March 2nd so following with the 6 month release cycle, that would put 0.11.0 at September 2nd. Based on the experiences with the stable releases, here's what I'd recommend: o On July 15th, fork master -> stable-0.11 o Change version to 0.10.90 o Release qemu-0.11.0-rc1 o Release additional -rcN releases every 1-2 weeks o Introduce a new maintainer for stable-0.10 (via git pulls) o At least 1 week before release, hopefully we'll have the final -rcN that we can then declare 0.11.0. I think we should really try hard to make these dates. I only have a few things that I would like to see happen before forking stable-0.11. Namely: o Setup qemu.org infrastructure (git hosting, wiki) o Setup qemu bug tracker (see next mail) o Include all ROM source code in tree via git submodules. This is a major headache for distributors and I think it's important to resolve before our next release. o Disable kqemu by default. The intention is _not_ to remove kqemu support. Enabling kqemu by default causes a few unpleasant side effects including errors if -m is greater than 1/2 of the host physical memory. I don't expect the qdev conversion will be complete by 0.11. I think we should try to get as much of the invasive changes as possible in to make stable-0.11 as maintainable as possible. However, I think it would be a mistake to gate the release on qdev. -- Regards, Anthony Liguori