From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38751) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEIDX-0006ns-BF for qemu-devel@nongnu.org; Mon, 04 Aug 2014 09:22:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XEIDP-0005Oy-Mq for qemu-devel@nongnu.org; Mon, 04 Aug 2014 09:22:23 -0400 Received: from s16892447.onlinehome-server.info ([82.165.15.123]:43169) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEIDP-0005Iv-G3 for qemu-devel@nongnu.org; Mon, 04 Aug 2014 09:22:15 -0400 Message-ID: <53DF88ED.30405@ilande.co.uk> Date: Mon, 04 Aug 2014 14:21:49 +0100 From: Mark Cave-Ayland MIME-Version: 1.0 References: <20140801164142.5291.7527@loki> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [ANNOUNCE] QEMU 2.1.0 is now available List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Michael Roth Cc: QEMU Developers On 01/08/14 23:33, Peter Maydell wrote: > On 1 August 2014 17:41, Michael Roth wrote: >> On behalf of the QEMU Team, I'd like to announce the availability of >> the QEMU 2.1.0 release. This release contains 2200+ commits from 180 >> authors. > >> Thank you to everyone involved! > > Yep, thanks to everybody who helped get this one out of the door; > trunk is now re-opened for 2.2 development. > > If there's anything you think we should maybe try to do better or > differently next time round, now might be a good time to suggest it. > Personally I think it went reasonably well and I was happy with the > length of hardfreeze time. We should remember to ask for updates > of the message translations at rc0/rc1 time rather than having them > appear very late in the cycle, perhaps. Indeed. One of the things I felt helped was that patchsets spanning across the entire tree, e.g. display changes and QOM changes were applied sooner in the release cycle which I felt helped reduce rebase clashes as release drew closer. The only improvement I would like to see is for maintainers to try and regularly flush their patch queues where possible, to help prevent patchsets of over 100 emails being posted to the lists (naming no names in order to protect the innocent of course ;). ATB, Mark.