From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id BB8AF5A3E for ; Thu, 14 May 2015 22:55:25 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 14 May 2015 13:55:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,431,1427785200"; d="scan'208";a="695042634" Received: from irsmsx109.ger.corp.intel.com ([163.33.3.23]) by orsmga001.jf.intel.com with ESMTP; 14 May 2015 13:55:23 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.36]) by IRSMSX109.ger.corp.intel.com ([169.254.13.51]) with mapi id 14.03.0224.002; Thu, 14 May 2015 21:55:23 +0100 From: "O'Driscoll, Tim" To: "dev@dpdk.org" Thread-Topic: Technical Steering Committee (TSC) Thread-Index: AdCOhfiHYCdsiQY0Tuup0INCIVIARw== Date: Thu, 14 May 2015 20:55:23 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D43080@IRSMSX102.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] Technical Steering Committee (TSC) 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, 14 May 2015 20:55:26 -0000 At Tuesday's Beyond DPDK 2.0 call, one topic we discussed was decision maki= ng and whether we need a Technical Steering Committee (TSC). As a follow-up= to that discussion, I'd like to propose that we create a TSC for DPDK to g= uide the long-term strategic direction of the project. 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 a TSC should help to provide a clear direction/strategy for the proj= ect, and help to resolve complex issues which don't reach a consensus on th= e mailing list in a timely manner. There were arguments at the call that a TSC is not required. The alternativ= e view though is why would we not put one in place? The TSC could review it= s own progress after 6 months, and if the members don't consider it to be p= roductive, then it could be disbanded. I see little effort and zero risk in= trying this, with the potential gain of a clearer decision making process = and a better defined project strategy.=20 Scope -----=20 Issues the TSC should consider should 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. An examp= le of this might be Cuckoo Hash. Does that replace the existing hash implem= entation, or should it be provided as an alternative? Who decides this? Tha= t could be more of an operational issue, but it's borderline. - Competitive Positioning. Monitor the competitive landscape and determine = any impacts to future DPDK strategy.=20 - Unresolved issues. Provide a decision on issues that don't reach a consen= sus on the mailing list in a timely manner. Composition ----------- Composition of the TSC should reflect contributions to the project, but be = balanced so that no single party has an undue influence. It should also be = kept to a manageable size(maybe 7?). The TSC should elect its own chair, who would have the deciding vote in the= event that the TSC was deadlocked. Once in place, the TSC should approve a= ny new members. Specific details on membership can be discussed and agreed later, if we agr= ee on the creation of a TSC.