Re: [Xen-devel] Clarifying the state of ARINC653 scheduler (and other components) in Xen 4.5 and beyond

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

> On 10 Jun 2015, at 10:51, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> 
> On 10/06/15 10:42, Lars Kurth wrote:
>> Alright,
>> if nobody is willing to come up with a definition of 
>> experimental/preview/supported/deprecated, I will based on what I have seen
>> Lars
> 
> I was planning to start a document to this effect to live in
> docs/features/, given the success of the command line document.

This would work

> 
> My plan was that we would slowly gain a doc per feature giving a brief
> overflow, support status, further todo for experimental features, etc
> which comes with an audit trail of when it moved between supported states.

I thought about this and talked to a few people and can put together a starting 
point with regards to state definitions. 
A document living in the source tree is good enough for me

I also think it might be a good idea to create some sort of lighweight 
lifecycle model that provides recommendations when a feature would move from 
one state to the next, etc. - I like the idea of using a file in the source 
tree to get an audit trail. It would also possibly make the life of the release 
manager easier: committed features would end up with a record in that file. 

We could also consider making recommendations along the lines of "if a feature 
has been in experimental for X (let's say 2 to set an example) release cycle's, 
we should have a discussion before the release (or at the beginning of a 
release cycle) to see whether anyone is willing to step up and improve it and 
what would need to be done. Or whether there is a good reason for the feature 
staying in that state. Otherwise we may deprecate it."

I think over time, we have built up far too many features that never were 
completed and are in some sort of half finished state. The threat of weeding 
out unfinished stuff may
a) lead to companies who initially implemented to step up
b) avoid security issues / usability issues by avoiding cruft

Regards
Lars



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