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 EFAD9C320 for ; Wed, 20 May 2015 21:04:03 +0200 (CEST) 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 (8.14.4/8.14.4) with ESMTP id t4KJ42Df011261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 20 May 2015 15:04:02 -0400 Received: from leitrim.localdomain (ovpn-113-124.phx2.redhat.com [10.3.113.124]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4KJ414b006011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 May 2015 15:04:02 -0400 Message-ID: <555CDAA1.7030703@redhat.com> Date: Wed, 20 May 2015 12:04:01 -0700 From: Dave Neary User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "O'Driscoll, Tim" , "dev@dpdk.org" References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D43080@IRSMSX102.ger.corp.intel.com> In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D43080@IRSMSX102.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] 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: Wed, 20 May 2015 19:04:04 -0000 Hi, On 05/14/2015 01:55 PM, O'Driscoll, Tim wrote: > At Tuesday's Beyond DPDK 2.0 call, one topic we discussed was decision making 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 guide the long-term strategic direction of the project. As others have said, I think a TSC can have value, more as the "guardian of the roadmap", a place to engage to set high level goals and priorities for the project. And as Neil and Thomas said, I also agree that it does not make sense for the TSC to get involved in the day-to-day of the project (patch review, for example). There is a danger with TSCs that you end up with "design by committee" - but I think that is a risk that can be mitigated by limiting the scope. In terms of membership: I do think it's important to have the voice of users in the technical community, but I agree with Stephen that the TSC would not be the appropriate forum for that. 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