qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] KVM call for 2017-03-14


From: Markus Armbruster
Subject: Re: [Qemu-devel] KVM call for 2017-03-14
Date: Tue, 14 Mar 2017 13:20:26 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Kevin Wolf <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]