[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Survey Results - Part 1 : Improving Xen Project Governance and Conventions
>>> On 06.10.15 at 11:36, <ian.campbell@xxxxxxxxxx> wrote: > 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@xxxxxxxxx> >> > 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. I think tmem would make a very good one. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |