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

[Peter Krempa]

On Fri, Jul 06, 2018 at 16:56:46 +0200, Kevin Wolf wrote:
> Am 06.07.2018 um 13:11 hat Cornelia Huck geschrieben:
> > 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 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.
> 
> The problem is that things are only starting to move after two releases
> have passed. The original idea was to already use that time. If we don't
> use it, then waiting for two releases is pointless and we can just
> directly let things go to a deprecation watchlist.
> 
> Maybe we can just use the existing wiki page:
> 
>     https://wiki.qemu.org/index.php/Features/LegacyRemoval
> 
> And add a column for whether libvirt is ready? Of course, that only
> makes sense if libvirt people make use of and contribute to this page.

This should not be a problem, but I think we need some active
encouraging/prodding to remove deprecated stuff. Otherwise we might miss
the news.

signature.asc
Description: PGP signature