From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: [Qemu-devel] KVM call for 2017-03-14 Date: Tue, 14 Mar 2017 13:20:26 +0100 Message-ID: <87y3w89hit.fsf@dusky.pond.sub.org> References: <87tw6y8bs8.fsf@secure.mitica> <6559d50e-b8d5-eaa2-4a14-48608644ad29@redhat.com> <20170314101351.GC3952@noname.str.redhat.com> Mime-Version: 1.0 Content-Type: text/plain Cc: Thomas Huth , Peter Maydell , QEMU Developer , KVM devel mailing list , Juan Quintela To: Kevin Wolf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:33720 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751113AbdCNMUk (ORCPT ); Tue, 14 Mar 2017 08:20:40 -0400 In-Reply-To: <20170314101351.GC3952@noname.str.redhat.com> (Kevin Wolf's message of "Tue, 14 Mar 2017 11:13:51 +0100") Sender: kvm-owner@vger.kernel.org List-ID: Kevin Wolf writes: > 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. Of course, "legacy code and back-compatibility requirements" will start to grow back the minute we release new interfaces. Whether a big cut is worthwhile depends on the seriousness of the current situation and the rate of regrowth. There's hope the weeds will grow more slowly around well-designed new interfaces.