Re: [libvirt] [Qemu-devel] [PULL 25/26] block: Remove deprecated -drive option serial
Daniel P. Berrangé <berrange(a)redhat.com> writes:
On Mon, Jul 09, 2018 at 01:08:38PM +0200, Cornelia Huck wrote:
> On Mon, 09 Jul 2018 08:33:05 +0200
> Markus Armbruster <armbru(a)redhat.com> wrote:
>
> > Peter Maydell <peter.maydell(a)linaro.org> writes:
> >
> > > On 6 July 2018 at 15:56, Kevin Wolf <kwolf(a)redhat.com> wrote:
> > >> Am 06.07.2018 um 13:11 hat Cornelia Huck geschrieben:
> > >>> 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.
> > >
> > > Right, so clearly just "put a note in the documentation"
isn't
> > > sufficient advertisement/prodding of things going away.
> >
> > Yes. Ideas on more forceful notification have been tossed around, we
> > just have to act on them.
> >
> > > (Also, two
> > > releases is pretty fast. Many of our users will be using distro
> > > packaged versions of QEMU which will lag further behind than
> > > bleeding-edge users. The system version of QEMU on my desktop
> > > machine is 2.5...)
> >
> > If you consume QEMU in a way that's impacted by the changes the
> > deprecation policy guards, you have two sane options:
> >
> > * Track upstream deprecation, either continuously, or at least right
> > after a QEMU release. Since 2.10, they're collected in qemu-doc
> > appendix "Deprecated features".
>
> Can we draw more attention to this in any way? Point it out prominently
> in the release notes? Send a list to known consumers (e.g. libvirt) on
> release time?
Yes, we should all newly deprecated stuff in the release notes.
No-brainer.
For libvirt, I think whenever something is proposed for deprecation
we could just CC libvir-list, or ask one of the libvirt people to
confirm its not being used. If it is, then we should file BZ against
libvirt.
Makes sense, but relying on developers getting their cc: right every
time is a setting us up for failure.
Our tool to help with getting cc: wrong less often is the MAINTAINERS
file. Could one of the libvirt developers watch changes to qemu-doc
appendix "Deprecated features"? Would putting the appendix in its own
.texi help with that?