qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [libvirt] [PULL 25/26] block: Remove depre


From: Markus Armbruster
Subject: Re: [Qemu-block] [Qemu-devel] [libvirt] [PULL 25/26] block: Remove deprecated -drive option serial
Date: Thu, 12 Jul 2018 08:32:45 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Daniel P. Berrangé <address@hidden> 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 <address@hidden> wrote:
>> 
>> > Peter Maydell <address@hidden> writes:
>> > 
>> > > On 6 July 2018 at 15:56, Kevin Wolf <address@hidden> 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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]