qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 1/4] add QemuSupportState
Date: Tue, 30 Oct 2018 18:37:42 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

On 30/10/18 16:46, Cornelia Huck wrote:
On Tue, 30 Oct 2018 15:13:45 +0100
Philippe Mathieu-Daudé <address@hidden> 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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]