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

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

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

> 
>>
>> Should we continue this discussion on the "Minutes of KVM Forum BoF on
>> deprecating stuff" thread?
>>
>> Thanks,
>>
>> Phil.
>>
>>>
>>> cheers,
>>>     Gerd
>>>
>>>    
>>
>