From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id E89D98E7A for ; Fri, 11 Dec 2015 10:48:29 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP; 11 Dec 2015 01:48:28 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,412,1444719600"; d="scan'208";a="869455376" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by orsmga002.jf.intel.com with ESMTP; 11 Dec 2015 01:48:28 -0800 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.23]) by IRSMSX107.ger.corp.intel.com ([169.254.10.124]) with mapi id 14.03.0248.002; Fri, 11 Dec 2015 09:47:06 +0000 From: "O'Driscoll, Tim" To: "'dev@dpdk.org'" Thread-Topic: Architecture Board Proposal Thread-Index: AdESXXFZp4hchkInQi2ciOcDI//rHAPyJH9ABHQ+rqA= Date: Fri, 11 Dec 2015 09:47:05 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA6747A128@IRSMSX108.ger.corp.intel.com> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA674488A2@IRSMSX108.ger.corp.intel.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA67464A14@IRSMSX108.ger.corp.intel.com> In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA67464A14@IRSMSX108.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-inteldataclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsIiwiaWQiOiJiMDAxZTk3Yy0yNzM5LTQwMDctOWM2YS00YjYyOGJlOTdkOTMiLCJwcm9wcyI6W3sibiI6IkludGVsRGF0YUNsYXNzaWZpY2F0aW9uIiwidmFscyI6W3sidmFsdWUiOiJDVFBfSUMifV19XX0sIlN1YmplY3RMYWJlbHMiOltdLCJUTUNWZXJzaW9uIjoiMTUuNC4xMC4xOSIsIlRydXN0ZWRMYWJlbEhhc2giOiJCODRGTkxNWkw4ZFZcL1BBRGFKMDdcL1NkUXFzTGFjSDJkOU83MXJ3ZFpGVkU9In0= 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: Fri, 11 Dec 2015 09:48:30 -0000 Since we have agreement on the purpose and scope of the board, I'd like to = make a proposal on the composition. I think the following people all have a= strong history of contributions and technical credibility within the commu= nity, and represent a broad range of perspectives on DPDK: Stephen Hemminge= r, Thomas Monjalon, Olivier Matz, Panu Matilainen, Jerin Jacob, Bruce Richa= rdson, Konstantin Ananyev. I'd propose that this group have an initial meeting early in the new year. = A good topic for a first meeting would be to clarify the scope of DPDK. We = discussed this at the Userspace event (including questions such as whether = an IPsec sample application is or is not within DPDK scope), and Venky agre= ed to draft an initial proposal, but due to other commitments he hasn't had= time to do this yet. If Venky does get time to do this then his draft can = be an input to the board for discussion/approval, otherwise I think the boa= rd members should just determine and document the scope themselves. If anybody has comments on this or alternative proposals, please feel free = to air them on the mailing list. We can also add this to the agenda for our= community call on Wednesday and hopefully finalise it then. Tim > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of O'Driscoll, Tim > Sent: Wednesday, November 18, 2015 5:55 PM > To: 'dev@dpdk.org' > Subject: Re: [dpdk-dev] Architecture Board Proposal >=20 > In order to progress this, I'd like to summarise what's been discussed > on the mailing list so far (both in this thread and in the one Dave > Neary started on governance proposals from the Userspace event) and give > a final chance to people to provide any additional input. The main > things that came up in the discussion were: >=20 > - 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. >=20 > - It was reiterated that the board should only make decisions when a > consensus isn't reached on the mailing this. This should not happen > often, so the workload should be light. >=20 > - Membership needs to be based on contributions. There were requests for > ARM 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-related contributions this may be less of an issue as we > would have at least one ARM SoC rep to consider for membership based on > recent contributions. >=20 > We do still have the difficult topic of membership to agree on. For now > though, 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. >=20 >=20 > Tim >=20 > > -----Original Message----- > > From: O'Driscoll, Tim > > Sent: Thursday, October 29, 2015 3:22 PM > > To: dev@dpdk.org > > Subject: Architecture Board Proposal > > > > 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. > > > > 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. > > > > 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. > > > > 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. > > > > 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. > > > > 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. > > > > My preference would be for option 3. Any other opinions or comments on > > this proposal? > > > > > > Tim