Re: [Xen-devel] Proposal: Feature Maturity Lifecycle

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

> On 15 Jun 2015, at 12:26, George Dunlap <dunlapg@xxxxxxxxx> wrote:
> 
> On Fri, Jun 12, 2015 at 4:22 PM, Lars Kurth <lars.kurth.xen@xxxxxxxxx> wrote:
>> Hi all,
>> 
>> <snip>
>> 4.      Supported
>>        - Intended functionality is fully implemented
>>        - Feature is *maintained*
>>        - Feature is *tested*
>>        - Feature is *stable*
>>        - Feature is *documented*
>>        - Bugs and issues can be raised on xen-devel@ and will be
>>          handled by the developers/maintainers/committers within the
>>          community.
>>        - Regressions and blockers in a complete feature do normally
>>          block new releases.
>>        - Security issues would be handled by the security team.
> 
> So if we accept these definitions, it would would officially make
> adding functionality to osstest a requirement for everybody
> contributing new functionality.  I think at the moment, that may be
> too high a barrier, unless it becomes simple and straightforward to
> write, test, and contribute new tests to osstest.  (I think Stefano
> was trying to do this a bit with the raisin project, but that's not
> complete yet.)

That is a good point. Part of the reason for allowing 3rd party testing is to 
help with that, but this may not be sufficient.
The question is: how much of a gap do have today (or will we have by Xen 4.6)

> Another practical issue: There are existing large bits of
> functionality that are currently considered "supported" that are not
> tested as part of our continuous integration testing.  PCI
> pass-through is, I think, one major example.  According to this
> classification, a lot of our features would have to move back to
> "Experimental" until we managed to get things tested and documented.

PCI passthrough is interesting, because am not convinced we do handle security 
issues for it. Or are we?
Also, it is maybe something that isn't as easy to test automatically.
What other features that are supported do not get any testing?

> Do we want to have another category -- perhaps "Legacy-Stable" or
> something like that -- to indicate functionality which has been sort
> of "grandfathered" in to the "supported" state?  That would allow us
> to indicate that this functionality is actually usable, while keeping
> us honest and motivating us to move things into new "stable".

Another way would be to allow exceptions to cover for this case (we can use a 
footnote to that effect in the master document pointing that out). 
I don't mind either way, but it feels to me that we shouldn't introduce a new 
state for a boundary case. 
It all depends on how much of a problem do we have

Regards
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel