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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 14/10/16 07:36, Jan Beulich wrote:
>>>> On 14.10.16 at 02:58, <sstabellini@xxxxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel