From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 8423E559A for ; Wed, 16 Nov 2016 16:13:53 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP; 16 Nov 2016 07:13:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,500,1473145200"; d="scan'208";a="1069320545" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.64]) by fmsmga001.fm.intel.com with SMTP; 16 Nov 2016 07:13:49 -0800 Received: by (sSMTP sendmail emulation); Wed, 16 Nov 2016 15:13:49 +0000 Date: Wed, 16 Nov 2016 15:13:49 +0000 From: Bruce Richardson To: Thomas Monjalon Cc: "Mcnamara, John" , "moving@dpdk.org" , "Yigit, Ferruh" , "yuanhan.liu@linux.intel.com" , "De Lara Guarch, Pablo" Message-ID: <20161116151348.GA31872@bricha3-MOBL3.ger.corp.intel.com> References: <1660077.mdFWPiNUk9@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1660077.mdFWPiNUk9@xps13> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.7.1 (2016-10-04) 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 15:13:54 -0000 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. My 2c. /Bruce