Re: [Xen-devel] Security support scope (apropos of Xen and CNA)

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

> On 8 May 2017, at 17:11, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> 
> On 08/05/17 17:04, Ian Jackson wrote:
>> Tim Deegan writes ("Re: Security support scope (apropos of Xen and CNA)"):
>>> Ah, so it is.  So there is information on the wiki page that's not in
>>> MAINTAINERS.  Could that be moved into MAINTAINERS?  There are
>>> a few things that don't map well to maintainership of specific
>>> files, e.g. "vMCE" or nested virtualization.  But on the whole I
>>> think that adding clauses for them would be OK.
>> I think this is quite awkward, really.  MAINTAINERS is about files,
>> and implementations.  The security support status is about parts of
>> interfaces, which don't map at all well.
>> 
>> We could add no-files stanzas, but how would you tell what they
>> referred to ?
> 
> This is the principle behind introducing docs/features/* which, as part
> of the required metadata, contains a support statement.
> 
> This way, there is an authoritative statement of support on a
> per-feature basis which is easy to keep up to date.
> 
> Lars: Any update on your project level clarifications of support statuses?

No, there is no vendor agreement yet on the testing side (aka what testing they 
commit to and what would happen if 3rd party testing outside of OSSTEST does 
not take place). That and what to do with "security supported" components which 
have poor testing for historical reasons are the only outstanding issue. These 
are really big issues, where there is no real consensus. I will get a Design 
Session in place for this at the summit: maybe we can make some progress.

However, IMHO, we can start off agreeing a format: in nutshell what we need is 
a list that shows feature=status - although we may want to add a few more 
fields, aka feature=(support status=..., maintainer status=<as per maintainers 
file>, tested=OSSTEST|XTF|3rd Party|..., ...). Someone needs to make a sensible 
proposal.

For example, we could just map "status" on what we have now: preview, 
experimental, supported (which includes security support) and extend/change the 
meaning of the status field as this gets resolved. I don't think the two things 
are strongly linked.

Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel