From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 490FEF958; Thu, 9 Feb 2017 12:54:26 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP; 09 Feb 2017 03:54:26 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,349,1484035200"; d="scan'208";a="818852759" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by FMSMGA003.fm.intel.com with ESMTP; 09 Feb 2017 03:54:24 -0800 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.173]) by IRSMSX152.ger.corp.intel.com ([169.254.6.191]) with mapi id 14.03.0248.002; Thu, 9 Feb 2017 11:54:24 +0000 From: "O'Driscoll, Tim" To: Thomas Monjalon , "dev@dpdk.org" CC: "techboard@dpdk.org" Thread-Topic: [dpdk-dev] decision process and DPDK scope Thread-Index: AQHSgsV0M41s8SPJs0O+s6Y/r3B4DaFgjwQg Date: Thu, 9 Feb 2017 11:54:23 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA722B9CB4@IRSMSX108.ger.corp.intel.com> References: <1667864.GflPPoyiWF@xps13> In-Reply-To: <1667864.GflPPoyiWF@xps13> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGM1ZGJlNDQtZjc5YS00NjNlLTg2OTItOTdjZmE3ZDUyZjE5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjIuMTEuMCIsIlRydXN0ZWRMYWJlbEhhc2giOiJsN0VwTk9ZdkRZK3dYYWhBNFlGcGZcL3JibFhIOHVxaGg2bjgwdmFqNUNKTT0ifQ== x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] decision process and DPDK scope X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 11:54:28 -0000 > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon >=20 > Hi all, >=20 > When DPDK was a small project, it was easy to propose a major change, > get feedback from the few contributors and figure a decision. > It had the drawback of the lack of various point of views. > So we probably made some quick and wrong decisions. >=20 > As the community is growing, we need to improve the decision process > to make sure the responsibilities are well shared and represent the > diversity of the community. >=20 > There has been a recent failure in this process. I would like to show > it as an example of things to better solve. > During last August, a patch was sent: "add bit-rate metrics to xstats". > After more thoughts, a v2 was sent in October: "expanded statistic > reporting". > Starting from this version, the idea was to add completely new > libraries. > Nobody (including me) asked why we should maintain these things in DPDK. > I have just realized that there was neither discussion on the need for > these > libraries nor on the DPDK scope. I feel the DPDK scope (and API in > general) > should be better owned by the community. So I took the decision to not > integrate these patches in 17.02 and I'm sorry about that. > It is a failure to not give good feedbacks on time. > It is a failure to not ask the right questions. > It is a failure to not have more attention on a new feature. > It is a failure to take such decision alone. >=20 > I think we can use this case to avoid seeing it again in the future. > I suggest that the technical board should check whether every new > proposed > features are explained, discussed and approved enough in the community. I assume you don't mean every new feature, just those that involve major ch= anges (new libraries, new/modified APIs etc.). Is that correct? > If needed, the technical board meeting minutes will give some lights to > the threads which require more attention. > Before adding a new library or adding a major API, there should be > some strong reviews which include discussing the DPDK scope. >=20 > Openness of a large community is proven by its active feedbacks. +1 At the moment, when there's no feedback on an RFC or patch set, there's no = way of knowing whether that means people are happy with it or that nobody h= as reviewed it. Using the Tech Board to highlight RFCs/patch sets that requ= ire more review is a good idea.