[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.