DPDK patches and discussions
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: "Mcnamara, John" <john.mcnamara@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Proposal for a new Committer model
Date: Tue, 29 Nov 2016 14:12:07 -0500	[thread overview]
Message-ID: <20161129191207.GA17132@hmsreliant.think-freely.org> (raw)
In-Reply-To: <20161118161025.GC29049@hmsreliant.think-freely.org>

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

  parent reply	other threads:[~2016-11-29 19:12 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-17  9:20 Mcnamara, John
2016-11-18  6:00 ` Matthew Hall
2016-11-18 18:09 ` Neil Horman
2016-11-18 19:06   ` Jerin Jacob
2016-11-20  4:17     ` Stephen Hemminger
2016-11-21  8:52   ` Thomas Monjalon
2016-11-22 19:52     ` Neil Horman
2016-11-22 20:56       ` Ferruh Yigit
2016-11-23 13:48         ` Neil Horman
2016-11-23 14:01           ` Ferruh Yigit
2016-11-23 15:33             ` Neil Horman
2016-11-23 16:21               ` Ferruh Yigit
2016-11-23 20:13                 ` Neil Horman
2016-11-24  9:17                   ` Thomas Monjalon
2016-11-25 19:55                     ` Neil Horman
2016-11-23  8:21       ` Mcnamara, John
2016-11-23 14:11         ` Neil Horman
2016-11-23 15:41           ` Yuanhan Liu
2016-11-23 20:19             ` Neil Horman
2016-11-24  5:53               ` Yuanhan Liu
2016-11-25 20:05                 ` Neil Horman
2016-11-29 19:12   ` Neil Horman [this message]
2016-11-30  9:58     ` Mcnamara, John
2016-12-02 16:41       ` Mcnamara, John

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161129191207.GA17132@hmsreliant.think-freely.org \
    --to=nhorman@tuxdriver.com \
    --cc=dev@dpdk.org \
    --cc=john.mcnamara@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).