From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 2B5A6F72 for ; Fri, 28 Oct 2016 11:13:54 +0200 (CEST) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga105.fm.intel.com with ESMTP; 28 Oct 2016 02:13:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,557,1473145200"; d="scan'208";a="24749315" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by fmsmga005.fm.intel.com with ESMTP; 28 Oct 2016 02:13:52 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.210]) by irsmsx105.ger.corp.intel.com ([169.254.7.177]) with mapi id 14.03.0248.002; Fri, 28 Oct 2016 10:13:51 +0100 From: "O'Driscoll, Tim" To: "O'Driscoll, Tim" , Thomas Monjalon , "moving@dpdk.org" Thread-Topic: [dpdk-moving] description of technical governance Thread-Index: AQHSLsgspqsrwFQmYEaV+coOh/7zraC6hH4wgAMTGjA= Date: Fri, 28 Oct 2016 09:13:51 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA676091C7@IRSMSX108.ger.corp.intel.com> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA676071BB@IRSMSX108.ger.corp.intel.com> <4939831.0LCNYxqha0@xps13> <26FA93C7ED1EAA44AB77D62FBE1D27BA67607DDE@IRSMSX108.ger.corp.intel.com> In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA67607DDE@IRSMSX108.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiN2I4YzM3NTQtNGU1Zi00YTE3LWEyZmEtNmM4MjNlY2IzMjU0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IklxcUVyWW1KQ0lCc1haeXFUcDJYWGRGakZFRnJaanNab2ZcL01HZmM4U3lJPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-moving] description of technical governance X-BeenThere: moving@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK community structure changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 09:13:54 -0000 > -----Original Message----- > From: moving [mailto:moving-bounces@dpdk.org] On Behalf Of O'Driscoll, > Tim > Sent: Wednesday, October 26, 2016 11:22 AM > To: Thomas Monjalon ; moving@dpdk.org > Subject: Re: [dpdk-moving] description of technical governance >=20 >=20 > > -----Original Message----- > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > Sent: Tuesday, October 25, 2016 3:00 PM > > To: moving@dpdk.org > > Cc: O'Driscoll, Tim > > Subject: Re: [dpdk-moving] description of technical governance > > > > 2016-10-25 11:27, O'Driscoll, Tim: > > > We also have a gap in terms of documenting technical governance. > > > Even ignoring the move to LF, Matt in particular was looking for > > > more clarity on this. > > > Thomas: would you be willing to create and post a proposal on this? > > > > The technical governance is consensus-based. > > The board was built in case a consensus is not found. > > > > There are several projects with their own git trees. > > DPDK and the web site are two of them. > > > > The DPDK project is organized around some git subtrees > > and the mainline gathers every contributions accepted in the subtrees. > > The component maintainers are quality responsibles for the code and > > the git history. They coordinate how improvements and fixes are done. > > The git tree committers are responsibles of the pace, giving time for > > reviews and tests while releasing in time. They also do the last > checks > > or call for help when there is no progress on a patch. > > > > Is it the kind of information you are looking for? > > I think the technical governance must be described on the web site > > in the "development" page. > > It is already partly described but it may requires more details and > > updates. >=20 > Yes, it's the additional detail that I was asking about. If you look at > what we have at the moment (http://dpdk.org/dev), it's quite brief. > Other projects typically have more detail, for example: > - FD.io Technical Community Charter: https://fd.io/governance/technical- > community-charter > - OvS technical governance including committer responsibilities and > process for adding and removing committers: > http://openvswitch.github.io/contributors/ > - ODL TSC Charter: https://www.opendaylight.org/tsc-charter >=20 > We don't necessarily need as much detail as they have, but I think we do > need a bit more than we have at the moment. From a brief discussion with > Mike Dolan during our previous engagement with the LF earlier in the > year, the LF would simply be looking for DPDK technical governance to be > properly documented, and for it to be meritocratic (e.g. committers > chosen based on history of contributions rather than the company they > work for). >=20 > Matt also had some thoughts during our discussion in Dublin on things > he'd like to see added to the technical governance. Perhaps he can > comment further on what he'd like to see. >=20 > In terms of where this is documented, I don't think that matters, and > adding some additional detail to the existing Development page seems > like a good solution to me. I haven't seen anybody else comment on aspects of the technical governance = that should be clarified, so here are a few comments/questions from me that= might help to prompt some discussion. We have a few different types of maintainers: 1) those responsible for revi= ewing changes in individual libraries who are identified in the MAINTAINERS= file; 2) sub-tree maintainers who submit pull requests to the main tree; 3= ) stable release maintainer; 4) main tree maintainer; 5) maintainers for ot= her projects hosted on dpdk.org (pktgen, spp etc.). We should document the = responsibilities of each of these, and the process for adding and removing = them. At the moment, the MAINTAINERS file doesn't identify the sub-tree maintaine= rs or the stable release maintainer. I think they should be included. At the moment, other projects hosted on dpdk.org (pktgen, spp etc.) don't h= ave a MAINTAINERS file. I think this should be mandatory for all sub-projec= ts within DPDK. Should every repo have more than one person with commit rights so that we'r= e not dependent on a single person? They would obviously have to coordinate= on who does what, which could involve sharing the workload or operating on= an active/backup basis. We should document how members of the Tech Board get added/removed. We shou= ld also clarify the scope. Is the scope of the Tech Board just DPDK itself = (http://dpdk.org/browse/dpdk/tree/), or does it also cover the other projec= ts hosted on dpdk.org (http://dpdk.org/browse/)? If it's just DPDK, then wh= o provides the technical oversight for the other projects? My preference wo= uld be for the existing board to cover all sub-projects. We should document the process for adding a new sub-project like pktgen or = SPP. At the moment I think it's proposed on the dev mailing list and added = if there's a consensus. Should it be mandatory that new project proposals a= re reviewed and approved by the Tech Board, to make sure there's consistenc= y and nothing gets missed in a flood of email?