From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40052.outbound.protection.outlook.com [40.107.4.52]) by dpdk.org (Postfix) with ESMTP id D2AF35921 for ; Mon, 31 Oct 2016 16:20:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Gu/Eewn4ibf7/bft3dNa5p2Sz+FLMbzCBRaquf7itRI=; b=IPmJsI1OCfuStFheu2R9NnuqfNxuiiJLJbUf1LbhYBB8W3AqNI9Fi/2PKK/zYWhsNKdRo5ipuYxhIxMvAlVq4t1NkCVI63BscdV/aXW1uDWP0/IenFwmSjqw0IBZNsQb2xXvNm+PA4zL0yPBF3Km0kk2VvIIhhrZw2k46akV8aw= Received: from AM5PR0801MB2051.eurprd08.prod.outlook.com (10.168.158.141) by AM5PR0801MB2052.eurprd08.prod.outlook.com (10.168.158.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.12; Mon, 31 Oct 2016 15:20:32 +0000 Received: from AM5PR0801MB2051.eurprd08.prod.outlook.com ([10.168.158.141]) by AM5PR0801MB2051.eurprd08.prod.outlook.com ([10.168.158.141]) with mapi id 15.01.0669.024; Mon, 31 Oct 2016 15:20:32 +0000 From: Matt Spencer To: Vincent Jardin , Thomas Monjalon , "moving@dpdk.org" Thread-Topic: [dpdk-moving] description of technical governance Thread-Index: AQHSLsgejSOr3VBxk0mkwdhTbAlIkaC6h/qAgAMRp4CAAHQFjoAANhSAgAA7HYCABDamPw== Date: Mon, 31 Oct 2016 15:20:31 +0000 Message-ID: References: <26FA93C7ED1EAA44AB77D62FBE1D27BA676091C7@IRSMSX108.ger.corp.intel.com> <2677739.KbWyRmNgFH@xps13>, <1580d802a08.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com> In-Reply-To: <1580d802a08.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Matt.Spencer@arm.com; x-originating-ip: [25.160.228.132] x-ms-office365-filtering-correlation-id: d4c7c0ca-1aef-4c35-737e-08d401a1746d x-microsoft-exchange-diagnostics: 1; AM5PR0801MB2052; 7:dVpLVygFIRE1b/EZ8IuzkQMIHDIjcPRPbvyo9TXDq0F9Y4l40C0LR8ilvVwuK9csptVBzBZPJCFxlpja4SwpumAj87tGWZMBFb2UtYMRVKt0Ms+chmSD/yHYYiGu8ylaG4Krbv4T48yC/jiZA75nmhs5tTHDoZPdyGHzFLGwZOoloyc0949zLaD/B/m9oDNTz8zjJNuglsGCJ0xRC4yAE5pklOz3BpPwDeUuMmU0i6Bw+byIs8PppAuZMbmtlGQZslwKT+VVkOct56Vb+5qMfEKSqLYI5zyGYCzIpHtJo2x7SEZfUO9D4OzaCywBvwY7bEsY+M2XLx1oLEWR1m4hQUPoq+E+y+SQgQMfeREHoOo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0801MB2052; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:AM5PR0801MB2052; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0801MB2052; x-forefront-prvs: 01128BA907 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(7916002)(40434004)(54014002)(377454003)(189002)(51914003)(377424004)(199003)(86362001)(11100500001)(5002640100001)(10400500002)(101416001)(54356999)(76176999)(92566002)(50986999)(74316002)(586003)(102836003)(3846002)(16236675004)(6116002)(2900100001)(106356001)(81156014)(2906002)(8676002)(7846002)(5890100001)(93886004)(81166006)(7736002)(33656002)(2501003)(66066001)(7696004)(5001770100001)(97736004)(19625215002)(4001150100001)(3280700002)(3660700001)(122556002)(107886002)(68736007)(2950100002)(189998001)(76576001)(87936001)(19580405001)(105586002)(8936002)(106116001)(5660300001)(19580395003)(77096005)(9686002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0801MB2052; H:AM5PR0801MB2051.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0801MB20517D17BFC3DDB2D9E1132A95AE0AM5PR0801MB2051_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2016 15:20:31.8172 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB2052 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: Mon, 31 Oct 2016 15:20:33 -0000 --_000_AM5PR0801MB20517D17BFC3DDB2D9E1132A95AE0AM5PR0801MB2051_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the responses. I'm really looking forward to the debate later t= oday! One point I would raise, and it is one that Thomas picked up on a bit. I d= on't think we can have a pure meritocracy /and/ expect some of the membersh= ip to pay to support the project management. I am going to have a very har= d time explaining to my exec why we should be spending $$$ on DPDK when the= re is no clear benefit to membership. Comparisons have ben made to the OVS project, which is fine, but OVS does n= ot have any membership costs (as far as I can see) and LF host this project= for free. I don't think we can have both of these positions hold true. We either hav= e 1 - a pure meritocracy - ie the governance does not change and I believe w= e are in the same position as we are today 2 - Something a bit more like FD.io, with paid membership and paid access = to a board/TSC Regards Matt ________________________________ From: Vincent Jardin Sent: 28 October 2016 23:54:13 To: Thomas Monjalon; moving@dpdk.org; Matt Spencer Subject: Re: [dpdk-moving] description of technical governance Le 28 octobre 2016 9:22:43 PM Thomas Monjalon a =E9crit : > 2016-10-28 16:52, Matt Spencer: >> 1 - we adopt the model as is - one TSC member per committer >> As this stands today, that would give us 56 TSC members, >> with almost half of them from one company >> >> 2 - we adopt the model as is - one TSC member per committer - >> to a maximum of 20% membership of the TSC >> This would ensure that no one company can 'own' the TSC - >> 56 committers, so max TSC membership from one company would be 11 >> >> 3 - Maximum one member of TSC per committing company, >> plus one TSC assignee per paid member >> This would keep the TSC to a manageable level, give companies >> an incentive to join, but not require membership to be on the TSC >> >> 4 - Something else? >> >> My current thoughts are with 3 because we should end up with a >> representative cross section of the stakeholders of the project, >> whilst still incentivising membership of the foundation. > > Thanks for sharing your view. > > I'm an Open Source guy and I might lack some politician skills. > So please excuse me if I take the freedom to talk really frankly :) > > First of all, this email thread was dedicated to the technical governance= . > And Matt is introducing money in this topic by talking about incentives. > I think it is a very interesting point that we must discuss. > From the beginning, everybody were saying that we must keep technical > governance and legal structure separate. > However one question has still no good answer: what is the incentive > for contributing money in the structure? > Is money going to biase the desired meritocratic system? > > My second comment is about having one company controlling the technical > governance. > I won't enter into the number details, and it's true that Intel provides > at least 50% of the contributions nowadays. Intel is also the biggest > contributor to Linux. No surprise. > I understand that a voice from ARM is requiring to mitigate this fact. > I would prefer ARM related companies working to achieve the same > level of commitment as Intel. They are increasing their contribution pace > but may never really compete with a giant like Intel. > That's why I second Matt to say that we must give a chance to every > vendors to influence the technical decisions. > Introducing a membership threshold looks to be a good idea. > > Having said that, I must state that the DPDK reality is a lot more > complex than a competition between vendors. > We are proving that a consensus based model works very well without > the need of a TSC or a board. > We can create such organization, but please keep in mind that it should > not be really helpful in the day-to-day job. +2 From contributions, meritocracy is applied. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM5PR0801MB20517D17BFC3DDB2D9E1132A95AE0AM5PR0801MB2051_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks for the responses.  I'm really looking forward to the debate= later today!


One point I would raise, and it is one that Thomas picked up on a bit. &= nbsp;I don't think we can have a pure meritocracy /and/ expect some of the = membership to pay to support the project management.  I am going to ha= ve a very hard time explaining to my exec why we should be spending $$$ on DPDK when there is no clear benefit to me= mbership.


Comparisons have ben made to the OVS project, which is fine, but OVS doe= s not have any membership costs (as far as I can see) and LF host this proj= ect for free.


I don't think we can have both of these positions hold true.  We ei= ther have

 1 - a pure meritocracy - ie the governance does not chan= ge and I believe we are in the same position as we are today

 2 - Something a bit more like FD.io, with paid membership and paid= access to a board/TSC


Regards


Matt

From: Vincent Jardin <= vincent.jardin@6wind.com>
Sent: 28 October 2016 23:54:13
To: Thomas Monjalon; moving@dpdk.org; Matt Spencer
Subject: Re: [dpdk-moving] description of technical governance
 


Le 28 octobre 2016 9:22:43 PM Thomas Monjalon <thomas.monjalon@6wind.com= > a
=E9crit :

> 2016-10-28 16:52, Matt Spencer:
>> 1 - we adopt the model as is - one TSC member per committer
>> As this stands today, that would give us 56 TSC members,
>> with almost half of them from one company
>>
>> 2 - we adopt the model as is - one TSC member per committer -
>> to a maximum of 20% membership of the TSC
>> This would ensure that no one company can 'own' the TSC -
>> 56 committers, so max TSC membership from one company would be 11<= br> >>
>> 3 - Maximum one member of TSC per committing company,
>> plus one TSC assignee per paid member
>> This would keep the TSC to a manageable level, give companies
>> an incentive to join, but not require membership to be on the TSC<= br> >>
>> 4 - Something else?
>>
>> My current thoughts are with 3 because we should end up with a
>> representative cross section of the stakeholders of the project, >> whilst still incentivising membership of the foundation.
>
> Thanks for sharing your view.
>
> I'm an Open Source guy and I might lack some politician skills.
> So please excuse me if I take the freedom to talk really frankly :) >
> First of all, this email thread was dedicated to the technical governa= nce.
> And Matt is introducing money in this topic by talking about incentive= s.
> I think it is a very interesting point that we must discuss.
> From the beginning, everybody were saying that we must keep technical<= br> > governance and legal structure separate.
> However one question has still no good answer: what is the incentive > for contributing money in the structure?
> Is money going to biase the desired meritocratic system?
>
> My second comment is about having one company controlling the technica= l
> governance.
> I won't enter into the number details, and it's true that Intel provid= es
> at least 50% of the contributions nowadays. Intel is also the biggest<= br> > contributor to Linux. No surprise.
> I understand that a voice from ARM is requiring to mitigate this fact.=
> I would prefer ARM related companies working to achieve the same
> level of commitment as Intel. They are increasing their contribution p= ace
> but may never really compete with a giant like Intel.
> That's why I second Matt to say that we must give a chance to every > vendors to influence the technical decisions.
> Introducing a membership threshold looks to be a good idea.
>
> Having said that, I must state that the DPDK reality is a lot more
> complex than a competition between vendors.
> We are proving that a consensus based model works very well without > the need of a TSC or a board.
> We can create such organization, but please keep in mind that it shoul= d
> not be really helpful in the day-to-day job.

+2

 From contributions, meritocracy is applied.


IMPORTANT NOTICE: The contents of this email and any attachme= nts are confidential and may also be privileged. If you are not the intende= d recipient, please notify the sender immediately and do not disclose the c= ontents to any other person, use it for any purpose, or store or copy the information in any medium. Thank = you. --_000_AM5PR0801MB20517D17BFC3DDB2D9E1132A95AE0AM5PR0801MB2051_--