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 795BA374E for ; Fri, 30 Oct 2015 12:01:11 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 30 Oct 2015 04:01:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,217,1444719600"; d="scan'208";a="590950609" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by FMSMGA003.fm.intel.com with ESMTP; 30 Oct 2015 04:01:10 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.138]) by IRSMSX101.ger.corp.intel.com ([169.254.1.33]) with mapi id 14.03.0248.002; Fri, 30 Oct 2015 11:01:09 +0000 From: "O'Driscoll, Tim" To: Dave Neary , "dev@dpdk.org" Thread-Topic: [dpdk-dev] Architecture Board Proposal Thread-Index: AdESXXFZp4hchkInQi2ciOcDI//rHAAJWayAAB9PXNA= Date: Fri, 30 Oct 2015 11:01:08 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA674499B6@IRSMSX108.ger.corp.intel.com> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA674488A2@IRSMSX108.ger.corp.intel.com> <56327827.1030306@redhat.com> In-Reply-To: <56327827.1030306@redhat.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: Fri, 30 Oct 2015 11:01:12 -0000 > -----Original Message----- > From: Dave Neary [mailto:dneary@redhat.com] > Sent: Thursday, October 29, 2015 7:49 PM > To: O'Driscoll, Tim; dev@dpdk.org > Subject: Re: [dpdk-dev] Architecture Board Proposal >=20 > Thanks Tim, >=20 > Great to see some momentum coming out of DPDK Userspace. >=20 > On 10/29/2015 11:21 AM, O'Driscoll, Tim wrote: > > 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 > Speaking personally, I don't mind what we call it once there is an > agreed scope, membership process, and decision making process. > Architecture Board seems OK to me. >=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. > > > > 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? >=20 > I agree with Thomas here that this seems like it would be a separate > project under dpdk.org, rather than part of DPDK - I think it's OK for > the Architecture Board to own the scope of "projects on dpdk.org" rather > than just DPDK. I think there are two questions here. The first is one that Thomas raised a= nd you've also touched on: Is the scope of the Architecture Board just DPDK= (i.e. everything in http://dpdk.org/browse/dpdk/), or is it everything hos= ted on dpdk.org (list at: http://dpdk.org/browse/). My original intent was = just DPDK, but I'm fine with either option. The second question is who decides whether something is within the scope of= DPDK or not? A TCP/IP stack was just an example. If I were to submit patch= es for a DPDK-accelerated IPsec library (librte_ipsec), who would decide wh= ether that's OK or if it needs to reside somewhere else outside of the DPDK= ? I think that managing the scope of the project should be one of the roles= of the Architecture Board. > > - 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 > In general I would summarise these as "act as a decision making body > when there is a difficulty converging to a decision in the community". > That includes competing technology, priorities and in general > non-converging discussions. >=20 > I think it's important to say that this body kicks in after a decision > has not converged, it is not (apart from project scope considerations, > wich will not evolve very often) a leading body, rather, it's a "last > resort" providing clarity when the community does not generate a > consensus. Exactly. > > 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? >=20 > I like co-option in this case, but I would like to have some kind of > criteria for how board removals can happen - that might be a detail, but > it's important that the architect board continue to represent the most > influential participants in the community, and I could imagine a > scenario where someone named to the board moves to a different position > and over the course of 6-12 months is less active in the project - would > they be expected to nominate a successor? Withdraw and alow others to > nominate? If they don't volunteer to withdraw, what criteria can the > board use to request that they withdrawal? That's a good point. I do think the board needs to review its own compositi= on on an annual basis to make sure that existing members still meet the cri= teria and to identify/co-opt new members. The expectation would be that peo= ple who are no longer actively involved would withdraw themselves in good f= aith, but if that didn't happen then the board would need to propose their = removal and vote on it. > One thing I think is important is that seats are not considered "owned" > by a company. There isn't a 6WIND seat or an Intel seat - seats are held > by individuals representing the interests of the technical community, > not companies invested in the project. In general, though, I think 2 > seats per company may is a good number, I would not want to have even > the perception of a majority voting block by one company. Agreed. This is why I strongly prefer option 3 where we pick the best indiv= iduals based on technical merit rather than option 1 where companies nomina= te. > Overall, thanks Tim! I think this is a really solid proposal. >=20 > Thanks, > Dave. >=20 > -- > Dave Neary - NFV/SDN Community Strategy > Open Source and Standards, Red Hat - http://community.redhat.com > Ph: +1-978-399-2182 / Cell: +1-978-799-3338