Re: [Xen-devel] [For 4.9] Updating https://wiki.xenproject.org/wiki/Xen_Project_Release_Features to reflect support status of new features

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

I wanted to bump this thread. I saw that the page still contain "Note 
that we will add complete information related to Xen Project 4.9, in the 
week after the 4.9 release.".
It looks like to me we added some features, but I am not sure if we 
added all of them.
Cheers,

On 27/06/17 09:53, Lars Kurth wrote:
> Hi all, (I think I CCed all stake-holders)
>
> to finish off the release documentation for 4.9, I need to add an extra
> column
> to https://wiki.xenproject.org/wiki/Xen_Project_Release_Features –
> because I was travelling, this dropped of my radar. There several
> decisions to be made:
> A) Decide which "features" to add
> B) Decide on the status of the feature
> C) Deal with status changes of any past features
>
> The first goal would be to decide on A and any new "features" under C.
> For B, I am OK to add "???" for now and point to this thread, until we
> have concluded the discussion
>
> Note that I tracked some of this as preparation for getting CNA status.
>  Items marked with * are not yet in the discussion document that I
> created for the security team and which we intend to discuss at the summit.
>
> For all of these, the naming convention is "Section in document" >
> "Feature" : "Support status". The definition of support status is added
> at the end of the mail: note that the text has not yet been fully
> agreed, but seems to reflect fairly well how we handled stuff in the past.
>
> == On A / B: I think we should add ==
> - Resource Management > Null Scheduler : tech preview or experimental
> - Virtual Firmware or PV Bootloader Support (not sure which) >  x86/Boot
> Xen on EFI platforms using GRUB2*  : ???
> - Hardware > ARM/Alternative Runtime Patching (ARM32 and ARM64): ???
> [note that this should probably have been added for 4.8, but I didn't
> add it]
> - Hardware > ARM/System Error Protection* : ???
> - Hardware > ARM/Wait for Virtual Interrupt* : ???
> - Hardware > x86/AVX512/Neural Network Instructions AVX512_4VNNIW* : ???
> - Hardware > x86/AVX512/Multiply Accumulation Single precision
> AVX512_4FMAPS* : ???
> - Device Models > DMOP (Device Model Operation Hypercall)  : ???
>
> New Heading:  PV Protocols and Drivers
> - PV Protocols and Drivers > pvcalls : tech preview or experimental
> - PV Protocols and Drivers > 9pfs : tech preview or experimental
> - PV Protocols and Drivers* > sndif (sound device) : tech preview or
> experimental
> - PV Protocols and Drivers* > displif (PV display) : tech preview or
> experimental
>
> Did I miss anything?
>
> == On C ==
> - Security > Live Patching -
> see 
> https://lists.xenproject.org/archives/html/xen-devel/2017-06/threads.html#03039
> - Security > Alternative 2pm : Supported – I think we should split this
> out – it is currently implicitly covered under "Virtual Machine
> Introspection"
>
> If we introduce a new heading "PV Protocols and Drivers" we should
> probably list all the common ones as supported in this heading, e.g.
> - PV Protocols and Drivers* > default (net, block, console, keyboard,
> mouse) : supported
>
> There are also USB and framebuffer, which I am not sure whether they
> should be supported and if not, what their status is
> - PV Protocols and Drivers* > USB : ???
> - PV Protocols and Drivers* > framebuffer : ???
>
> Suggestions are welcome
>
> Best Regards
> Lars
>
> ----
>
> ## Definitions
>
> ### User-facing Support Criteria
>
>  * **Functionally complete:** Does it behave like a fully functional
>    feature?  Does it work on all expected platforms, or does it only work
>    for a very specific sub-case?  Does it have a sensible UI, or do you
>    have to have a deep understanding of the internals to get it to work
>    properly?
>
>  * **Functional stability:** What is the risk of it exhibiting bugs?
>
>    General answers to the above:
>
>    - *Here be dragons*: Pretty likely to still crash / fail to work.  Not
>      recommended unless you like life on the bleeding edge.
>    - *Quirky*: Mostly works but may have odd behavior here and there.
>      Recommended for playing around or for non-production use cases.
>    - *Normal*: Ready for production use
>
> *  **Interface stability:**  If I build a system based on the current
>    interfaces, will they still work when I upgrade to the next version?
>
>    - *Not stable*: Interface is still in the early stages and still fairly
>      likely to be broken in future updates.
>    - *Provisionally stable*: We're not yet promising backwards
>      compatibility, but we think this is probably the final form of the
>      interface.  It may still require some tweaks.
>    - *Stable*: We will try very hard to avoid breaking backwards
>      compatibility, and to fix any regressions that are reported.
>
> *  **Security supported:** Will XSAs be issued if security-related bugs are
>    discovered in the functionality?
>
> ### Definition of Support Labels
>
> Rather than specify each level above, we have some short-hand labels
> that we use to denote general answer to the above questions.
>
> # Experimental
>  Functional completeness: No
>  Functional stability: Here be dragons
>  Interface stability: Not stable
>  Security supported: No
>
> # Tech Preview
>  Functional completeness: Yes
>  Functional stability: Quirky
>  Interface stability: Provisionally stable
>  Security supported: No.
>
> # Supported
>  Functional completeness: Yes
>  Functional stability: Normal
>  Interface stability: Yes
>  Security supported: Yes
>
> # Deprecated
>  Functional completeness: Yes
>  Functional stability: Quirky
>  Interface stability: No (as in, may disappear the next release)
>  Security supported: Yes
--
Julien Grall

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