From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions Date: Sat, 12 Nov 2011 12:20:25 +0200 Message-ID: <4EBE4869.8060401@redhat.com> References: <4EBAAA68.10801@redhat.com> <4EBAACAF.4080407@codemonkey.ws> <4EBAB236.2060409@redhat.com> <4EBAB9FA.3070601@codemonkey.ws> <4EBB919B.7040605@redhat.com> <4EBC0FC9.6030301@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Lucas Meneghel Rodrigues , Kevin Wolf , KVM mailing list , "Michael S. Tsirkin" , Marcelo Tosatti , QEMU devel , Juan Jose Quintela Carreira To: Anthony Liguori Return-path: In-Reply-To: <4EBC0FC9.6030301@codemonkey.ws> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 11/10/2011 07:54 PM, Anthony Liguori wrote: >> IMO, this should be a release blocker. qemu 1.0 only supporting >> migration on enterprise storage? > > > No, this is not going to block the release. > > You can't dump patches on the ML during -rc for an issue that has been > understood for well over a year simply because it's release time. > > If this was so important, it should have been fixed a year ago in the > proper way. Nor can you yank support for migration this way. Might as well put a big sign on 1.0, "Do Not Use This Release". Making formal plans and sticking to them is great, but not to the point of ignoring reality. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36958) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPAhQ-0005mP-O6 for qemu-devel@nongnu.org; Sat, 12 Nov 2011 05:20:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RPAhP-0004v9-Qp for qemu-devel@nongnu.org; Sat, 12 Nov 2011 05:20:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:21571) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPAhP-0004ux-Js for qemu-devel@nongnu.org; Sat, 12 Nov 2011 05:20:35 -0500 Message-ID: <4EBE4869.8060401@redhat.com> Date: Sat, 12 Nov 2011 12:20:25 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4EBAAA68.10801@redhat.com> <4EBAACAF.4080407@codemonkey.ws> <4EBAB236.2060409@redhat.com> <4EBAB9FA.3070601@codemonkey.ws> <4EBB919B.7040605@redhat.com> <4EBC0FC9.6030301@codemonkey.ws> In-Reply-To: <4EBC0FC9.6030301@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Lucas Meneghel Rodrigues , Kevin Wolf , KVM mailing list , "Michael S. Tsirkin" , Marcelo Tosatti , QEMU devel , Juan Jose Quintela Carreira On 11/10/2011 07:54 PM, Anthony Liguori wrote: >> IMO, this should be a release blocker. qemu 1.0 only supporting >> migration on enterprise storage? > > > No, this is not going to block the release. > > You can't dump patches on the ML during -rc for an issue that has been > understood for well over a year simply because it's release time. > > If this was so important, it should have been fixed a year ago in the > proper way. Nor can you yank support for migration this way. Might as well put a big sign on 1.0, "Do Not Use This Release". Making formal plans and sticking to them is great, but not to the point of ignoring reality. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.