Re: [Xen-devel] [RFC PATCH] Feature doc: Added Feature Maturity Lifecycle

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

Thank you for the feedback

> On 11 Nov 2015, at 16:33, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> 
> FWIW I think it would be valuable if we can CC some vendors /
> contributors and get feedback from them.

I will bring this up at the next board meeting and highlight the proposal

> Some comments below.
> 
> On Fri, Nov 06, 2015 at 12:35:44PM -0500, Lars Kurth wrote:
>> - Incorporated feedback from
>>  http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01992.html
>> 
>> Open Issues:
>> - Did not build and test the doc yet (want to get the content right first)
>> - Decide on supported status in MAINTAINER file
>> - Resolve loose ends on where and how to record Feature State
>> 
>> Signed-off-by: Lars Kurth <lars.kurth@xxxxxxxxxxxxxx>
>> ---
>> docs/features/feature-maturity-lifecycle.pandoc | 260 
>> ++++++++++++++++++++++++
>> 1 file changed, 260 insertions(+)
>> create mode 100644 docs/features/feature-maturity-lifecycle.pandoc
>> 
>> diff --git a/docs/features/feature-maturity-lifecycle.pandoc
>> b/docs/features/feature-maturity-lifecycle.pandoc
>> new file mode 100644
>> index 0000000..46f98a7
>> --- /dev/null
>> +++ b/docs/features/feature-maturity-lifecycle.pandoc
>> @@ -0,0 +1,260 @@
>> +% Feature Maturity Lifecycle
>> +% Revision 1
>> +
>> +\clearpage
>> +
>> +# Basics
>> +--------------- -------------------
>> +        Status: **Proposal**
>> +
>> +     Component: Development Process
>> +--------------- -------------------
>> +
> [...]
>> +## Complete
>> +This is a state which has not existed in the past. It is aimed
>> +at larger new features, which may only be in use or of interest
>> +to a small number of contributors, or where not enough expertise
>> +exists in the community to treat the feature as **Supported**. It
>> +presents an opportunity for developers to prove over one or
>> +two release cycles that said feature can be **supported** in future.
>> +
>> +* 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 behind the feature. There
>> +  is an expectation for the developers/maintainers to address
>> +  bugs and issues over a period of time.
>> +* Regressions and blockers in a complete feature do **not** normally
> 
> I would just remove "and blockers".

ACK

>> +  block new releases. It is at the discretion of the community
>> +  and Release Manager to downgrade the feature.
>> +  Security issues would **not** be handled by the security team.
>> +
>> +## 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.
> 
> ... in a supported feature ...

Well spotted

>> +* Security issues would be handled by the security team.
>> +
> 
> When do we downgrade feature with Supported status?  I think it's done
> near release like Complete?

I was thinking that this can happen at any time, but if say a test report where 
one is expected, doesn't come in, we would have to downgrade during RC stage.

>> +
>> +## Supported-Legacy-Stable
>> +According to this classification, a lot of our existing features would
>> +have to move back to **Experimental** until have tested and documented
>> +them. In other words, the following criteria may not always hold for
>> +such features:
>> +
>> +* Feature is **tested**
>> +* Feature is **documented**
>> +
>> +However many of these features and platforms are known to work in
>> +production. For this reason, such features will be marked as
>> +**Supported-Legacy-Stable** to ease migration to the new **Supported**
>> +criteria. **Supported-Legacy-Stable** fulfils the following criteria:
>> +
>> +* Intended functionality is **fully implemented**
>> +* Feature is **maintained**
>> +* Feature is **stable**
>> +* 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.
>> +
>> +## Deprecated
>> +There are typically two scenarios when a feature would be
>> +deprecated.
>> +* If the feature is not relevant any more or has been replaced
>> +  by a new implementation (e.g. xm vs. xl)
>> +* If we have lost the capability to support a feature.
>> +  For example when we have lost the capability to **maintain**
>> +  the feature, because we do not have maintainers. In such cases
>> +  raising the issue on xen-devel@ usually will lead to a resolution,
>> +  if there is enough usage by vendors in the eco-system.
>> +
>> +Features in any state can be deprecated.
>> +
>> +The following properties apply to deprecated features:
>> +* Bugs and issues can be raised on xen-devel@ and will be
>> +  handled at the discretion of the community.
>> +* Regressions and blockers in a deprecated feature do normally
>> +  block new releases.
> 
> Do or do not?

Should read: "do not"

> 
> Since by definition the community doesn't have capacity to support
> deprecated feature I don't see much point blocking release with it.
> 
> Wei.


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