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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

FWIW I think it would be valuable if we can CC some vendors /
contributors and get feedback from them.

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

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

> +* 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?


> +
> +## 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?

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