From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id A8B335599 for ; Wed, 16 Nov 2016 17:23:54 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP; 16 Nov 2016 08:23:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,500,1473145200"; d="scan'208";a="787206020" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by FMSMGA003.fm.intel.com with ESMTP; 16 Nov 2016 08:23:53 -0800 Received: from fmsmsx117.amr.corp.intel.com (10.18.116.17) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 16 Nov 2016 08:23:53 -0800 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.68]) by fmsmsx117.amr.corp.intel.com ([10.18.116.17]) with mapi id 14.03.0248.002; Wed, 16 Nov 2016 08:23:52 -0800 From: "Wiles, Keith" To: "Richardson, Bruce" CC: Thomas Monjalon , "Mcnamara, John" , "moving@dpdk.org" , "Yigit, Ferruh" , "yuanhan.liu@linux.intel.com" , "De Lara Guarch, Pablo" Thread-Topic: [dpdk-moving] Proposal a Committer model Thread-Index: AdI/l7PhpM0xx4kTSdma4UibzjQDRgAofW6AAAlbNoAAAnImgA== Date: Wed, 16 Nov 2016 16:23:52 +0000 Message-ID: References: <1660077.mdFWPiNUk9@xps13> <20161116151348.GA31872@bricha3-MOBL3.ger.corp.intel.com> In-Reply-To: <20161116151348.GA31872@bricha3-MOBL3.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.252.134.192] Content-Type: text/plain; charset="us-ascii" Content-ID: <5D253A90CA40E841B5A58F382E17E838@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 16:23:56 -0000 > On Nov 16, 2016, at 9:13 AM, Bruce Richardson wrote: >=20 > On Wed, Nov 16, 2016 at 10:45:55AM +0000, Thomas Monjalon wrote: >> Hi, >>=20 >> 2016-11-15 23:35, Mcnamara, John: > >>> There are a number of benefits: >>>=20 >>> 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. >>=20 >> Committing faster means making patches disappear from the radar faster. >> It does improve neither the quality nor the multi-vendor cooperation. >>=20 >> 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. >>=20 >> I think there are two major issues when working on neutrality in DPDK: >>=20 >> 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. >>=20 >> 2/ There are not enough reviews to challenge genericity of developments. >>=20 >> The only solution to these issues is to give some time for proper review= s. >>=20 >> 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 a= n >> obvious lack of review. >>=20 >> 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. >>=20 >=20 > 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. >=20 > 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 numb= er > of weeks. >=20 > Personally I'd much rather see a system whereby the first consensus versi= on > 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.] >=20 > 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. >=20 +1 I agree, your suggestion to commit sooner then later is reasonable plus = timely for DPDK. I think the multiple committer model is a requirement to get things done in= a quicker manner as this does not place more pressure on a single committe= r. > My 2c. >=20 > /Bruce Regards, Keith