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 AA2648E8B for ; Fri, 30 Oct 2015 14:11:07 +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 EA056C0B83E0; Fri, 30 Oct 2015 13:11:06 +0000 (UTC) Received: from dhcp-41-137.bos.redhat.com (ovpn-113-28.phx2.redhat.com [10.3.113.28]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9UDB5n6015633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2015 09:11:06 -0400 To: "O'Driscoll, Tim" , "dev@dpdk.org" References: <26FA93C7ED1EAA44AB77D62FBE1D27BA674488A2@IRSMSX108.ger.corp.intel.com> <56327827.1030306@redhat.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA674499B6@IRSMSX108.ger.corp.intel.com> From: Dave Neary Message-ID: <56336C69.5000405@redhat.com> Date: Fri, 30 Oct 2015 09:11:05 -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: <26FA93C7ED1EAA44AB77D62FBE1D27BA674499B6@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: Fri, 30 Oct 2015 13:11:07 -0000 Hi, On 10/30/2015 07:01 AM, O'Driscoll, Tim wrote: >>> 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. > > I think there are two questions here. The first is one that Thomas raised and 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 hosted 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 patches for a DPDK-accelerated IPsec library (librte_ipsec), who would decide whether 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. The issue I see is that if we agree that the architecture board's scope is limited to DPDK only, and the architecture board owns the scope of DPDK, that we still have the open question of which projects are appropriate to be housed under dpdk.org There was a general agreement in Dublin that DPDK related projects and applications could live in dpdk.org, but we didn't really touch on the process or requirements for adding new projects. I think it's appropriate for the architecture board to own those too. 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