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

[Cornelia Huck]

On Wed, 4 Jul 2018 17:14:02 +0100
Peter Maydell <peter.maydell at linaro.org> wrote:

> On 4 July 2018 at 14:34, Kevin Wolf <kwolf at 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 way, we can still easily remove old cruft (case (a)), but still
accommodate cases like this (case (c)). The obvious drawback is that
we'd need someone to curate the deprecation watchlist, to poke the
users we're waiting for, and probably remove anyway after some time if
they don't get their act together.

> 
> In this particular case, reverting this deletion seems like
> a fairly easy call to me.
> 
> We should also definitely work on improving how we can
> let management-layer developers easily test that they're
> not accidentally relying on deprecated features, certainly
> (and also on better documentation for command line users
> of how to switch away from deprecated features -- for
> instance I am still using -redir in some of my scripts
> because the warning about it being deprecated is not
> precise about what exact command line option can be used
> instead, especially for the case where the ethernet device
> is builtin rather than created with -device...)

Yes, this as well.