Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

2016-10-14 Thread Stefano Stabellini 
On Fri, 14 Oct 2016, Jan Beulich wrote:
> >>> On 14.10.16 at 11:59,  wrote:
> > On 14/10/16 07:36, Jan Beulich wrote:
> > On 14.10.16 at 02:58,  wrote:
> >>> On Fri, 14 Oct 2016, Andrew Cooper wrote:
>  There should be a high barrier to "Supported" status, because the cost
>  of getting it wrong is equally high.  However, there are perfectly
>  legitimate intermediate stages such as "Supported in these limited set
>  of circumstances".  A number of features are not plausibly for use in
>  production environments, but otherwise function fine for
>  development/investigatory purposes.  In these cases, something like "no
>  security support, but believed to be working fine" might be appropriate.
> >>>
> >>> I agree on this. I think we need an intermediate step: "working but not
> >>> supported for security" is completely reasonable. When we say that it is
> >>> "working", it should be because we have automated testing for it (I
> >>> don't know if I would go as far as requiring it to be in OSSTest, any
> >>> automated testing, even third party, would do). If it is not
> >>> automatically tested, then it is just "best effort".
> >> 
> >> I don't think this is a reasonable expectation - how would you envision
> >> testing the dozens of command line options alone, not to speak of
> >> things depending on hardware characteristics?
> > 
> > Well there may be situations where we can make reasonable exceptions.
> > But it would certainly be a lot better if a feature wasn't considered
> > "done" until there was something in place to make sure that it worked
> > and continued to work, other than "we hope people use it and report any
> > bugs they find".
> 
> Perhaps an earlier question here is what a "feature" is. My command
> line option example was specifically chosen to make it possibly very
> small scope, yet indicate an area where we would likely say "using
> this and that option is not supported" (depending on the instance
> with either of the two meanings you name below).

This is another one of those cases where we need to apply our judgement
on a case by case basis.


> > The more interesting aspect of Stefano's suggestion here is whether
> > there should be two levels of "supported" -- "supported" as in, "this
> > works but it's not in our security boundary", and "supported" as in,
> > "this works and it *is* in our security boundary".
> 
> To me the question is how far that would matter for people
> wanting to use Xen in production: I for one wouldn't feel well
> using features which aren't security supported.

Sure, but Xen isn't only used in high availability production systems.
For example one use case for Xen on ARM is IoT, a space where most
devices don't even have a way to be securely updated yet. (I hope that
people using Xen on ARM in those scenarios do have a way to patch theirs
devices.)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

2016-10-14 Thread Stefano Stabellini 
On Fri, 14 Oct 2016, George Dunlap wrote:
> On 14/10/16 07:36, Jan Beulich wrote:
>  On 14.10.16 at 02:58,  wrote:
> >> On Fri, 14 Oct 2016, Andrew Cooper wrote:
> >>> There should be a high barrier to "Supported" status, because the cost
> >>> of getting it wrong is equally high.  However, there are perfectly
> >>> legitimate intermediate stages such as "Supported in these limited set
> >>> of circumstances".  A number of features are not plausibly for use in
> >>> production environments, but otherwise function fine for
> >>> development/investigatory purposes.  In these cases, something like "no
> >>> security support, but believed to be working fine" might be appropriate.
> >>
> >> I agree on this. I think we need an intermediate step: "working but not
> >> supported for security" is completely reasonable. When we say that it is
> >> "working", it should be because we have automated testing for it (I
> >> don't know if I would go as far as requiring it to be in OSSTest, any
> >> automated testing, even third party, would do). If it is not
> >> automatically tested, then it is just "best effort".
> > 
> > I don't think this is a reasonable expectation - how would you envision
> > testing the dozens of command line options alone, not to speak of
> > things depending on hardware characteristics?
>
> Well there may be situations where we can make reasonable exceptions.
> But it would certainly be a lot better if a feature wasn't considered
> "done" until there was something in place to make sure that it worked
> and continued to work, other than "we hope people use it and report any
> bugs they find".

It is difficult to generalize, because, as Jan wrote, some things come
with dozen of command line options, some other things come with none.
This is were we'll have to apply our judgment on a case by case basis.
But indeed the basic idea is that it is "done" when there is some
testing for it, where "some" is case specific. Community testing is
great, but automated testing is more reliable and predictable.

At the same time this is an Open Source community and we might get
contributions from people that aren't paid to work on Xen. We cannot
ask all contributors to write automated testing scripts, and maybe offer
security support. A contributor might write good code for a new feature
but refuse to write the testing for it. I think that's OK, we can take
that code, but then we need to clarify the state of that feature with
the community.

On one hand we don't want users to think a feature is fully stable and
supported when actually it is not. It negatively impacts Xen brand and
reputation. On the other hand we don't want to discourage contributions
by asking to commit to security support, automated testing, ABI
stability etc. from the start. Rome wasn't built in a day :-)
Can you imagine if we accepted ARM patches in Xen only after Xen on ARM
was ready for automated testing and security support?

The best way to achieve both goals at the same time is to clarify the
right level of quality/stability/support for each feature.


> The more interesting aspect of Stefano's suggestion here is whether
> there should be two levels of "supported" -- "supported" as in, "this
> works but it's not in our security boundary", and "supported" as in,
> "this works and it *is* in our security boundary".

I think the security team should be free to refuse to offer support for
something, which otherwise might be considered working and stable. It
might not even be a vote of distrust: after all the security team has
only a finite amount of resources, maybe not enough to cover all areas
of the project.


> But as we don't *yet* have such a decision-making process in place, I
> think we need to approach each change in an ad-hoc manner.  Having a
> discussion about *credit2* which includes the security aspects makes
> sense, and I don't think we need to wait until we've got a generalized
> framework to make a reasonable decision about that.

By no means I meant to delay Dario's work.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

2016-10-14 Thread Jan Beulich 
>>> On 14.10.16 at 11:59,  wrote:
> On 14/10/16 07:36, Jan Beulich wrote:
> On 14.10.16 at 02:58,  wrote:
>>> On Fri, 14 Oct 2016, Andrew Cooper wrote:
 There should be a high barrier to "Supported" status, because the cost
 of getting it wrong is equally high.  However, there are perfectly
 legitimate intermediate stages such as "Supported in these limited set
 of circumstances".  A number of features are not plausibly for use in
 production environments, but otherwise function fine for
 development/investigatory purposes.  In these cases, something like "no
 security support, but believed to be working fine" might be appropriate.
>>>
>>> I agree on this. I think we need an intermediate step: "working but not
>>> supported for security" is completely reasonable. When we say that it is
>>> "working", it should be because we have automated testing for it (I
>>> don't know if I would go as far as requiring it to be in OSSTest, any
>>> automated testing, even third party, would do). If it is not
>>> automatically tested, then it is just "best effort".
>> 
>> I don't think this is a reasonable expectation - how would you envision
>> testing the dozens of command line options alone, not to speak of
>> things depending on hardware characteristics?
> 
> Well there may be situations where we can make reasonable exceptions.
> But it would certainly be a lot better if a feature wasn't considered
> "done" until there was something in place to make sure that it worked
> and continued to work, other than "we hope people use it and report any
> bugs they find".

Perhaps an earlier question here is what a "feature" is. My command
line option example was specifically chosen to make it possibly very
small scope, yet indicate an area where we would likely say "using
this and that option is not supported" (depending on the instance
with either of the two meanings you name below).

> The more interesting aspect of Stefano's suggestion here is whether
> there should be two levels of "supported" -- "supported" as in, "this
> works but it's not in our security boundary", and "supported" as in,
> "this works and it *is* in our security boundary".

To me the question is how far that would matter for people
wanting to use Xen in production: I for one wouldn't feel well
using features which aren't security supported.

> But as we don't *yet* have such a decision-making process in place, I
> think we need to approach each change in an ad-hoc manner.  Having a
> discussion about *credit2* which includes the security aspects makes
> sense, and I don't think we need to wait until we've got a generalized
> framework to make a reasonable decision about that.

Sure.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

2016-10-14 Thread George Dunlap 
On 14/10/16 07:36, Jan Beulich wrote:
 On 14.10.16 at 02:58,  wrote:
>> On Fri, 14 Oct 2016, Andrew Cooper wrote:
>>> There should be a high barrier to "Supported" status, because the cost
>>> of getting it wrong is equally high.  However, there are perfectly
>>> legitimate intermediate stages such as "Supported in these limited set
>>> of circumstances".  A number of features are not plausibly for use in
>>> production environments, but otherwise function fine for
>>> development/investigatory purposes.  In these cases, something like "no
>>> security support, but believed to be working fine" might be appropriate.
>>
>> I agree on this. I think we need an intermediate step: "working but not
>> supported for security" is completely reasonable. When we say that it is
>> "working", it should be because we have automated testing for it (I
>> don't know if I would go as far as requiring it to be in OSSTest, any
>> automated testing, even third party, would do). If it is not
>> automatically tested, then it is just "best effort".
> 
> I don't think this is a reasonable expectation - how would you envision
> testing the dozens of command line options alone, not to speak of
> things depending on hardware characteristics?

Well there may be situations where we can make reasonable exceptions.
But it would certainly be a lot better if a feature wasn't considered
"done" until there was something in place to make sure that it worked
and continued to work, other than "we hope people use it and report any
bugs they find".

The more interesting aspect of Stefano's suggestion here is whether
there should be two levels of "supported" -- "supported" as in, "this
works but it's not in our security boundary", and "supported" as in,
"this works and it *is* in our security boundary".

But as we don't *yet* have such a decision-making process in place, I
think we need to approach each change in an ad-hoc manner.  Having a
discussion about *credit2* which includes the security aspects makes
sense, and I don't think we need to wait until we've got a generalized
framework to make a reasonable decision about that.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

2016-10-14 Thread Dario Faggioli 
On Thu, 2016-10-13 at 13:46 +0100, Wei Liu wrote:
> On Thu, Oct 13, 2016 at 01:44:28PM +0100, Dario Faggioli wrote:
> > 
> > Ok, so, if that's the case, what's the process: resend (this patch)
> > --
> > or some other kind of formal request-- with secur...@xenproject.org
> > Cc-ed?
> > 
> 
> If you want these to be applied more quickly the best thing to do is
> to
> leave the status experimental and later send another patch with
> security@ CC'ed to change the status.
> 
I like this as a way forward... lemme see if I can do that before going
to catch a train that will make me catch a plane! :-D

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

2016-10-14 Thread Jan Beulich 
>>> On 14.10.16 at 02:58,  wrote:
> On Fri, 14 Oct 2016, Andrew Cooper wrote:
>> There should be a high barrier to "Supported" status, because the cost
>> of getting it wrong is equally high.  However, there are perfectly
>> legitimate intermediate stages such as "Supported in these limited set
>> of circumstances".  A number of features are not plausibly for use in
>> production environments, but otherwise function fine for
>> development/investigatory purposes.  In these cases, something like "no
>> security support, but believed to be working fine" might be appropriate.
> 
> I agree on this. I think we need an intermediate step: "working but not
> supported for security" is completely reasonable. When we say that it is
> "working", it should be because we have automated testing for it (I
> don't know if I would go as far as requiring it to be in OSSTest, any
> automated testing, even third party, would do). If it is not
> automatically tested, then it is just "best effort".

I don't think this is a reasonable expectation - how would you envision
testing the dozens of command line options alone, not to speak of
things depending on hardware characteristics?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

2016-10-13 Thread Stefano Stabellini 
On Fri, 14 Oct 2016, Andrew Cooper wrote:
> > I like the idea of keeping these info on pandoc on a git repo, like Lars
> > did with the governance.
> 
> I should hasten to add that perhaps picking on the security team in
> isolation was a poor move on my part, for which I apologise. There are
> multiple involved parties with different interests, all of which need
> attending to.

No worries, on my part I just think that we should write down these
things to remember, set expectations and to avoid surprises.


> The feature submitter (should) have a vested interest in getting code
> submitted (even as experimental/tech preview to start with), so that
> others can trial/debug/extend the feature.  Even having code upstream
> but disabled-by-default in Kconfig is a far better position for others
> to start from, than to be provided with instructions saying "there was a
> patch series several months ago on a mailing list".

Undeniably true.

 
> The reviewers/maintainers (should) have a vested interest in keeping the
> overall quality up.  Due to their appointment within the community, they
> have demonstrated knowledge and expertise in their respective areas, and
> the overall project relies on them to ask questions such as "How does $X
> work with $Y?" or "Have you considered $Z as an alternative?", and to
> come to a fair and unbiased opinion to the quality and worthiness of a
> feature.
> 
> The release manager has conflicted vested interests.  On the one hand,
> getting more features in a release is better on paper and in the press,
> but can certainly backfire when features aren't up to scratch. 
> Ultimately, if features in a release are substandard, the downstreams
> and end users will be the ones to bear the pain.  It is in the release
> managers best interest to ensure that the features which are finally
> accepted are actually ready.
> 
> Nothing is ever perfect, but a whole lot of stuff is perfectly good in
> common case, and useful for people in general.  This is why the feature
> doc template specifically has sections for know issues to be fixed, and
> areas for future improvement.  Any documentation (so long as it isn't
> factually incorrect) is better than nothing.
> 
> There seems to be general consensus that a status of "Supported" means
> "with security support", and I agree with this assessment.  Ultimately,
> the security team is accountable to whatever the project as a whole
> declares "Supported", but as the security team are all commiters and
> maintainer there is a large overlap of responsibility.  OTOH, the
> security team are also responsible for managing the fallout when things
> go wrong.
> 
> XSAs are bad publicity, and are a problem for downstreams (remember that
> we have plenty of downstreams who measure quantity of servers in units
> of a datacenter).  Another problem we as a community have is that no
> support status is written down; there is a 13ish? year backlog in this
> regard.  Writing details down in feature docs is intended to get
> everyone on the same, un-ambiguous, page.
> 
> We also have an unfortunate habit of new features appearing, being
> accepted, and (intentionally or unintentionally) available to guests. 
> Fastforward a bit, and it is discovered that said feature resembles a
> sieve in terms of security holes, and the common recourse is to publish
> an XSA stating "turn it off and don't use it with untrusted guests", or
> "here is a patch to actually turn it off, and still don't use it with
> untrusted guests", because we really can't re-engineer a feature in a
> security patch.  (Sorry to pick on TMEM here, but it is now 4 years of
> development later and it still has a lot of development left to go. 
> Reworking features in the light of a security hole can be very
> complicated, and lots of work.)

Yes, that's definitely a position we should try not to be in.


> There should be a high barrier to "Supported" status, because the cost
> of getting it wrong is equally high.  However, there are perfectly
> legitimate intermediate stages such as "Supported in these limited set
> of circumstances".  A number of features are not plausibly for use in
> production environments, but otherwise function fine for
> development/investigatory purposes.  In these cases, something like "no
> security support, but believed to be working fine" might be appropriate.

I agree on this. I think we need an intermediate step: "working but not
supported for security" is completely reasonable. When we say that it is
"working", it should be because we have automated testing for it (I
don't know if I would go as far as requiring it to be in OSSTest, any
automated testing, even third party, would do). If it is not
automatically tested, then it is just "best effort".

Finally some features involve some sort of ABI exposed to the guest. At
some point when the feature is "Supported", the ABI will be most
certainly maintained for backward compatibility. But the feature could
be fully

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

2016-10-13 Thread Andrew Cooper 
On 13/10/2016 22:06, Stefano Stabellini wrote:
>
> Credit2 **Supperted**, instead of experimental.
 Supperted?  That's like supported right? ;p


 It is fine for you to propose that a feature should be upgraded to
 supported, and this is probably the best way to formally do so.

 However, final agreement of a feature becoming supported should
>>> include
 input from the security team. (At the end of the day, it is us with
 extra work if the feature isn't up to scratch.)
>>> Is this new? If so, should we formalize the change in process somewhere
>>> (patch to governance, etc.)?
>> This came about when we had .. XSA7? Which was the tmem one and came with 
>> the idea that anything that moves to Supported has to pass the security 
>> audit pass.

Off the top of my head, XSA-7 is the Intel silicon sysret bug.  ITYM
XSA-15, but your point still stands.

> Make sense. In that case we should definitely write it down somewhere.

My entire purpose with introducing feature docs to start with was to try
and do for feature what we now do very well for
docs/misc/xen-command-line.markdown  i.e. to keep the documentation
easy, and up to date.

This does involve the committers, maintainers and reviewers being
mindful to prompt for an update when necessary.  However, it is very
evident from the replies on-list these days that it has become second
nature to a lot of people to either patch the document in the first
place, or prompt others to do the same in submitted patches.

Overall, this is a very good position to be in, for the community as a
whole.  I am certainly hoping that in another couple of years, we as a
community have exactly the same "second nature" mindset when it comes to
keeping the feature docs up to date.

> I like the idea of keeping these info on pandoc on a git repo, like Lars
> did with the governance.

I should hasten to add that perhaps picking on the security team in
isolation was a poor move on my part, for which I apologise. There are
multiple involved parties with different interests, all of which need
attending to.

The feature submitter (should) have a vested interest in getting code
submitted (even as experimental/tech preview to start with), so that
others can trial/debug/extend the feature.  Even having code upstream
but disabled-by-default in Kconfig is a far better position for others
to start from, than to be provided with instructions saying "there was a
patch series several months ago on a mailing list".

The reviewers/maintainers (should) have a vested interest in keeping the
overall quality up.  Due to their appointment within the community, they
have demonstrated knowledge and expertise in their respective areas, and
the overall project relies on them to ask questions such as "How does $X
work with $Y?" or "Have you considered $Z as an alternative?", and to
come to a fair and unbiased opinion to the quality and worthiness of a
feature.

The release manager has conflicted vested interests.  On the one hand,
getting more features in a release is better on paper and in the press,
but can certainly backfire when features aren't up to scratch. 
Ultimately, if features in a release are substandard, the downstreams
and end users will be the ones to bear the pain.  It is in the release
managers best interest to ensure that the features which are finally
accepted are actually ready.

Nothing is ever perfect, but a whole lot of stuff is perfectly good in
common case, and useful for people in general.  This is why the feature
doc template specifically has sections for know issues to be fixed, and
areas for future improvement.  Any documentation (so long as it isn't
factually incorrect) is better than nothing.

There seems to be general consensus that a status of "Supported" means
"with security support", and I agree with this assessment.  Ultimately,
the security team is accountable to whatever the project as a whole
declares "Supported", but as the security team are all commiters and
maintainer there is a large overlap of responsibility.  OTOH, the
security team are also responsible for managing the fallout when things
go wrong.

XSAs are bad publicity, and are a problem for downstreams (remember that
we have plenty of downstreams who measure quantity of servers in units
of a datacenter).  Another problem we as a community have is that no
support status is written down; there is a 13ish? year backlog in this
regard.  Writing details down in feature docs is intended to get
everyone on the same, un-ambiguous, page.

We also have an unfortunate habit of new features appearing, being
accepted, and (intentionally or unintentionally) available to guests. 
Fastforward a bit, and it is discovered that said feature resembles a
sieve in terms of security holes, and the common recourse is to publish
an XSA stating "turn it off and don't use it with untrusted guests", or
"here is a patch to actually turn it off, and still don't use it with
untrusted guests", because

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

2016-10-13 Thread Stefano Stabellini 
On Thu, 13 Oct 2016, Konrad Rzeszutek Wilk wrote:
> On October 13, 2016 2:13:19 PM EDT, Stefano Stabellini 
>  wrote:
> >On Thu, 13 Oct 2016, Andrew Cooper wrote:
> >> On 13/10/16 12:01, Dario Faggioli wrote:
> >> > Hey,
> >> >
> >> > "Just" as per the subject, I wrote feature documents for (almost)
> >all our
> >> > schedulers. No big deal, I'd say, apart from the fact that I'm
> >declaring
> >> > Credit2 **Supperted**, instead of experimental.
> >> 
> >> Supperted?  That's like supported right? ;p
> >> 
> >> 
> >> It is fine for you to propose that a feature should be upgraded to
> >> supported, and this is probably the best way to formally do so.
> >> 
> >> However, final agreement of a feature becoming supported should
> >include
> >> input from the security team. (At the end of the day, it is us with
> >> extra work if the feature isn't up to scratch.)
> >
> >Is this new? If so, should we formalize the change in process somewhere
> >(patch to governance, etc.)?
> 
> This came about when we had .. XSA7? Which was the tmem one and came with the 
> idea that anything that moves to Supported has to pass the security audit 
> pass.

Make sense. In that case we should definitely write it down somewhere. I
like the idea of keeping these info on pandoc on a git repo, like Lars
did with the governance.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

2016-10-13 Thread Konrad Rzeszutek Wilk 
On October 13, 2016 2:13:19 PM EDT, Stefano Stabellini  
wrote:
>On Thu, 13 Oct 2016, Andrew Cooper wrote:
>> On 13/10/16 12:01, Dario Faggioli wrote:
>> > Hey,
>> >
>> > "Just" as per the subject, I wrote feature documents for (almost)
>all our
>> > schedulers. No big deal, I'd say, apart from the fact that I'm
>declaring
>> > Credit2 **Supperted**, instead of experimental.
>> 
>> Supperted?  That's like supported right? ;p
>> 
>> 
>> It is fine for you to propose that a feature should be upgraded to
>> supported, and this is probably the best way to formally do so.
>> 
>> However, final agreement of a feature becoming supported should
>include
>> input from the security team. (At the end of the day, it is us with
>> extra work if the feature isn't up to scratch.)
>
>Is this new? If so, should we formalize the change in process somewhere
>(patch to governance, etc.)?

This came about when we had .. XSA7? Which was the tmem one and came with the 
idea that anything that moves to Supported has to pass the security audit pass.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

2016-10-13 Thread Stefano Stabellini 
On Thu, 13 Oct 2016, Andrew Cooper wrote:
> On 13/10/16 12:01, Dario Faggioli wrote:
> > Hey,
> >
> > "Just" as per the subject, I wrote feature documents for (almost) all our
> > schedulers. No big deal, I'd say, apart from the fact that I'm declaring
> > Credit2 **Supperted**, instead of experimental.
> 
> Supperted?  That's like supported right? ;p
> 
> 
> It is fine for you to propose that a feature should be upgraded to
> supported, and this is probably the best way to formally do so.
> 
> However, final agreement of a feature becoming supported should include
> input from the security team. (At the end of the day, it is us with
> extra work if the feature isn't up to scratch.)

Is this new? If so, should we formalize the change in process somewhere
(patch to governance, etc.)?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

2016-10-13 Thread Wei Liu 
On Thu, Oct 13, 2016 at 01:44:28PM +0100, Dario Faggioli wrote:
> On Thu, 2016-10-13 at 12:28 +0100, Andrew Cooper wrote:
> > On 13/10/16 12:01, Dario Faggioli wrote:
> > > "Just" as per the subject, I wrote feature documents for (almost)
> > > all our
> > > schedulers. No big deal, I'd say, apart from the fact that I'm
> > > declaring
> > > Credit2 **Supperted**, instead of experimental.
> > 
> > Supperted?  That's like supported right? ;p
> > 
> Nah, 'supperted' is the new 'supported', didn't you know? :-P
> 
> > It is fine for you to propose that a feature should be upgraded to
> > supported, and this is probably the best way to formally do so.
> > 
> > However, final agreement of a feature becoming supported should
> > include
> > input from the security team. (At the end of the day, it is us with
> > extra work if the feature isn't up to scratch.)
> > 
> Ok, so, if that's the case, what's the process: resend (this patch) --
> or some other kind of formal request-- with secur...@xenproject.org
> Cc-ed?
> 

If you want these to be applied more quickly the best thing to do is to
leave the status experimental and later send another patch with
security@ CC'ed to change the status.

Wei.

> Regards,
> Dario
> -- 
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

2016-10-13 Thread Dario Faggioli 
On Thu, 2016-10-13 at 12:28 +0100, Andrew Cooper wrote:
> On 13/10/16 12:01, Dario Faggioli wrote:
> > "Just" as per the subject, I wrote feature documents for (almost)
> > all our
> > schedulers. No big deal, I'd say, apart from the fact that I'm
> > declaring
> > Credit2 **Supperted**, instead of experimental.
> 
> Supperted?  That's like supported right? ;p
> 
Nah, 'supperted' is the new 'supported', didn't you know? :-P

> It is fine for you to propose that a feature should be upgraded to
> supported, and this is probably the best way to formally do so.
> 
> However, final agreement of a feature becoming supported should
> include
> input from the security team. (At the end of the day, it is us with
> extra work if the feature isn't up to scratch.)
> 
Ok, so, if that's the case, what's the process: resend (this patch) --
or some other kind of formal request-- with secur...@xenproject.org
Cc-ed?

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

2016-10-13 Thread George Dunlap 
On 13/10/16 12:28, Andrew Cooper wrote:
> On 13/10/16 12:01, Dario Faggioli wrote:
>> Hey,
>>
>> "Just" as per the subject, I wrote feature documents for (almost) all our
>> schedulers. No big deal, I'd say, apart from the fact that I'm declaring
>> Credit2 **Supperted**, instead of experimental.
> 
> Supperted?  That's like supported right? ;p
> 
> 
> It is fine for you to propose that a feature should be upgraded to
> supported, and this is probably the best way to formally do so.
> 
> However, final agreement of a feature becoming supported should include
> input from the security team. (At the end of the day, it is us with
> extra work if the feature isn't up to scratch.)

Yes, interesting idea.  I don't think in our discussions of feature
lifecycle maturity we'd talked about that yet.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

2016-10-13 Thread Andrew Cooper 
On 13/10/16 12:01, Dario Faggioli wrote:
> Hey,
>
> "Just" as per the subject, I wrote feature documents for (almost) all our
> schedulers. No big deal, I'd say, apart from the fact that I'm declaring
> Credit2 **Supperted**, instead of experimental.

Supperted?  That's like supported right? ;p


It is fine for you to propose that a feature should be upgraded to
supported, and this is probably the best way to formally do so.

However, final agreement of a feature becoming supported should include
input from the security team. (At the end of the day, it is us with
extra work if the feature isn't up to scratch.)

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

2016-10-13 Thread Dario Faggioli 
Hey,

"Just" as per the subject, I wrote feature documents for (almost) all our
schedulers. No big deal, I'd say, apart from the fact that I'm declaring
Credit2 **Supperted**, instead of experimental.

In fact, it's being tested by OSSTest for ages, and it's undergone a huge
amount of development, testing and benchmarking lately, and its current status
is finally good enough, IMO.

As a consequence of that, in patch 2, I'm also touching the code, but that's
just for removing a printk, so it should not be too big of a deal I hope.

This wiki page is listed among the references in Credit2's feature document:
https://wiki.xenproject.org/wiki/Credit2_Scheduler_Development.
If you go there checking it out, bear in mind that I'm updating and
re-organazing it by quite a bit, like right now.

Sorry if the Cc-list is a bit large, but that's the best I and
get_maintainers.pl could come up with. :-P

Thanks and Regards,
Dario
---
Dario Faggioli (3):
  docs: Credit1 feature document.
  docs: Credit2 feature document.
  docs: RTDS feature document.

 docs/features/credit.pandoc  |   99 +
 docs/features/credit2.pandoc |  123 +
 docs/features/rtds.pandoc|  125 ++
 xen/common/sched_credit2.c   |2 -
 4 files changed, 347 insertions(+), 2 deletions(-)
 create mode 100644 docs/features/credit.pandoc
 create mode 100644 docs/features/credit2.pandoc
 create mode 100644 docs/features/rtds.pandoc
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel