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 86EC1C35E for ; Fri, 24 Apr 2015 23:03:00 +0200 (CEST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3OL2wDV020669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 24 Apr 2015 17:02:59 -0400 Received: from leitrim.localdomain (ovpn-113-97.phx2.redhat.com [10.3.113.97]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3OL2vht028372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Apr 2015 17:02:58 -0400 Message-ID: <553AAF81.6030900@redhat.com> Date: Fri, 24 Apr 2015 17:02:57 -0400 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" , Stephen Hemminger References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D29B55@IRSMSX102.ger.corp.intel.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D2B50E@IRSMSX102.ger.corp.intel.com> In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D2B50E@IRSMSX102.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Beyond DPDK 2.0 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, 24 Apr 2015 21:03:01 -0000 Hi Tim, On 04/23/2015 07:36 AM, O'Driscoll, Tim wrote: >> Alternatively, propose some options and vote, but I don't think we have things defined >> enough for that yet. > > We tried to keep the initial communication neutral and avoid suggesting solutions to give others a chance to comment. At a very high level, there seem to be 3 possible approaches though: > > 1. Do nothing. The project is increasing in size, and the releases are getting delivered according to the roadmap, so one option is to continue as we are. > > 2. Add a more formal governance structure to dpdk.org. This might involve putting in place a Technical Steering Committee to give long-term technical direction to the project, and to resolve any differences of opinion that don't reach a conclusion on the mailing list. > > 3. Transition the project to an organization such as the Linux Foundation, and use their help to implement a more formal governance structure. This would probably involve a TSC, and possibly also a governing board and the creation of some form of centralized marketing/branding/promotional budget for the project. I see at least one other option, which is to document the process for becoming a maintainer/core reviewer (whatever terminology we choose), and move from a single project lead to multiple committers. This would allow the project to scale, reducing average review time and removing bottlenecks, but would avoid the potential for "design by committee" which a TSC would bring, and also avoid the operational and cost overhead of a formal foundation. This will not address the issue of how the project's scope, priorities and roadmap are defined, but will definitely help with both the scaling of project contributions and the diversity of the project. The MAINTAINERS file: http://dpdk.org/browse/dpdk/tree/MAINTAINERS is an awesome step in the right direction by clearly defining where people maintain a module. Regards, 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