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