On Thu, 13 Oct 2016, Konrad Rzeszutek Wilk wrote:
> On October 13, 2016 2:13:19 PM EDT, Stefano Stabellini
> <sstabell...@kernel.org> 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
> >> > 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
> >> 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
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