From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id E807E8E72 for ; Thu, 29 Oct 2015 20:48:57 +0100 (CET) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 0CD66A0E4A; Thu, 29 Oct 2015 19:48:57 +0000 (UTC) Received: from dhcp-41-137.bos.redhat.com (ovpn-113-192.phx2.redhat.com [10.3.113.192]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9TJmuTb012563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Oct 2015 15:48:56 -0400 To: "O'Driscoll, Tim" , "dev@dpdk.org" References: <26FA93C7ED1EAA44AB77D62FBE1D27BA674488A2@IRSMSX108.ger.corp.intel.com> From: Dave Neary X-Enigmail-Draft-Status: N1110 Message-ID: <56327827.1030306@redhat.com> Date: Thu, 29 Oct 2015 15:48:55 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA674488A2@IRSMSX108.ger.corp.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 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: Thu, 29 Oct 2015 19:48:58 -0000 Thanks Tim, Great to see some momentum coming out of DPDK Userspace. 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. 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. > 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? 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. > - 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. 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. 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. > 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? 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? 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. Overall, thanks Tim! I think this is a really solid proposal. Thanks, Dave. -- 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