From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: [RFC PATCH] Feature doc: Added Feature Maturity Lifecycle Date: Tue, 1 Dec 2015 13:01:15 +0000 Message-ID: <20151201130115.GU21588@citrix.com> References: <20151111163344.GF10274@zion.uk.xensource.com> <72B279C7-0C6C-447A-8C73-0A60FC9173D1@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1a3kYa-0000CA-Bm for xen-devel@lists.xenproject.org; Tue, 01 Dec 2015 13:01:20 +0000 Content-Disposition: inline In-Reply-To: <72B279C7-0C6C-447A-8C73-0A60FC9173D1@gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Lars Kurth Cc: Wei Liu , Ian Campbell , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org On Tue, Dec 01, 2015 at 12:16:42PM +0000, Lars Kurth wrote: > > > On 11 Nov 2015, at 16:33, Wei Liu wrote: > > > > FWIW I think it would be valuable if we can CC some vendors / > > contributors and get feedback from them. > > I highlighted this at the Advisory Board meeting and the board is > supportive. Concrete feedback was > > A) "I'm generally supportive of this because I believe it will help > reduce ambiguities around the status of features and ultimately help > improve quality." This was mirrored by everyone at the last meeting. > > B) The preview vs. experimental classification was deemed to be a bit > arbitrary, and maybe we can fold them into one category. The feeling > was that the distinction does not provide much value and we should > maybe come up with something simpler. > > C) A concern raised was that by being explicit about "legacy" features > we may create negative PR opportunities, e.g. "the Xen Project has > declared 50% of its features to be untested and undocumented". Perhaps > instead we just grandfather these features into "stable" rather than > having an explicit "legacy-stable" designation. > Putting those into "stable" sounds reasonable to me. Plus some clarification as you mentioned below. > Another possible solution would be to be clear about what is > automatically tested and what requires manual testing (or is currently > tested by 3rd party test infrastructure such as XenRT and others) in > the "Supported" category. The argument that can be made is that for > "legacy-stable" we rely on 3rd party testing. This would help direct > test resources during Test Days towards such features. > > The documentation angle is probably less of an issue, because we have > user facing docs for pretty much everything in the man pages. So we > basically mainly talk about specs and other documents which are either > in the wiki or in docs/misc. And of course we can make judgement calls > for those docs in pretty much the same way as we do now. > > Any views on the pros and cons? > > Lars