From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 2654036E for ; Tue, 29 Nov 2016 11:58:20 +0100 (CET) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP; 29 Nov 2016 02:58:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,568,1473145200"; d="scan'208";a="36709234" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga005.jf.intel.com with ESMTP; 29 Nov 2016 02:58:19 -0800 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.145]) by IRSMSX104.ger.corp.intel.com ([169.254.5.52]) with mapi id 14.03.0248.002; Tue, 29 Nov 2016 10:58:18 +0000 From: "O'Driscoll, Tim" To: "moving@dpdk.org" Thread-Topic: Today's Meeting Thread-Index: AdJKLvFbIHK4ZZN2TE2BJwGdoy7IfQ== Date: Tue, 29 Nov 2016 10:58:17 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA67625C3C@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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTNhMDBhMmQtNmNhOS00YjgzLWI2MDYtZTFkZGQ2YjNmNWRhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjIuMTEuMCIsIlRydXN0ZWRMYWJlbEhhc2giOiJVXC9XT05OT1F0Ym9TUjRZRjFTdkwxVVlVdzF0WmczWEhka09cL0tjaU5RZjQ9In0= x-ctpclassification: CTP_IC 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-moving] Today's Meeting 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: Tue, 29 Nov 2016 10:58:21 -0000 We talked at the end of last week's meeting about how we can make this proc= ess go faster. We said we'd try to focus on existing comments on the doc ra= ther than bringing up new issues. Below are the outstanding comments on the= doc that I think we need to discuss. We won't get through them all today, = but focusing on specific issues might help us make faster progress. Also, just a reminder that today's meeting is at 3pm GMT, 4pm CET, 10am EST= , 7am PST. Access numbers are: France: +33 1588 77298 UK: +44 179340 2663 USA: +1 916 356 2663=09 Bridge Number: 5 Conference ID: 94641018 Link to Skype meeting: https://meet.intel.com/tim.odriscoll/G7H113HY - For Section 2 (Project Scope), Mike Dolan suggested removing info that ca= n be maintained elsewhere and is likely to change. I've shortened this sect= ion so that it just defines scope at a high level and then references the w= ebsite for details like specific git repos. The intent is just to clarify t= hat we have one core project (DPDK), plus a few smaller sub-projects that a= re closely related to DPDK. I'm assuming nobody has any concerns with this. - On the Governing Board scope (section 3.1.1), Matt still has a comment on= the need for the GB to be able to define business requirements such as the= need for an LTS release. We've discussed this a couple of times before but= never reached a clear conclusion on it. We should conclude on this at tomo= rrow's meeting. - On the GB composition (section 3.1.2), there have been a couple of commen= ts at previous meetings and on the mailing list (most recently from Dave) o= n the need for technical representation. At the moment, this section just s= ays that there's a rep from the Tech Board on the GB. We need to agree if t= his is sufficient or if we need additional technical members. Similarly, we= need to agree whether there's any non-technical representation on the TB (= section 3.2.2). - For voting, I think we should be consistent between the two boards in ter= ms of the quorum required for a meeting to proceed and the majority require= d for a vote. We should also discuss whether there are specific decisions w= here a higher than 50% majority from the TB/GB is required. Having a higher= bar to pass a vote increases stability, but it also preserves the status q= uo and slows the rate of change. This applies to sections 3.1.3 and 3.2.3. - We need to agree how people are added to/removed from the TB (section 3.2= .2). How are people proposed? What are the criteria for accepting them? Is = the board a fixed size or could it expand over time? What's the maximum rep= resentation from any single company? - For Membership (section 4) we need to agree whether membership relates to= the project or just to the GB. There are a couple of comments in the doc f= rom Vincent, and Thomas has raised the same issue on the mailing list as we= ll, saying that membership only applies to the GB. I'd viewed this differen= tly, that people became members of the project and that one of the benefits= is representation on the GB. We need to conclude on this. - A related issue that we need to conclude on is whether we need a Contribu= tor membership level as Matt has proposed (related to the CLA/DCO item belo= w). - For CI, good progress has been made on putting in place a distributed sol= ution as we discussed previously. We do need to progress the discussion on = a centralized performance lab. I think for the charter we just need to agre= e at a high level and resolve Matt and Jaswinder's comments. We can discuss= the details (what tests, what hardware etc.) in a separate meeting. - For Technical Governance (section 5), we need to agree how much of this s= hould be in the charter and how much should be maintained in the Contributo= r's Guidelines and/or DPDK.org Development page. I put some proposed text i= n the doc which links to the other docs that cover this. If we agree that's= the right approach then we don't need to discuss further. If we want more = detail in this doc, then Thomas has proposed some initial text and Keith an= d others have commented on this. - Where is the technical governance for apps that are not part of the DPDK = project documented? These are small, but it should still be captured somewh= ere. - For the IP Policy, the main question which has come up several times on t= he mailing list is whether we need a CLA or if the DCO is sufficient. - At the moment, this section says that everything is BSD licensed. That's = not strictly true as some small parts of DPDK use GPL or dual BSD/GPL. We n= eed to capture those existing exceptions somewhere, either in this doc or i= n another location that we can link to. - For Amendments, I think it was Dave who asked if changes to this doc shou= ld require approval from both the GB and the TB.