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

On 06.07.2018 13:11, Cornelia Huck wrote: > On Wed, 4 Jul 2018 17:14:02 +0100 > Peter Maydell <peter.maydell(a)linaro.org&gt; wrote: > >> On 4 July 2018 at 14:34, Kevin Wolf <kwolf(a)redhat.com&gt; 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...