Re: [dpdk-dev] Proposal for a new Committer model

["Mcnamara, John" <john.mcnamara@intel.com>]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Mcnamara, John
> Sent: Wednesday, November 30, 2016 9:59 AM
> To: Neil Horman <nhorman@tuxdriver.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] Proposal for a new Committer model
> 
> > -----Original Message-----
> > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > Sent: Tuesday, November 29, 2016 7:12 PM
> > To: Mcnamara, John <john.mcnamara@intel.com>
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] Proposal for a new Committer model
> >
> > > ...
> > >
> > > 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?
> 
> Hi,
> 
> Yes. I think we have consensus on the main parts. I'll re-draft a proposal
> that we can discuss and then add to the contributors guide.
> 
> John
> 

I'll submit a draft update to the DPDK Code Contributors guide shortly.

John