[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH] Feature doc: Added Feature Maturity Lifecycle
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |