[Top][All Lists]

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

Re: [Qemu-devel] [libvirt] [PULL 25/26] block: Remove deprecated -drive

From: Thomas Huth
Subject: Re: [Qemu-devel] [libvirt] [PULL 25/26] block: Remove deprecated -drive option serial
Date: Mon, 9 Jul 2018 08:58:05 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 06.07.2018 13:11, Cornelia Huck wrote:
> On Wed, 4 Jul 2018 17:14:02 +0100
> Peter Maydell <address@hidden> wrote:
>> On 4 July 2018 at 14:34, Kevin Wolf <address@hidden> wrote:
>>> Essentially, what is important to me isn't getting these options dropped
>>> exactly in 3.0, but not setting a bad precedence that deprecation isn't
>>> actually worth anything. We may easily end up with this deprecation
>>> process:
>>> depreate a feature
>>> release QEMU version n + 1
>>> release QEMU version n + 2
>>> remove the feature
>>> while libvirt hasn't removed use of the feature:
>>>     # ...and why should it when everything is still working?
>>>     reinstate the feature
>>>     release QEMU version n + x
>>>     remove the feature  
>> My take on the deprecation policy essentially is that it gives
>> us a *minimum* bar for how soon we can drop something. We
>> shouldn't be using it as an "always target this speed for
>> dropping something" -- we ought to be pragmatic. We can
>> drop stuff that's unused quickly, but should be slower
>> for things that still have major users (or reconsider
>> the deprecation entirely, potentially). There should be
>> a balance between making our work as developers easier and
>> inconveniencing our users.
> What about the following?
> - put a feature on the "normal" deprecation list to remove after two
>   releases
> Case (a): nobody complains, either within the deprecation period or
> when it is finally removed
>   -> all is good
> Case (b): the feature turns out to be widely used, and/or it turns out
> that it offers value that currently can't be offered easily in another
> way
>   -> remove from deprecation list; this obviously needs more thinking
> Case (c): the feature is used, the users are willing to move away from
> it, but they need a bit more time
>   -> put it on a "deprecation watchlist", listing the users we are
>   waiting for, and then remove after all are done (no +2)

That sounds like another indication that we should have a list of
"legacy" options in our qemu-doc, i.e. a list of interfaces that we
consider as old and unwanted, but do not intend to remove in 2 releases
yet. That idea has recently also come up already when we discussed the
"-enable-kvm" and "-no-kvm" options. The remainders "-usbdevice" is also
another good candidate for that list...


reply via email to

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