From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 761C3282 for ; Tue, 29 Nov 2016 20:12:25 +0100 (CET) Received: from cpe-2606-a000-111b-40ed-7aac-c0ff-fec2-933b.dyn6.twc.com ([2606:a000:111b:40ed:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1cBnpB-0004tB-4g; Tue, 29 Nov 2016 14:12:22 -0500 Date: Tue, 29 Nov 2016 14:12:07 -0500 From: Neil Horman To: "Mcnamara, John" Cc: dev@dpdk.org Message-ID: <20161129191207.GA17132@hmsreliant.think-freely.org> References: <20161118161025.GC29049@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161118161025.GC29049@hmsreliant.think-freely.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] Proposal for a new Committer model X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 19:12:25 -0000 On Fri, Nov 18, 2016 at 01:09:35PM -0500, Neil Horman wrote: > On Thu, Nov 17, 2016 at 09:20:50AM +0000, Mcnamara, John wrote: > > Repost from the moving at dpdk.org mailing list to get a wider audience. > > Original thread: http://dpdk.org/ml/archives/moving/2016-November/000059.html > > > > > > Hi, > > > > I'd like to propose a change to the DPDK committer model. Currently we have one committer for the master branch of the DPDK project. > > > > One committer to master represents a single point of failure and at times can be inefficient. There is also no agreed cover for times when the committer is unavailable such as vacation, public holidays, etc. I propose that we change to a multi-committer model for the DPDK project. We should have three committers for each release that can commit changes to the master branch. > > > > 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. > > > > Having multiple committers will require some degree of co-ordination but there are a number of other communities successfully following this model such as Apache, OVS, FD.io, OpenStack etc. so the approach is workable. > > > > John > > I agree that the problems you are attempting to address exist and are > worth finding a solution for. That said, I don't think the solution you > are proposing is the ideal, or complete fix for any of the issues being > addressed. > > If I may, I'd like to ennumerate the issues I think you are trying to > address based on your comments above, then make a counter-proposal for a > solution: > > Problems to address: > > 1) high-availability - There is a desire to make sure that, when patches > are proposed, they are integrated in a timely fashion. > > 2) high-throughput - DPDK has a large volume of patches, more than one > person can normally integrate. There is a desire to shard that work such > that it is handled by multiple individuals > > 3) Multi-Vendor fairness - There is a desire for multiple vendors to feel > as though the project tree maintainer isn't biased toward any individual > vendor. > > To solve these I would propose the following solution (which is simmilar > to, but not quite identical, to yours). > > A) Further promote subtree maintainership. This was a conversation that I > proposed some time ago, but my proposed granularity was discarded in favor > of something that hasn't worked as well (in my opinion). That is to say a > few driver pmds (i40e and fm10k come to mind) have their own tree that > send pull requests to Thomas. We should be sharding that at a much higher > granularity and using it much more consistently. That is to say, that we > should have a maintainer for all the ethernet pmds, and another for the > crypto pmds, another for the core eal layer, another for misc libraries > that have low patch volumes, etc. Each of those subdivisions should have > their own list to communicate on, and each should have a tree that > integrates patches for their own subsystem, and they should on a regular > cycle send pull requests to Thomas. Thomas in turn should by and large, > only be integrating pull requests. This should address our high- > throughput issue, in that it will allow multiple maintainers to share the > workload, and integration should be relatively easy. > > B) Designate alternates to serve as backups for the maintainer when they > are unavailable. This provides high-availablility, and sounds very much > like your proposal, but in the interests of clarity, there is still a > single maintainer at any one time, it just may change to ensure the > continued merging of patches, if the primary maintainer isn't available. > Ideally however, those backup alternates arent needed, because most of the > primary maintainers work in merging pull requests, which are done based on > the trust of the submaintainer, and done during a very limited window of > time. This also partially addreses multi-vendor fairness if your subtree > maintainers come from multiple participating companies. > > Regards > Neil > > > Soo, I feel like we're wandering away from this thread. Are you going to make a change to the comitter model? Neil