From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:58901)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1QoxTd-0006a8-3c
	for qemu-devel@nongnu.org; Thu, 04 Aug 2011 08:56:41 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1QoxTc-0005Tl-49
	for qemu-devel@nongnu.org; Thu, 04 Aug 2011 08:56:41 -0400
Received: from mx1.redhat.com ([209.132.183.28]:21964)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1QoxTb-0005Th-S4
	for qemu-devel@nongnu.org; Thu, 04 Aug 2011 08:56:40 -0400
Message-ID: <4E3A97B5.6000002@redhat.com>
Date: Thu, 04 Aug 2011 14:59:33 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <1312326516-10117-1-git-send-email-aliguori@us.ibm.com>
	<m3ty9zjt09.fsf@neno.neno> <4E389258.6040007@us.ibm.com>
	<m3sjpidg4h.fsf@neno.neno> <4E398A44.8060507@codemonkey.ws>
	<m3bow6cgtr.fsf@neno.neno>
In-Reply-To: <m3bow6cgtr.fsf@neno.neno>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] migration: remove subsections in fdc and
 rtl8139 and bump versions
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: quintela@redhat.com
Cc: Paolo Bonzini <pbonzini@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org

Am 03.08.2011 23:42, schrieb Juan Quintela:
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>> On 08/03/2011 04:00 AM, Juan Quintela wrote:
> 
>> I don't have a problem with Paolo's new protocol.  In fact, I'm strong
>> in favor of applying it to master.  But I don't like the idea of
>> adding a new migration protocol with no testing in master before
>> putting it in a release.
> 
> I have.  If we are changing a protocol in an incompatible version, we
> can remove a lot of warts that current descriptions have.  Not that
> Paolo protocol is bad, but if we are going to do some change, adding
> things like size, removing previous warts, etc is the way to go.

So how about stating clearly that migrating between 0.x and 1.x won't
work and using the next few months to develop a sane migration protocol?

We'll still have to do something about 0.15 and it's not very nice to
break migration twice, but seems there is no way around it.

Kevin