Clarifying the state of ARINC653 scheduler (and other components) in Xen 4.5 and beyond

Clarifying the state of ARINC653 scheduler (and other components) in Xen 4.5 and beyond

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 1646 bytes --]

Hi,
I wanted to point out that there is some discrepancy on the supported state of the ARINC653 scheduler
* http://wiki.xenproject.org/wiki/Xen_Project_Release_Features <http://wiki.xenproject.org/wiki/Xen_Project_Release_Features> not listed at all
* http://wiki.xenproject.org/wiki/Xen_Project_Schedulers#5._ARINC_653_.28Xen_4.0.29 <http://wiki.xenproject.org/wiki/Xen_Project_Schedulers#5._ARINC_653_.28Xen_4.0.29> says it's supported 
Note that I create the page in the run-up to the 4.5 release copying information from 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> 

It seems that I tripped over the different definitions of supported in the maintainers file and in Release Features. 
\
I guess this raises a few questions:

a) What feature status should the ARINC653 scheduler be in (and what was its history related to states ) - we should add it to http://wiki.xenproject.org/wiki/Xen_Project_Release_Features <http://wiki.xenproject.org/wiki/Xen_Project_Release_Features>

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> 

And then there are probably other areas where we may have similar mismatches

Best Regards
Lars

[-- Attachment #1.2: Type: text/html, Size: 2469 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Jan Beulich]

>>> On 08.06.15 at 12:43, <lars.kurth.xen@gmail.com> 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?

> And then there are probably other areas where we may have similar mismatches

Like x86 memory paging/sharing, where I'm sure the wiki page is
what correctly reflects their states.

Jan

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

[Ian Campbell]

On Mon, 2015-06-08 at 13:00 +0100, Jan Beulich wrote:
> >>> On 08.06.15 at 12:43, <lars.kurth.xen@gmail.com> 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.


> 
> > And then there are probably other areas where we may have similar mismatches
> 
> Like x86 memory paging/sharing, where I'm sure the wiki page is
> what correctly reflects their states.
> 
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

[Lars Kurth]

> On 8 Jun 2015, at 13:19, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> On Mon, 2015-06-08 at 13:00 +0100, Jan Beulich wrote:
>>>>> On 08.06.15 at 12:43, <lars.kurth.xen@gmail.com> 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

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

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 2132 bytes --]

On Mon, 2015-06-08 at 14:01 +0100, Lars Kurth wrote:
> > On 8 Jun 2015, at 13:19, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > 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.
> > 
> > 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.
>
> And then there is of course the question what we do with ARINC653. 
> 
Not sure we actually need to do something. The status in MAINTAINERS is
consistent with the existing semantic, as there's actually people
actively looking after the scheduler (and paid to do so, AFAIK).

Wrt the wiki page, the best way of capturing the state of things is,
basing on what's in there for the other schedulers, 'Supported' there
too. The scheduler has a very limited scope, and is useful only in a
handful of situations, and that's by design. But for those situations it
works pretty well, AFAIK.

Moreover, there is people in the community providing help to interested
users on how to set it up (there has been a thread on xen-users about
this rather recently).

Whether we should recommend to use it in production, well, I think we
could, of course for those people and only for them having a requirement
for compliance with the ARINC653 standard, which certainly is not the
most common thing around.

Whether it's actually being used in production by anyone, I don't
know... although they may not be allowed to say much/everything, maybe
Robbie and Josh could comment on this... but is this that relevant?

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Jan Beulich]

>>> On 08.06.15 at 22:59, <dario.faggioli@citrix.com> wrote:
> On Mon, 2015-06-08 at 14:01 +0100, Lars Kurth wrote:
>> > On 8 Jun 2015, at 13:19, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > 
>> > 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.
>> > 
>> > 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.
>>
>> And then there is of course the question what we do with ARINC653. 
>> 
> Not sure we actually need to do something. The status in MAINTAINERS is
> consistent with the existing semantic, as there's actually people
> actively looking after the scheduler (and paid to do so, AFAIK).
> 
> Wrt the wiki page, the best way of capturing the state of things is,
> basing on what's in there for the other schedulers, 'Supported' there
> too. The scheduler has a very limited scope, and is useful only in a
> handful of situations, and that's by design. But for those situations it
> works pretty well, AFAIK.
> 
> Moreover, there is people in the community providing help to interested
> users on how to set it up (there has been a thread on xen-users about
> this rather recently).
> 
> Whether we should recommend to use it in production, well, I think we
> could, of course for those people and only for them having a requirement
> for compliance with the ARINC653 standard, which certainly is not the
> most common thing around.

But you understand that one primary aspect of whether something
is to be considered supported is whether that code, if found to be
flawed, may end up triggering security advisories? I.e. apart from
people looking after it and people using it (or showing interest to do
so) we also need to be convinced that the code quality is good
enough. The situation of tmem (also marked Supported in
./MAINTAINERS) is the prime example of when that's not
(recognizably) the case. And the bug report (that luckily didn't need
to result in an XSA for other reasons) leading to
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01018.html
shows that the code may not have got audited from a security
perspective.

Jan

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

[Lars Kurth]

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

> On 9 Jun 2015, at 10:53, Jan Beulich <jbeulich@suse.com> wrote:
> 
>>>> On 08.06.15 at 22:59, <dario.faggioli@citrix.com> wrote:
>> On Mon, 2015-06-08 at 14:01 +0100, Lars Kurth wrote:
>>>> On 8 Jun 2015, at 13:19, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>> 
>>> And then there is of course the question what we do with ARINC653. 
>>> 
>> Not sure we actually need to do something. The status in MAINTAINERS is
>> consistent with the existing semantic, as there's actually people
>> actively looking after the scheduler (and paid to do so, AFAIK).
>> 
>> Wrt the wiki page, the best way of capturing the state of things is,
>> basing on what's in there for the other schedulers, 'Supported' there
>> too. The scheduler has a very limited scope, and is useful only in a
>> handful of situations, and that's by design. But for those situations it
>> works pretty well, AFAIK.
>> 
>> Moreover, there is people in the community providing help to interested
>> users on how to set it up (there has been a thread on xen-users about
>> this rather recently).
>> 
>> Whether we should recommend to use it in production, well, I think we
>> could, of course for those people and only for them having a requirement
>> for compliance with the ARINC653 standard, which certainly is not the
>> most common thing around.
> 
> But you understand that one primary aspect of whether something
> is to be considered supported is whether that code, if found to be
> flawed, may end up triggering security advisories? I.e. apart from
> people looking after it and people using it (or showing interest to do
> so) we also need to be convinced that the code quality is good
> enough. The situation of tmem (also marked Supported in
> ./MAINTAINERS) is the prime example of when that's not
> (recognizably) the case. And the bug report (that luckily didn't need
> to result in an XSA for other reasons) leading to
> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01018.html
> shows that the code may not have got audited from a security
> perspective.
> 
> Jan

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

[Jan Beulich]

>>> On 10.06.15 at 11:42, <lars.kurth.xen@gmail.com> wrote:
> if nobody is willing to come up with a definition of 
> experimental/preview/supported/deprecated, I will based on what I have seen

I didn't think we severely disagreed on these states' meanings; my
understanding was more that we need to clarify that ./MAINTAINERS
saying supported doesn't mean supported in the wiki features page's
sense.

Jan

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

[Andrew Cooper]

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.

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.

Of course, this was going to happen in some copus free time intersecting
with a docs day, which hasn't occurred yet :(

~Andrew

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

[Lars Kurth]

> On 10 Jun 2015, at 10:51, Andrew Cooper <andrew.cooper3@citrix.com> 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

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

[Lars Kurth]

> On 10 Jun 2015, at 10:51, Andrew Cooper <andrew.cooper3@citrix.com> 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.
> 
> 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.

Hi all, I made a proposal via http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01992.html
Lars