From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 25ED28E84 for ; Thu, 29 Oct 2015 16:22:06 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 29 Oct 2015 08:21:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,214,1444719600"; d="scan'208";a="590392226" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by FMSMGA003.fm.intel.com with ESMTP; 29 Oct 2015 08:21:49 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.138]) by IRSMSX103.ger.corp.intel.com ([169.254.3.116]) with mapi id 14.03.0248.002; Thu, 29 Oct 2015 15:21:49 +0000 From: "O'Driscoll, Tim" To: "dev@dpdk.org" Thread-Topic: Architecture Board Proposal Thread-Index: AdESXXFZp4hchkInQi2ciOcDI//rHA== Date: Thu, 29 Oct 2015 15:21:48 +0000 Message-ID: <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: [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: Thu, 29 Oct 2015 15:22:06 -0000 At the recent DPDK Userspace event we agreed that we need a body to make te= chnical decisions for the project. In Dublin we referred to this as a Techn= ical Steering Committee, but that term is often used on other projects to d= escribe a body with a more political charter. To avoid confusion, and clar= ify that the scope of this body for DPDK is purely technical, I propose cal= ling 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/strateg= y for the project, and help to resolve complex issues which don't reach a c= onsensus on the mailing list in a timely manner. Scope -----=20 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 so= mebody wanted to upstream a DPDK-enabled TCP/IP stack to dpdk.org, should t= hat 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 mo= st cases you can probably work around situations like this by making them o= ptional, but that might not always be possible. If it's not, who decides wh= ether 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 doe= s it get rejected? - Unresolved issues. Provide a decision on issues that don't reach a consen= sus 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 init= ially (it should be an odd number to minimize deadlocks). - Membership should be based on: number and quality of contributions, techn= ical 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 decidi= ng vote in the event of a deadlock. - The board will review its own composition and co-opt/approve any new memb= ers 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 alloca= te a number of positions on the board based on the contributions from each = company and then allow those companies to nominate their representatives. T= he downsides are that many companies contribute but not all can be represen= ted on the board so we'd need a way to decide which companies get a seat an= d which don't, and that this focuses the discussion on company contribution= s 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 co= mmunity. We could determine the initial composition by consensus. I think t= he 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