From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars Kurth Subject: Clarifying the state of ARINC653 scheduler (and other components) in Xen 4.5 and beyond Date: Mon, 8 Jun 2015 11:43:02 +0100 Message-ID: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/mixed; boundary="===============6648019498790554602==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "" Cc: Wei Liu , Joshua Whitehead , Robert VanVossen List-Id: xen-devel@lists.xenproject.org --===============6648019498790554602== Content-Type: multipart/alternative; boundary="Apple-Mail=_BFF82193-DE41-482B-8DE7-FABE289455C3" --Apple-Mail=_BFF82193-DE41-482B-8DE7-FABE289455C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 = not = listed at all * = http://wiki.xenproject.org/wiki/Xen_Project_Schedulers#5._ARINC_653_.28Xen= _4.0.29 = says it's supported=20 Note that I create the page in the run-up to the 4.5 release copying = information from = http://xenbits.xenproject.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3DMAINTAINERS= ;hb=3DHEAD = =20 It seems that I tripped over the different definitions of supported in = the maintainers file and in Release Features.=20 \ 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 = 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=3Dxen.git;a=3Dblob;f=3DMAINTAINERS= ;hb=3DHEAD = =20 And then there are probably other areas where we may have similar = mismatches Best Regards Lars= --Apple-Mail=_BFF82193-DE41-482B-8DE7-FABE289455C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

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 not listed at all

* 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=3Dxen.git;a=3Dblob;f=3D= MAINTAINERS;hb=3DHEAD

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

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=3Dxen.git;a=3Dblob;f=3D= MAINTAINERS;hb=3DHEAD

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

Best = Regards

Lars

= --Apple-Mail=_BFF82193-DE41-482B-8DE7-FABE289455C3-- --===============6648019498790554602== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6648019498790554602==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Clarifying the state of ARINC653 scheduler (and other components) in Xen 4.5 and beyond Date: Mon, 08 Jun 2015 13:00:23 +0100 Message-ID: <55759FF802000078000820F3@mail.emea.novell.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Lars Kurth Cc: Joshua Whitehead , Wei Liu , Robert VanVossen , "" List-Id: xen-devel@lists.xenproject.org >>> On 08.06.15 at 12:43, 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 > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Clarifying the state of ARINC653 scheduler (and other components) in Xen 4.5 and beyond Date: Mon, 8 Jun 2015 13:19:08 +0100 Message-ID: <1433765948.7108.484.camel@citrix.com> References: <55759FF802000078000820F3@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55759FF802000078000820F3@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Lars Kurth , Wei Liu , Joshua Whitehead , Robert VanVossen , "" List-Id: xen-devel@lists.xenproject.org On Mon, 2015-06-08 at 13:00 +0100, Jan Beulich wrote: > >>> On 08.06.15 at 12:43, 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 > > > > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars Kurth Subject: Re: Clarifying the state of ARINC653 scheduler (and other components) in Xen 4.5 and beyond Date: Mon, 8 Jun 2015 14:01:21 +0100 Message-ID: <3FDAE9EB-2D4C-41E2-83D9-B8A21609A267@gmail.com> References: <55759FF802000078000820F3@mail.emea.novell.com> <1433765948.7108.484.camel@citrix.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1433765948.7108.484.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Wei Liu , Joshua Whitehead , Robert VanVossen , Jan Beulich , "" List-Id: xen-devel@lists.xenproject.org > On 8 Jun 2015, at 13:19, Ian Campbell wrote: > > On Mon, 2015-06-08 at 13:00 +0100, Jan Beulich wrote: >>>>> On 08.06.15 at 12:43, 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 >>> >> >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Clarifying the state of ARINC653 scheduler (and other components) in Xen 4.5 and beyond Date: Mon, 8 Jun 2015 22:59:54 +0200 Message-ID: <1433797194.2388.23.camel@citrix.com> References: <55759FF802000078000820F3@mail.emea.novell.com> <1433765948.7108.484.camel@citrix.com> <3FDAE9EB-2D4C-41E2-83D9-B8A21609A267@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5294014656655638120==" Return-path: In-Reply-To: <3FDAE9EB-2D4C-41E2-83D9-B8A21609A267@gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Lars Kurth Cc: Wei Liu , Ian Campbell , Robert VanVossen , "" , Joshua Whitehead , Jan Beulich List-Id: xen-devel@lists.xenproject.org --===============5294014656655638120== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-sL3+F/c1I2kB0EUO1cfy" --=-sL3+F/c1I2kB0EUO1cfy Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-06-08 at 14:01 +0100, Lars Kurth wrote: > > On 8 Jun 2015, at 13:19, Ian Campbell wrote: > >=20 > > In MAINTAINERS S: Supported means: > >=20 > > "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. > >=20 > > For reference Maintained is "Someone actually looks after it.". > >=20 > > 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.=20 >=20 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 --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-sL3+F/c1I2kB0EUO1cfy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlV2AkoACgkQk4XaBE3IOsRZpQCghCVqntOsqNlDNQzWkriGI0fW QtQAn1yr71jCl9K4R9vhwlnuyYPlm/rm =KWuf -----END PGP SIGNATURE----- --=-sL3+F/c1I2kB0EUO1cfy-- --===============5294014656655638120== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5294014656655638120==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Clarifying the state of ARINC653 scheduler (and other components) in Xen 4.5 and beyond Date: Tue, 09 Jun 2015 10:53:38 +0100 Message-ID: <5576D3C2020000780008284A@mail.emea.novell.com> References: <55759FF802000078000820F3@mail.emea.novell.com> <1433765948.7108.484.camel@citrix.com> <3FDAE9EB-2D4C-41E2-83D9-B8A21609A267@gmail.com> <1433797194.2388.23.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1433797194.2388.23.camel@citrix.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli , Lars Kurth Cc: Joshua Whitehead , Wei Liu , Ian Campbell , Robert VanVossen , "" List-Id: xen-devel@lists.xenproject.org >>> On 08.06.15 at 22:59, wrote: > On Mon, 2015-06-08 at 14:01 +0100, Lars Kurth wrote: >> > On 8 Jun 2015, at 13:19, Ian Campbell 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars Kurth Subject: Re: Clarifying the state of ARINC653 scheduler (and other components) in Xen 4.5 and beyond Date: Wed, 10 Jun 2015 10:42:26 +0100 Message-ID: <8E07AF3D-EE33-45FA-942F-F133FB542D3F@gmail.com> References: <55759FF802000078000820F3@mail.emea.novell.com> <1433765948.7108.484.camel@citrix.com> <3FDAE9EB-2D4C-41E2-83D9-B8A21609A267@gmail.com> <1433797194.2388.23.camel@citrix.com> <5576D3C2020000780008284A@mail.emea.novell.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5576D3C2020000780008284A@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Wei Liu , Ian Campbell , Dario Faggioli , Robert VanVossen , "" , Joshua Whitehead List-Id: xen-devel@lists.xenproject.org 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 wrote: > >>>> On 08.06.15 at 22:59, wrote: >> On Mon, 2015-06-08 at 14:01 +0100, Lars Kurth wrote: >>>> On 8 Jun 2015, at 13:19, Ian Campbell 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Clarifying the state of ARINC653 scheduler (and other components) in Xen 4.5 and beyond Date: Wed, 10 Jun 2015 10:51:17 +0100 Message-ID: <557824B50200007800082F4A@mail.emea.novell.com> References: <55759FF802000078000820F3@mail.emea.novell.com> <1433765948.7108.484.camel@citrix.com> <3FDAE9EB-2D4C-41E2-83D9-B8A21609A267@gmail.com> <1433797194.2388.23.camel@citrix.com> <5576D3C2020000780008284A@mail.emea.novell.com> <8E07AF3D-EE33-45FA-942F-F133FB542D3F@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <8E07AF3D-EE33-45FA-942F-F133FB542D3F@gmail.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Lars Kurth Cc: Wei Liu , Ian Campbell , Dario Faggioli , Robert VanVossen , "" , Joshua Whitehead List-Id: xen-devel@lists.xenproject.org >>> On 10.06.15 at 11:42, 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Clarifying the state of ARINC653 scheduler (and other components) in Xen 4.5 and beyond Date: Wed, 10 Jun 2015 10:51:54 +0100 Message-ID: <557808BA.9010406@citrix.com> References: <55759FF802000078000820F3@mail.emea.novell.com> <1433765948.7108.484.camel@citrix.com> <3FDAE9EB-2D4C-41E2-83D9-B8A21609A267@gmail.com> <1433797194.2388.23.camel@citrix.com> <5576D3C2020000780008284A@mail.emea.novell.com> <8E07AF3D-EE33-45FA-942F-F133FB542D3F@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <8E07AF3D-EE33-45FA-942F-F133FB542D3F@gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Lars Kurth , Jan Beulich Cc: Wei Liu , Ian Campbell , Dario Faggioli , Robert VanVossen , "" , Joshua Whitehead List-Id: xen-devel@lists.xenproject.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars Kurth Subject: Re: Clarifying the state of ARINC653 scheduler (and other components) in Xen 4.5 and beyond Date: Thu, 11 Jun 2015 17:14:44 +0100 Message-ID: References: <55759FF802000078000820F3@mail.emea.novell.com> <1433765948.7108.484.camel@citrix.com> <3FDAE9EB-2D4C-41E2-83D9-B8A21609A267@gmail.com> <1433797194.2388.23.camel@citrix.com> <5576D3C2020000780008284A@mail.emea.novell.com> <8E07AF3D-EE33-45FA-942F-F133FB542D3F@gmail.com> <557808BA.9010406@citrix.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <557808BA.9010406@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: Wei Liu , Ian Campbell , Dario Faggioli , Robert VanVossen , "" , Joshua Whitehead , Jan Beulich List-Id: xen-devel@lists.xenproject.org > On 10 Jun 2015, at 10:51, Andrew Cooper 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars Kurth Subject: Re: Clarifying the state of ARINC653 scheduler (and other components) in Xen 4.5 and beyond Date: Fri, 12 Jun 2015 16:24:39 +0100 Message-ID: <054172F6-9203-496B-9DDB-9316F53362AD@gmail.com> References: <55759FF802000078000820F3@mail.emea.novell.com> <1433765948.7108.484.camel@citrix.com> <3FDAE9EB-2D4C-41E2-83D9-B8A21609A267@gmail.com> <1433797194.2388.23.camel@citrix.com> <5576D3C2020000780008284A@mail.emea.novell.com> <8E07AF3D-EE33-45FA-942F-F133FB542D3F@gmail.com> <557808BA.9010406@citrix.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <557808BA.9010406@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: Wei Liu , Ian Campbell , Dario Faggioli , Robert VanVossen , "" , Joshua Whitehead , Jan Beulich List-Id: xen-devel@lists.xenproject.org > On 10 Jun 2015, at 10:51, Andrew Cooper 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