Re: [Xen-devel] [RFC PATCH] Feature doc: Added Feature Maturity Lifecycle

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

> On 11 Nov 2015, at 19:38, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> 
> On 06/11/15 17:35, Lars Kurth wrote:
>> +# State Definitions
>> +
>> +This section lists state definitions of a **Feature** in terms of
>> +properties. This section talks about Features, for readability, but
>> +is used interchangeably between **Features** and **Platforms**.
>> +
>> +States are listed in order of increasing number
>> +of properties. Note that note all features will require to go
>> +through each state: for example small and non-risky features
>> +may go straight from under development to supported. It is up to
>> +the development community to judge and discuss, which states
>> +are necessary based on the size and risk of a feature.
>> +
>> +## Preview
>> +* Partially completed, with missing functionality
>> +* May **not be fully functional** in all cases
>> +* May **not be tested**
>> +* APIs and interfaces may **not be stable**
> 
> "are not stable".
> 
> i.e. maintainers reserve the right to insist that the interfaces are
> changed.

OK. That makes sense

> 
> For preview and experimental features, it is quite possible that hidden
> design considerations become visible after the initial code is committed.
> 
> As a result, it is important that nothing is set in stone while the
> feature itself is still in development.

Agreed. 


>> +* The developer is actively looking for user feedback
>> +* Bugs and issues can be raised on xen-devel@ and will be
>> +  handled on a best-effort basis
> 
> Probably best to explicitly state that there is no security support for
> Preview/Experimental features.  By their classification, they are not
> ready for production use.

Agreed.

>> +
>> +## Experimental
>> +* Core functionality is **fully functional**
>> +* However, not all functionality or platform support may be
>> +  present
>> +* May **not be tested**, although there is an expectation that a plan
>> +  to improve testing is in place or worked on
>> +* APIs and interfaces may **not be stable**
>> +* Bugs and issues can be raised on xen-devel@ and will be
>> +  handled on a best-effort basis. However, there is an expectation
>> +  that issues related to broken core functionality are addressed.
> 
> I am not completely convinced by splitting Preview and Experiential. 
> The difference between the two is quite subjective.
> 
> I would hope that the exact state of the feature in the range Nothing ->
> Supported is easy to derive from the Limitations, Improvements and Known
> Issues sections of its feature document.

Alright. That makes sense and is also mirrored somewhat by the Advisory Board 
feedback (see my last mail to Wei).
What is your view on the usefulness of keeping Preview and Experimental 
separate? It sounds to me that we should fold these into one category and let 
Limitations, Improvements and Known Issues speak for themselves.

Lars 


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