Re: [Qemu-ppc] [PATCH v2 2/6] add QemuSupportState

[Eduardo Habkost]

On Tue, Nov 06, 2018 at 11:23:31AM +0100, Gerd Hoffmann wrote:
> Indicates support state for something (device, backend, subsystem, ...)
> in qemu.  Add QemuSupportState field to ObjectClass.  Add some support
> code.
> 
> TODO: wire up to qom-list-types
> 
> Signed-off-by: Gerd Hoffmann <address@hidden>
> ---
[...]
> +##
> +# @SupportState:
> +#
> +# Indicate Support level of qemu devices, backends, subsystems, ...
> +#
> +# @unspecified: not specified (zero-initialized).
> +#
> +# @experimental: in development, can be unstable or incomplete.

People reading this document would ask: what would appear on
MAINTAINERS if SupportState is `experimental`?

> +#
> +# @supported: works stable and is fully supported.
> +#             (supported + maintained in MAINTAINERS).
> +#
> +# @unsupported: should work, support is weak or not present.
> +#               (odd-fixes + orphan in MAINTAINERS).

What's the difference in practice between unsupported and
experimental?

> +#
> +# @obsolete: is obsolete, still present for compatibility reasons,
> +#            will likely be removed at some point in the future.
> +#            Not deprecated (yet).
> +#            (obsolete in MAINTAINERS).
> +#
> +# @deprecated: is deprecated, according to qemu deprecation policy.

I believe we want to differentiate "deprecated, but still safe to
use in production if you have a migration plan" from "deprecated,
and also unstable and unsafe for production".

I expect enterprise distributions to have a strict policy of not
allowing unsupported and experimental devices to be enabled, but
still allow deprecated devices to be enabled (but only if they
are stable/supported).

-- 
Eduardo