From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Wolf Subject: Re: [Qemu-devel] KVM call for 2017-03-14 Date: Tue, 14 Mar 2017 11:13:51 +0100 Message-ID: <20170314101351.GC3952@noname.str.redhat.com> References: <87tw6y8bs8.fsf@secure.mitica> <6559d50e-b8d5-eaa2-4a14-48608644ad29@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Peter Maydell , Juan Quintela , QEMU Developer , KVM devel mailing list To: Thomas Huth Return-path: Received: from mx1.redhat.com ([209.132.183.28]:33012 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750749AbdCNKNy (ORCPT ); Tue, 14 Mar 2017 06:13:54 -0400 Content-Disposition: inline In-Reply-To: <6559d50e-b8d5-eaa2-4a14-48608644ad29@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Am 14.03.2017 um 10:24 hat Thomas Huth geschrieben: > > - in all areas our legacy code and back-compatibility requirements > > are threatening to choke forward progress if we don't make serious > > efforts to get on top of them > > ... and don't forget all the code that is in "orphan" state since many > years... it's often hard to get patches accepted that primarily touches > files that nobody feels responsible for... > > Maybe it's really time for a "spring-cleaning", break with some > compatibility cruft and do a 3.0 release afterwards ;-) If we decide that the situation is bad enough to do this, I'd vote for breaking not just "some" compatibility for a usual release after three months, but to take more time for it, completely break with the old interfaces and declare this a new QEMU that libvirt should have a separate driver for. And then throw out _all_ of the interfaces that don't match the design any more that we have in mind, even if this means a temporary regression in features. This means one big cut rather than having every release just slightly incompatible with the previous releases, which should actually make it more managable, even though the change is more radical. Kevin