>>> On 06.10.15 at 11:36, <ian.campb...@citrix.com> 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....@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.
I think tmem would make a very good one. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
