From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0079.outbound.protection.outlook.com [104.47.32.79]) by dpdk.org (Postfix) with ESMTP id 897B4559A for ; Wed, 16 Nov 2016 20:43:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Iq4Uc6IxpBXt400XDxDpr+nXp9G+1m7vLuKEvD0G0Ps=; b=cE0EfFAqPNpSsvshSioImORCpzZPZtj696mM5t8TFOwG9upTlbLUNZBG6c3/k+JdL4dYX2t6LDoAH/inpVA5J17AQF5nm/P8i9JZNR2dIxtU0gbKWcsT7dN/14F4MHU/9rAzwiNKis+Z02Tvlgmjt3hzUqvDNfDC4UQRUb+Kanw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@cavium.com; Received: from svelivela-lt.caveonetworks.com (50.233.148.156) by BY1PR0701MB1722.namprd07.prod.outlook.com (10.162.111.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Wed, 16 Nov 2016 19:42:56 +0000 Date: Thu, 17 Nov 2016 01:12:52 +0530 From: Jerin Jacob To: Bruce Richardson CC: Thomas Monjalon , "Mcnamara, John" , "moving@dpdk.org" , "Yigit, Ferruh" , "yuanhan.liu@linux.intel.com" , "De Lara Guarch, Pablo" Message-ID: <20161116194251.GA7874@svelivela-lt.caveonetworks.com> References: <1660077.mdFWPiNUk9@xps13> <20161116151348.GA31872@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20161116151348.GA31872@bricha3-MOBL3.ger.corp.intel.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Originating-IP: [50.233.148.156] X-ClientProxiedBy: CO2PR18CA0014.namprd18.prod.outlook.com (10.161.80.24) To BY1PR0701MB1722.namprd07.prod.outlook.com (10.162.111.141) X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 2:s2yG465jCRFQz93VzBCVlww/g3busyayw/4XfWZJtx46ZG1PmfrQkCchr3RkucWojeGTXEm1B6DT74yXQKL48Ciy/l2tfh00o3Xb8C9wZaXAagSIpTN9bJyntYXF9C4bdz3IQ5gz0ch+WS9+ba/Fs2P+ZyD78flHbBkcFXj+K48=; 3:12ipvmmDGvAXg8NB+EHvIZDle8kEZAn9OwaLoUdQ4+3pZ66DUoHJLURWugCuvtUfXFpX8ZOXPetmefuq6FG2iQxbSQygDlhq1FKxZbaqvOQh0NGRYZOF2yTFk5OIqZoPlHiBhMEtCmHvLWhEvlWxVX+xbcp4I7Tf1kEVS2wAH8s=; 25:VvfXoQYND5M57LoeWvXQn/tW9ELw7DpKtYpSFKwbEQGqq+CrlOSJztKs1uMeiYUAavdSNwz4jAoQCNrD1iVfNxiqHS27z88ZcKmQwiR9U+6U9q1YR7sNLQxfVfxr0KA8xSr5MYaalF8WNaJb49L4aaX1G7tvm2ql54lRXWpLduc07yvmVs0Nx6jE8AXrGWWugVAALAn2gO+7MfWIl0hbrlbnS825SCPHkm07uAt5MPuAhf9eX9m4QUexNDSZ0vHH+8U78XRA3Vn6Z+hBJrvSANmvRZX77KO+0IeNLJ5z8+fHaHxQBenVVUPBgUxCCR0V3v3p880ctz1KA0ift3nASOFxvMsea/wXHYClamr9JXCRYgISXpQpKS2f8Fv3y0sKEqy0CKi0cYW+rYU6S3dKPcdtxp2ft2NyEPikD4KxgZ1Q98KM1TVxtPMYRe0JEBA1QuV3+/2AMQeWTEWyNBtLfg== X-MS-Office365-Filtering-Correlation-Id: d64a2fd3-f5a9-4771-5ebe-08d40e58c3d6 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BY1PR0701MB1722; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 31:iCa7/Oxhsja5D8vo3sefT8lK5P/Vl709YLlCgJyaKEh1fa2hqCYFDJ92iMHTWxBvQe7f9WfnJRgj+cDKSeX/YeXUbk9OpR/qvXna38ySphFfhogF6wb2ENo3AKuEA3F2B6Ac4GnTXbkigmJ9mT8rQfNF549PcNa6Ikxbz8tOmxFGZRlKxTMzNflv0yXMz2tTEm4vZr6/AiA1zigLp4T0OsHYWkxH/+IKn1Ppryn1pCEBjJR94w2C6YRGqH+rwqcaTlp9auNQLiN3g8tr1gxLrA==; 20:VJSDpEPu44/UunoAAAHLrvRuQwyLZwwzxmwOExdcZ2PCoavbRAT93P6uR0u/2t2MqxIaCsXILGh+Y9DTODpGMXiOA3acFyyubAJTH4vR9jP8Lf3xDo6WvcGBnhgMZVF60S3bsXe8DVwYo0SteqHacg4hiDWjJqi3G1d5tbiFK1mjeZxWjA6Ig/bCMaj6bzw1LYPu3/nMcmj0vzQbMz1HoYS/LwXhHBMYapD4iN8J7w8b357A9dpQanJXY3YocUNak/byNkCrgztda6Js9s5U4pi4recfG5dVYANlv9LHVT9naVkSQVEf1V/MyDfYhiiowSS0BMSchPBg+z4PBJH/7xjH+oKond0GrCXqKYfvCRV6Fbe/W+48IyBXhRpYQraS1nO4VCTbpNiWUUgBx3++UEmDhr+CGYCAifEd/ECECvr8u0TnbAyjm+qD1Xvbr7kfY6NpEvXIFRylf9pujya5v2IS45lwGUIFaTuxzhR4GGG/U3ahpYP1OvjXpGtAwWj9p8Oa77eo9JFossYpaJU02igX32jaP6EA+6ZqkDhoX9J4QEtGysGdNsYGMViPKCVprnMycUXhj6xbcYbXeTszSEEPj+JNBbCDFn58ugmYY6s= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(6040281)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041223)(6061324); SRVR:BY1PR0701MB1722; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0701MB1722; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 4:cfw6yHjpkZAwneWUQ5NXDsgn7PZB8A1x+wSt2TH+mvgsuCg6ozMMDUW87NjEzal1CMXItnkYM/26heXwFmb5bMDjg1PPYNsp0Ldy219h8uUmrIBFYTGe9/eiZ8xAgKsd8lMgDR0ZFdyewk9L59wrlu85lHLa2Tz3FQtXwFK32G5SkMN5UX/MynZoOrKLKTwR0K9tyAYgoMgHdcLfa4ujdVX+/+fHWAlwf3O/8dpzkYIm2XuwgaSF/OQPeR3IhLjFp3F56daDT9gY8I1m29t+U96fiqF2YCNeSUyFxvcv65lOg/TVuXZoA4otI+3lhP2sOO9gUjqMQ39jz9oLqmQxjYj3Qo7r2IibhXtDyC7yHVZHDl5dGpSSRLlnxX/iJDAV0sxSc0DaWNDuwWBj8ny3LjEPx68p3rd+u8AqiEPG/+Q70ppJXMEQN5efN5wdFVRMdHW5gpvhswluNJKDU22pwVqvNJS5ZCfXeptwqagPD2uEzhNG8Dv583e4dsDhxYBD X-Forefront-PRVS: 01283822F8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(7916002)(377424004)(24454002)(43544003)(189002)(199003)(1076002)(97736004)(3846002)(46406003)(83506001)(305945005)(8676002)(105586002)(23726003)(189998001)(47776003)(229853002)(4001350100001)(68736007)(110136003)(77096005)(69596002)(9686002)(6116002)(97756001)(50986999)(92566002)(2950100002)(101416001)(54356999)(42882006)(4326007)(2906002)(6916009)(4001150100001)(81166006)(66066001)(42186005)(7736002)(7846002)(81156014)(53416004)(5660300001)(33656002)(50466002)(106356001)(76176999)(6666003)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0701MB1722; H:svelivela-lt.caveonetworks.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0701MB1722; 23:oXzYC40nStkg1K0bxQvMYngeZI8C41jhOHf31B3?= =?us-ascii?Q?AOKsLEjThFHefPWc87yVLa7N9IkbCFqhuBIq8nhWVI7ucCRRLCf03MyksIOV?= =?us-ascii?Q?kFWjf4k1dpji4f+4gP3XV9GIsXNMhie0FTh42zQc08iOzIyCBaPUCxswhuPv?= =?us-ascii?Q?Nj504DLVADRt6wzx3eipOVGNPxECxzrrgOh9xFjD85Gu+k47x01HekyUMQdA?= =?us-ascii?Q?AvE1Rxn14UOxkGi0ciebLvngwO5arS/g74eP2DH339i26tTNolSHU+ewizX7?= =?us-ascii?Q?H4lTmHpOWqSemfDXX6Tbkxe6ErnviB2VLiCl+SI3E5rYNktG7+G4ju+84Zd4?= =?us-ascii?Q?P0KXOvKFM3oMBrpnZ3ynOX0SoiPBF1PFIHaxQo8hNSxTRCV7NIdan3RoZCum?= =?us-ascii?Q?lRA+uQ6GgOg8zlabCYyP+oO2Fp0TvjpATrpi2oPPl6PZEIJRmGgTJ6p4JY0Y?= =?us-ascii?Q?4+g3YU9dDeYDOAIA3xEtFyppn+w4a6Mwmlto5aS0kB0mpSEjOXixBY9Unsxm?= =?us-ascii?Q?QCn73WQEys+c5Xm7oE+r9BveVZq2VaL8YxlKotnCcc3662tfk/+kScBDjgJ0?= =?us-ascii?Q?nmEIRdubCyDrjaU1IgML9+qjW5I0XhOsB+mUwJgLItnxb/BgaOYe5aJKxSex?= =?us-ascii?Q?cNTcHHi7YrmZgpNhtrLX98JHF8A3nal+7aFiLuBo0cADPjaTZtl6uwJY9vvK?= =?us-ascii?Q?Da1fEIoswrEEooOGrlIPawO5b7/bBNIWqFdb9OAHl2l5V1IXVCFGCDpDEX5i?= =?us-ascii?Q?insuPPrdQ4bAMoFXy9ElUuwb/iw62tp57Qw1jxEW3G/klVWq+i3obgrQHeoR?= =?us-ascii?Q?A4J5o5sl2dBTazvHSdr5+69GayB9D4wk00oRcvUoatHqpF2QEVyn+1JOw4Ki?= =?us-ascii?Q?kF1Ahmu9RE5RI8z4DBUYujx0cWbZHQRwNS8WlDbnZJEKn61trKAr+o+9Biwy?= =?us-ascii?Q?MbRGUqpYG2yCy3R51Vb0ZUf+MHpJPohHRRAhZe1rcOpLJshFH/1mssYyvW4l?= =?us-ascii?Q?QEUG3OjAAEkydbNm7GMdldZiKEBkjt/ZDBMV3IDR5oiFFcrAilfYd40R5yco?= =?us-ascii?Q?5zaoWp+3ksUIp4vctorBVxcDsNdEg2AvwkI8xkow+WEFJ3dTYapBjY4ECGLG?= =?us-ascii?Q?s+oLoZjajwsf1KcBm23HATiwk4/veUfG4AvVGTbOhHBwpZvcz/zVfCoOgX7N?= =?us-ascii?Q?PKAWCFlNvOS9Mi4oQ0XxBHaRw9IHbrkqeWDvarkMwTiqfxhna6vZQPHqQ5Jv?= =?us-ascii?Q?DVSkyP4Vk4jtups9nAz2zeRozz1jpK8vehe0ZM2kOyP8EMD6xyThG3l46wJz?= =?us-ascii?Q?TEQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 6:Lweviif3sAkij2gNp9Gl3LN+IvvThLPlCube1YSER3ztOIt6aAnJTZAyo/ncj1oUtW4TMhdddOshJpx8MNcZB/sbHpPiGKogHiRKm3spb+7Nyc5l54NAXPqe7gfa4Api8731JO36U7pXADcqGFd6uLwncjKfm6iyOkWntoCrsfOCw7vMf4DXUeCNLqcrwzjTB4TDxa3Jq/c+MelHfWGGIbouR21bAbbiwmQ50SokpQh3aqyAn6glDYQrpzbxCuVn+UQLirVoivnaTqrgatX99kqol+CZ1gS2h4Tmikw3AXwzQHPrrwcYnWEEeHd3NKf8KjTUuaZpLgPM9orxBuw7P7noyJwCAghwY+JJFjvH9J8=; 5:5GLZSHEPBivmXt2PrFUXcW+uLFU/i3jzL1m/3iL8zHtkE6ZibYu4x4z0lczgPEJ50F1CnPDbEL6grwIEdtP//Z1hHq0MAAMslFL1AkJcS64YsloewzQId4TDhycgAgJROY1OLUchdMeQJajwzuE2MQ==; 24:GLCcgROeGLA+AxpRj1YT/aGG8G0YMNtYA9AtF/+ezDD5Ya/PcqgR6Ldy0tI7hCTZFxD+c/Vesfnua65W7SlYhgn0UZTt/yUW+mPE7MJfxA0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 7:3aHU4icNyAjLxlfcSB8MkBRiiD2ZwD8MEUBBhbh8DRUwLvVwq+Hotq6mKksfzo7nHSzZ1vAuQOXtd1Vj44JrFvAiyDhRS8mdoggEfvZRhtibwOoN1W5B4+wrrF52ZD+dS6NSyOD3YZz6jU0+wLu0JI1drB0tGhFB7h0GScrhA39iMU4UcvdXH1EhKJpV+E2JbEAORLh2jiMQwskGwX3MOYK+nohwncMEkQ2vX1sZMxumRMMjYEwLapmqIKMR2GCUv5rVRIwh1nGC3BIbAJ9AKE7TZZHxVK/V+y3xbLLMBsddkztR3M9PcFTCUEksn3xgB8lFQgpqLpqy3GCcLR+WrcrZ7+HYXlG6YP0mqhsMk9A= X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Nov 2016 19:42:56.6825 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0701MB1722 Subject: Re: [dpdk-moving] Proposal a Committer model 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: Wed, 16 Nov 2016 19:43:02 -0000 On Wed, Nov 16, 2016 at 03:13:49PM +0000, Bruce Richardson wrote: > On Wed, Nov 16, 2016 at 10:45:55AM +0000, Thomas Monjalon wrote: > > Hi, > > > > 2016-11-15 23:35, Mcnamara, John: > > > > There are a number of benefits: > > > > > > 1. Greater capacity to commit patches. > > > 2. No single points of failure - a committer should always be > > > available if we have three. > > > 3. A more timely committing of patches. More committers should equal a > > > faster turnaround - ideally, maintainers should also provide feedback > > > on patches submitted within a 2-3 day period, as much as possible, > > > to facilitate this. > > > 4. It follows best practice in creating a successful multi-vendor > > > community - to achieve this we must ensure there is a level playing > > > field for all participants, no single person should be required to > > > make all of the decisions on patches to be included in the release. > > > > Committing faster means making patches disappear from the radar faster. > > It does improve neither the quality nor the multi-vendor cooperation. > > > > DPDK is mainly a community of hardware vendors. At the beginning, there > > was only one vendor (Intel). After being open on dpdk.org, more vendors > > joined. Nowadays we are still working to be more and more vendor neutral. > > Examples of current work: bus abstraction, filter API, event model, etc. > > > > I think there are two major issues when working on neutrality in DPDK: > > > > 1/ The first challenge and priority for a developer/vendor is to > > push access to new hardware features and achieving the best performance. > > It is not his priority to think about the genericity of the design > > or the API. And he generally doesn't take care of the performance on > > other hardware. > > > > 2/ There are not enough reviews to challenge genericity of developments. > > > > The only solution to these issues is to give some time for proper reviews. > > > > I would like to highlight again that having more good reviews is a good > > way of accelerating pace while improving quality. > > It is not so hard or long to commit patches which are ready. > > It is longer when the committer must play the reviewer role because of an > > obvious lack of review. > > > > About "no single person should be required to make all of the decisions > > on patches to be included in the release", I totally agree. > > That's why the reviews and discussions must make clear what is the > > consensus, the community decision. > > > > There is one big issue that I see with the current consensus model - > consensus is very slow. There are two ways to get the new features to > the quality we want: > 1) we all work together to get the patches to 100% quality and then they > get committed once everyone is happy. > 2) a number of the most interested parties work together to get the > patches to the point where they are all happy - where quality may be > only 90% there - and the patches are applied. Anyone who subsequently > has additional comments to improve things supplies patches for the > improvement. > > Where this becomes really visible to me is where we have a feature under > discussion for a number of weeks and has reached a consensus among the > few people looking at it. It's been acked and is supposedly ready for > merge. But...then someone new comes and looks at it for the first time, > kicking off a whole new round of discussion that goes on for another number > of weeks. > > Personally I'd much rather see a system whereby the first consensus version > gets merged in sooner, so that everyone else can make progress based on > that, rather than having to wait for absolutely everyone to agree. That > way: > a) the improvements can still be made by additional patches, > b) the "shape" of the release becomes clearer sooner as there is less > big bang application of all patches at the end > c) it makes life far easier for people basing patches on other earlier > patches in the same release > d) it makes validation easier since things can be tested earlier as part > of a full tree > AND BEST OF ALL > e) it encourages people to do reviews sooner as they have to catch that > initial review window, or else they are on the hook to do the extra > cleanup patches themselves. [Right now, there is little pressure on > people to do timely reviews - if they review the patch after two days or > two weeks, that patch still has to wait for their agreement to be merged > in.] > > Now, I believe multi-committer model is much more conducive to this way > of working (though it does not strictly require multiple committers). > So long as one trusted committer (and all committers need to be trusted) > is happy with a patchset it should go in - provided a reasonable review > period has elapsed. There is too much waiting for everyone to agree > right now. The main question would be who will part of committers list? I believe the multi-committers model may not fix current consensus slowness issue. Instead, if we are focusing on reducing the workload of Thomas, then I think git pull request based scheme will reduce the workload. Jerin