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 8 Jun 2015, at 13:19, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 
> On Mon, 2015-06-08 at 13:00 +0100, Jan Beulich wrote:
>>>>> On 08.06.15 at 12:43, <lars.kurth.xen@xxxxxxxxx> wrote:
>>> b) Do we actually have or should have a definition of 
>>> experimental/preview/supported/deprecated.  I don't think this was ever 
>>> written down and was defined before I joined. Also, there are no real 
>>> conventions related to changing the state.
>>> 
>>> c) How does b) map to the definitions in 
>>> http://xenbits.xenproject.org/gitweb/?p=xen.git;a=blob;f=MAINTAINERS;hb=HEAD
>>>  
>>> <http://xenbits.xenproject.org/gitweb/?p=xen.git;a=blob;f=MAINTAINERS;hb=HEAD>
>>>  
>> 
>> Perhaps we should simply add Experimental and Preview states to
>> ./MAINTAINERS' S: specifier?
> 
> In MAINTAINERS S: Supported means:
> 
> "Someone is actually paid to look after this.", which I think is
> distinct from "This works well enough that the project is happy to
> recommend it is used in production". It's a shame that Supported can be
> taken to mean both things.
> 
> Perhaps we should drop the distinction between Supported and Maintained
> in MAINTAINERS and call everything which is "Supported" there into
> "Maintained" instead.
> 
> For reference Maintained is "Someone actually looks after it.".
> 
> Alternatively if someone can think of another way to express "paid
> maintainer" we could switch to that.

That would clearly answer c - aka there is no connection. Note that 
http://wiki.xenproject.org/wiki/Xen_Project_Schedulers is not the official list 
of what is supported, and for this reason I probably didn't bother and read the 
definitions in the Maintainers file. 

Of course this could also be solved by having a definition for the 
experimental/preview/supported/deprecated states. For example, a link could be 
that a component/feature needs to be maintained to be in "supported" state. And 
we should have some convention somewhere which says how state changes are made: 
aka this could be as simple as making a proposal to the list. I could come up 
with some definitions, but I would assume that we would be closer to the final 
state if the initial definition (a list of bullet points is enough) came from 
developers who have bene involved in the project for some time.

And then there is of course the question what we do with ARINC653. 

Regards
Lars



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