Re: Should we mark RTDS as supported feature from experimental feature?

[Andrew Cooper <andrew.cooper3@citrix.com>]

>> However, inside MAINTAINERS file, the status of RTDS scheduler is
>> marked as Supported (refer to commit point 28041371 by Dario Faggioli
>> on 2015-06-25).
>>
> There's indeed a discrepancy between the way one can read that bit of
> MAINTAINERS, and what is generally considered Supported (e.g., subject
> to security support, etc).
>
> This is true in general, not only for RTDS (more about this below).

The purpose of starting the feature docs (in docs/features/) was to
identify the technical status of a feature, along side some
documentation pertinent to its use.

I am tempted to suggest a requirement of "no security support without a
feature doc" for new features, in an effort to resolve the current
uncertainty as to what is supported and what is not.

As for the MAINTAINERS file, supported has a different meaning.  From
the file itself,

Descriptions of section entries:

M: Mail patches to: FullName <address@domain>
L: Mailing list that is relevant to this area
W: Web-page with status/info
T: SCM tree type and location.  Type is one of: git, hg, quilt, stgit.
S: Status, one of the following:
           Supported:   Someone is actually paid to look after this.
           Maintained:  Someone actually looks after it.
           Odd Fixes:   It has a maintainer but they don't have time to do
            much other than throw the odd patch in. See below..
           Orphan:      No current maintainer [but maybe you could take the
                    role as you write your new code].
           Obsolete:    Old code. Something tagged obsolete generally means
            it has been replaced by a better system and you
                        should be using that.

Nothing in the MAINTAINERS file constitutes a security statement.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel