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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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.

>         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.

>         The intention here is to require that the central file is modified
>         with a patch that introduces a feature (state, feature title,
>         short description) and that developers which add functionality
>         modify accordingly. The release manager and other stake-holders
>         such as the community may also propose changes during the release
>         cycle (in particular towards the end). 

Right.

Ian.

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