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

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

> On 15 Jun 2015, at 13:21, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> 
> Lars Kurth writes ("Proposal: Feature Maturity Lifecycle"):
>> following up from 
>> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01775.html I 
>> wanted to propose the following convention related to feature classification 
>> as a proposal for discussion. I tried to pretty much describe what we do now 
>> and hope my understanding is correct. I did propose a new Complete state, to 
>> cover for bigger new features which we may not want to mark as supported 
>> straight away, for various reasons.
>> 
>> I marked areas which with some of my thoughts or references to other 
>> documents in [Note: ...] brackets
> 
> There is much here that is good.
> 
>>        Dependencies
>>        -------------
>> 
>> This document refers to definitions in other files and project conventions,
>> in particular:
>> 
>> 1.      Status of subsystems in the MAINTAINERS file
>>      The MAINTAINERS file maps individuals against groups of files 
>>        in the source tree. In there context of this document, we say that
>>        a feature is *maintained*, iff all components of that feature
>>        are marked as one of the following
>>        Supported:  Someone is actually paid to look after the code.
>>        Maintained: Someone actually looks after the code.
> 
> As part of this, we should rename the `Supported' field in
> MAINTAINERS.  I'm not sure that `Supported' makes enough of a
> difference from `Maintained' to be worth distinguishing.  So I would
> propose to abolish the category `Supported'.
> 
> If we do want to continue to distinguish what is currently called
> `Supported' it needs a new name.

Agreed. How about replacing Supported by "Company-Maintained" or something 
similar.

> 
>>        State Changes
>>        -------------        
>> [Note:  this assumes that we keep a document in the source tree which
>>        provides a snapshot of information akin a snapshot of
>>        http://wiki.xenproject.org/wiki/Xen_Project_Release_Features
>>        in the source tree. I am volunteering to maintain the wiki
>>        and initially populate the file based on existing information.
>>        Andy Cooper suggested he is willing to put together a template
>>        with some examples. See 
>> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01369.html]
> 
> I think that we should avoid introducing new manual-transfer tasks.
> 
> The document should be in tree (in docs/) in such a way that it is
> automatically published (on xenbits) along with the other
> documentation.

I think we are thinking along the same lines here and the intention is to 
generate a snapshot of functionality in tree.

However, I do also believe that the time evolution view in 
http://wiki.xenproject.org/wiki/Xen_Project_Release_Features is valuable and it 
is probably too hard to do this in an automated fashion, at least initially. So 
my offer is to maintain that manually, until we have some automated way of 
doing this.

Regards
Lars


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