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

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)