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

[Cornelia Huck <cohuck@redhat.com>]

On Tue, 30 Oct 2018 20:15:45 -0300
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Tue, Oct 30, 2018 at 06:37:42PM +0100, Philippe Mathieu-Daudé wrote:
> > 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 |      |              |
> > +------+-------+       +------------+      +--------------+
> >        |                                           ^
> >        |                                           |
> >        +-------------------------------------------+

I believe we can also take things out of the deprecated state again,
but I would expect that to be a very rare event.

'Obsolete' is probably 'unsupported' in the 'do not use that' sense,
but there still might be someone to talk to.

Similarly, 'unknown' devices etc. may have someone we can talk to, it's
just the problem of finding out who that is and getting them to move it
into the 'supported' state :)

> > 
> > So we have 3 distinct states.
> > 
> > Note:
> > - Maintainers can deprecate stuffs

It's not only maintainers that can do that, but it has to get their
ack, of course.

> > - Orphan code can become Supported
> > - Once scheduled for removal, there is no way back

We should not block the way back, or else we cannot adapt to things we
did not know when we first deprecated it.

> > - 'Unknown' seems pretty similar to 'Orphan'.  

Not quite. If something is 'orphan', it was explicitly moved to that
state when a maintainer gave it up. 'Unknown' may also be stuff that
simply fell through the cracks.

> 
> 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.

I think that makes sense -- we really want to single out
devices/machines that are deprecated and will go away unless
something magic happens.