From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57453) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYDUN-00077v-FJ for qemu-devel@nongnu.org; Thu, 10 Apr 2014 07:49:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WYDUH-0002lz-9c for qemu-devel@nongnu.org; Thu, 10 Apr 2014 07:49:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54832) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYDUH-0002lu-0L for qemu-devel@nongnu.org; Thu, 10 Apr 2014 07:49:45 -0400 Date: Thu, 10 Apr 2014 13:49:37 +0200 From: Kevin Wolf Message-ID: <20140410114937.GD4038@noname.redhat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] Should we have a 2.0-rc3 ? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "Michael S. Tsirkin" , QEMU Developers , Michael Roth , Alexander Graf , Anthony Liguori , Paolo Bonzini , Andreas =?iso-8859-1?Q?F=E4rber?= Am 10.04.2014 um 13:17 hat Peter Maydell geschrieben: > So far I know of at least three fixes which should probably > go into 2.0: > * my fix for the configure stack-protector checks on MacOSX > * MST's pull request updating the ACPI test blobs > * MST says we need to update the hex files for ACPI too > (otherwise you get a different ACPI blob depending on whether > your build system had iasl or not, if I understand correctly) > > Are there any others? I have three fixes in my queue, though none of them is bad enough to delay the release. However, if you're going to do an -rc3 anyway, let me know and I'll send a pull request for them. The bugs fixed are: * iscsi has an error path where the return value is undefined. * The bochs block driver has a buggy input validation check that can cause an out-of-bounds array read with corrupt images. > So we have two choices: > > (A) get those fixes into git today, and tag an rc3; that > would then need some testing time and presumably we'd hope > to tag it as the 2.0 release on Monday or Tuesday next week > > (B) say that the above are not worth fixing in 2.0 proper > and plan to do a 2.0.1 in a few weeks with the above plus > any other breakage that people find. > > Opinions? Either way is fine with me. Kevin