From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id CD7322E81 for ; Wed, 18 Nov 2015 18:54:45 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP; 18 Nov 2015 09:54:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,313,1444719600"; d="scan'208";a="841674688" Received: from irsmsx109.ger.corp.intel.com ([163.33.3.23]) by fmsmga001.fm.intel.com with ESMTP; 18 Nov 2015 09:54:44 -0800 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.23]) by IRSMSX109.ger.corp.intel.com ([169.254.13.96]) with mapi id 14.03.0248.002; Wed, 18 Nov 2015 17:54:43 +0000 From: "O'Driscoll, Tim" To: "'dev@dpdk.org'" Thread-Topic: Architecture Board Proposal Thread-Index: AdESXXFZp4hchkInQi2ciOcDI//rHAPyJH9A Date: Wed, 18 Nov 2015 17:54:42 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA67464A14@IRSMSX108.ger.corp.intel.com> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA674488A2@IRSMSX108.ger.corp.intel.com> In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA674488A2@IRSMSX108.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] Architecture Board Proposal X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 17:54:46 -0000 In order to progress this, I'd like to summarise what's been discussed on t= he mailing list so far (both in this thread and in the one Dave Neary start= ed on governance proposals from the Userspace event) and give a final chanc= e to people to provide any additional input. The main things that came up i= n the discussion were: - We need to agree whether the scope of the board is just DPDK (http://dpdk= .org/browse/dpdk/) or if it's all projects hosted on dpdk.org (http://dpdk.= org/browse/). The consensus seemed to be just DPDK. - It was reiterated that the board should only make decisions when a consen= sus isn't reached on the mailing this. This should not happen often, so the= workload should be light. - Membership needs to be based on contributions. There were requests for AR= M SoC representation on the board, but most people felt that contributions = should come from the SoC vendors first. Now that we're seeing more ARM-rela= ted contributions this may be less of an issue as we would have at least on= e ARM SoC rep to consider for membership based on recent contributions. We do still have the difficult topic of membership to agree on. For now tho= ugh, I want to make sure that we have agreement on the scope and purpose of= the board. We can address membership once we've finalized that. Tim > -----Original Message----- > From: O'Driscoll, Tim > Sent: Thursday, October 29, 2015 3:22 PM > To: dev@dpdk.org > Subject: Architecture Board Proposal >=20 > At the recent DPDK Userspace event we agreed that we need a body to make > technical decisions for the project. In Dublin we referred to this as a > Technical Steering Committee, but that term is often used on other > projects to describe a body with a more political charter. To avoid > confusion, and clarify that the scope of this body for DPDK is purely > technical, I propose calling it the DPDK Architecture Board. >=20 > Justification > ------------- > The role of the Maintainer is to be the gate-keeper for the project, and > to only accept contributions that are properly implemented, properly > reviewed, and consistent with the agreed project scope/charter. However, > it shouldn't be the responsibility of the Maintainer to be the final > decision maker (after community discussion) on issues affecting the > strategic direction of the project. Instead, this should be determined > by a higher level body that's representative of the DPDK community. >=20 > Having an Architecture Board will help to provide a clear > direction/strategy for the project, and help to resolve complex issues > which don't reach a consensus on the mailing list in a timely manner. >=20 > Scope > ----- > Issues that are within the scope of the Architecture Board include: > - Project scope/charter. What is and isn't within the scope of the > project? What happens if somebody wants to upstream a new > library/capability and it's not clear whether it fits within DPDK or > not? As a random example, if somebody wanted to upstream a DPDK-enabled > TCP/IP stack to dpdk.org, should that be accepted or rejected? > - Performance vs functionality considerations. If we need to make a > change and there's an unavoidable performance impact to doing so (maybe > something like extending the mbuf again), does that change get accepted > or not? In most cases you can probably work around situations like this > by making them optional, but that might not always be possible. If it's > not, who decides whether performance or functionality is more important? > - Replacing existing functionality versus adding new alternatives. If > there's a new implementation of an existing DPDK capability that > performs better in some use cases but worse in others, does that get > accepted and replace the existing implementation, does it get accepted > as an alternative, or does it get rejected? > - Unresolved issues. Provide a decision on issues that don't reach a > consensus on the mailing list in a timely manner. >=20 > Composition > ----------- > For composition of the Architecture Board, I'd propose the following: > - It needs to be kept to a manageable size. I propose limiting it to 5 > initially (it should be an odd number to minimize deadlocks). > - Membership should be based on: number and quality of contributions, > technical standing in the community, breadth of involvement (involvement > in many areas, not just a single part of DPDK). > - No single company/organization can have more than 2 members. > - The Architecture Board will elect its own chair, who will have the > deciding vote in the event of a deadlock. > - The board will review its own composition and co-opt/approve any new > members on an annual basis. >=20 > There are three main options for determining who is on the board: > 1. Nomination of representatives by contributing companies. We could > allocate a number of positions on the board based on the contributions > from each company and then allow those companies to nominate their > representatives. The downsides are that many companies contribute but > not all can be represented on the board so we'd need a way to decide > which companies get a seat and which don't, and that this focuses the > discussion on company contributions rather than individuals with the > best technical standing > 2. Election of representatives. We could poll for candidates and then > vote. This is likely to take time because we'll need to agree and > implement the process to support an election. > 3. Seed the board with those who have the best technical standing in the > community. We could determine the initial composition by consensus. I > think the prime candidates for an Architecture Board will be obvious to > most of us. >=20 > My preference would be for option 3. Any other opinions or comments on > this proposal? >=20 >=20 > Tim