[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Clarifying the state of ARINC653 scheduler (and other components) in Xen 4.5 and beyond
> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |