Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState

[Eduardo Habkost <ehabkost@redhat.com>]

On Tue, Oct 30, 2018 at 06:37:42PM +0100, Philippe Mathieu-Daudé wrote:
> On 30/10/18 16:46, Cornelia Huck wrote:
> > On Tue, 30 Oct 2018 15:13:45 +0100
> > Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
> > 
> > > On 30/10/18 15:00, Gerd Hoffmann wrote:
> > > > On Tue, Oct 30, 2018 at 02:32:40PM +0100, Philippe Mathieu-Daudé wrote:
> > > > > > +##
> > > > > > +# @SupportState:
> > > > > > +#
> > > > > > +# Indicate Support level of qemu devices, backends, subsystems, ...
> > > > > > +#
> > > > > > +# Since: 3.2
> > > > > > +##
> > > > > > +{ 'enum': 'SupportState',
> > > > > > +  'data': [ 'unknown',
> > > > > 
> > > > > 'unknown' is scary and should be fixed.
> > > > 
> > > > 'unknown' maps to "0" due to being first in list, so this is what you
> > > > get when it isn't explicitly set to something else.  Which make sense
> > > > IMHO.
> > > 
> > > Yes, I understand in your next patch, this case won't display warning to
> > > the user.
> > > 
> > > I wanted to say "we should fix those entries in the MAINTAINERS file".
> > 
> > I think that has been an ongoing quest for years :)
> > 
> > > 
> > > > > > +            'supported',
> > > > > > +            'maintained',
> > > > > > +            'odd-fixes',
> > > > > 
> > > > > All those fit in 'supported'
> > > > > > +            'orphan',
> > > > > > +            'obsolete',
> > > > > > +            'deprecated' ] }
> > > > > 
> > > > > And all those should appear as 'deprecated' IMHO.
> > > > 
> > > > See minutes on deprecation discussion.  Seems there is agreement we
> > > > need something more finegrained than "supported" and "deprecated".
> > > 
> > > I read again the "Minutes of KVM Forum BoF on deprecating stuff" thread
> > > and don't find details on finegrains, can you point it to me?
> > > 
> > > I think these are fine in the MAINTAINERS entries, but don't give useful
> > > information to a QEMU user that is not custom to MAINTAINERS.
> > 
> > We might squash 'supported' and 'maintained' together (as their only
> > real difference is whether someone gets paid for it), but 'odd fixes'
> > is different IMO (you have someone to talk to, but they don't dedicate
> > much of their time to it.)
> > 
> > > 
> > > As a user I'd expect anything not "supported" to be eventually "deprecated".
> > 
> > But there are differences:
> > - 'orphan' - nobody is looking after it; should become 'deprecated' if
> >    nobody steps up, but may move to one of the 'someone looks after it'
> >    states
> > - 'obsolete' - don't use this; should move to 'deprecated' once a
> >    replacement is ready (or it is not needed anymore)
> > - 'deprecated' - on the removal schedule; has not necessarily been in
> >    'orphan' or 'obsolete' before
> 
> OK!
> 
> If I understand correctly, we have this 'state machine':
> 
>    Supported            Unsupported          Deprecated
> 
> (someone to talk)     (nobody to talk)  (scheduled for removal)
> +--------------+       +------------+      +--------------+
> | S:Maintained |       | S:Unknown  |      |              |
> |              |       |            |      |              |
> | S:Supported  + <---> | S:Orphan   +----> | S:Deprecated +----> Removed
> |              |       |            |      |              |
> | S:Odd Fixes  |       | S:Obsolete |      |              |
> +------+-------+       +------------+      +--------------+
>        |                                           ^
>        |                                           |
>        +-------------------------------------------+
> 
> So we have 3 distinct states.
> 
> Note:
> - Maintainers can deprecate stuffs
> - Orphan code can become Supported
> - Once scheduled for removal, there is no way back
> - 'Unknown' seems pretty similar to 'Orphan'.

I'm still worried that the supported/unsupported distinction may
cause unnecessary hassle for every downstream distributor of
QEMU.  Do we really have a need to differentiate supported vs
unsupported device types at runtime?

I'd prefer to make support/unsupported differentiation to be a
build system feature (e.g. a CONFIG_UNSUPPORTED build-time
option) instead of a QMP/runtime feature.

-- 
Eduardo