>>> On 14.10.16 at 11:59, <george.dun...@citrix.com> wrote: > On 14/10/16 07:36, Jan Beulich wrote: >>>>> On 14.10.16 at 02:58, <sstabell...@kernel.org> 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
