Re: Survey Results - Part 1 : Improving Xen Project Governance and Conventions

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2015-10-06 at 10:19 +0100, George Dunlap wrote:
> On Mon, Oct 5, 2015 at 11:31 PM, Lars Kurth <lars.kurth.xen@gmail.com>
> > I also think that for some areas of code (e.g. if experimental and
> > sufficiently modular) a more relaxed approach may well be acceptable
> > until it is more widely adopted. Maybe we can also link this to the
> > "Feature Lifecycle Maturity" proposal I made a while back.
> 
> FWIW we do sort of have this already: the arinc scheduler, for
> instance, was completely self-contained, and so went in with actually
> very little review of the scheduling code itself.
> 
> Unfortunately, there are very few features which can be isolated to
> this degree.  The vast majority of features submitted recently touch
> core code which is used frequently (and so can't be isolated); and
> also includes a public interface, which is something that we have to
> be very careful to get right, because we are committed to supporting
> it for years.

Also we should be careful that experimental features accepted in a more
relaxed way actually do get checked per the usual requirements (whether the
same as today or modified) before being declared something more than
experimental (whether that is production or some intermediate state).

I think we have had instances of this in the past which has lead to issues
(e.g. security ones or maintenance ones) down the line, although I have to
confess I'm drawing a blank on examples right now.

That's something where a proposal like Lars' lifecycle thing would help,
but I would worry that once the code is in tree it would't get the same
level of scrutiny when it comes to get "upgraded" as it would if it were
being submitted as a non-experimental feature in the first place, even we
say it should. I think simply being aware of that possibility is probably
sufficient to render this a non-blocker if we want to try this approach
though.

Ian.