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

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

> -----Original Message-----
> From: Neil Horman [mailto:nhorman@tuxdriver.com]
> Sent: Tuesday, November 22, 2016 7:52 PM
> To: Thomas Monjalon <thomas.monjalon@6wind.com>
> Cc: dev@dpdk.org; Mcnamara, John <john.mcnamara@intel.com>
> Subject: Re: [dpdk-dev] Proposal for a new Committer model
> 
> On Mon, Nov 21, 2016 at 09:52:41AM +0100, Thomas Monjalon wrote:
> > 2016-11-18 13:09, Neil Horman:
> > > 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.
> >
> > Yes we tried this fine granularity and stated that it was not working
> well.
> > We are now using the bigger granularity that you describe below.
> >
> Ok, thats good, but that must be _very_ new.  Looking at your git tree, I
> see no merge commits.  How are you pulling from those subtrees?
> 


Hi Neil,

It seems like the weight of consensus in around your proposal for further subtree maintainers and backups. If you don't mind I'll take your text and redraft it as a potential section on maintainership for a future Project Charter document. Or at least so that we have a documented maintainship process.

 
> > > 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.
> >
> > Yes we could open a tree for EAL and another one for the core libraries.
> >
> That could be worthwhile.  Lets see how the net and crypto subtrees work
> out (assuming again that these trees are newly founded)

Could we define some of the potential subtrees now and look to introduce them in the this release cycle? EAL and the Core libs, as suggested by Thomas, seem like 2 obvious ones.


> 
> > > 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.
> >
> > Yes I think it is now a good idea to split the mailing list traffic,
> > at least for netdev and cryptodev.

I'd prefer not to have split dev lists, for now at least. We can reevaluate that again in a few months though.


> >
> 
> > > 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.


+1 on this apart from the limited merge window (for reasons similar to Thomas).

Should we have a call for volunteers for backup, on master and the sub-trees, followed by a simple +1 from community members to endorse them?


John