On 06/11/2018 15:26, Eduardo Habkost wrote:
> 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 <kra...@redhat.com>
>> ---
> [...]
>> +##
>> +# @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`?
Probably Maintained. It's something that is on its way towards becoming
"supported", but still too immature ("unstable or incomplete").
>> +#
>> +# @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.
I am not sure this is necessarily true. I don't see Cirrus or adlib or
pcnet disappearing anytime soon.
Paolo
>> +# 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).
>
