On Mon, 9 Jul 2018 08:58:05 +0200 Thomas Huth <thuth@redhat.com> wrote:
On 06.07.2018 13:11, Cornelia Huck wrote:
On Wed, 4 Jul 2018 17:14:02 +0100 Peter Maydell <peter.maydell@linaro.org> wrote:
On 4 July 2018 at 14:34, Kevin Wolf <kwolf@redhat.com> 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...
Agree. It also might be a good idea to poke e.g. libvirt about those. Related: Are there other widely-used management etc. programs that make use of QEMU? (For some value of 'widely'.) We might consider poking them as well.