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

[Neil Horman <nhorman@tuxdriver.com>]

On Wed, Nov 23, 2016 at 08:21:39AM +0000, Mcnamara, John wrote:
> 
> 
> > -----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.
> 
Sure, that sounds good to me.  Thank you.

>  
> > > > 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.
> 
Sure, I'd suggest the following:
	* net-pmds:
		- all network pmds located under drivers/net
		- librte_net
		- libtre_ether
		- librte_ip_frag
		- librte_pdump
		- librte_port
	* crypto-pmds:
		- all crypto pmds located under drivers/crypto
		- librte_cryptodev
	* eal:
		- librte_eal
	* core:
		- librte_cfgfile
		- librte_cmdline
		- librte_compat
		- librte_kvargs
		- librte_kni
		- librte_compat
	* misc:
		- librte_acl
		- librte_distributor
		- librte_hash
		- librte_jobstats
		- librte_lpm
		- librte_meter
		- librte_pipeline
		- librte_power
		- librte_reorder
		- librte_ring
		- librte_sched
		- librte_table
		- librte_timer
		- librte_vhost

Thats just a rough stab mind, but perhaps it would get the ball rolling.  I'd be
willing to take maintainership of one of these subtrees if there is consensus
around my doing so.

> 
> > 
> > > > 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.
> 
So, if thats a deal breaker, we can talk about it, but I need to point out that
multiple subtrees with a single development list creates a wide range of
problems that will later give the perception that creating subtrees in the first
place wasn't worthwhile.  If you have multiple maintainers working on multiple
subtrees in parallel with the expectation that we will all merge to thomas's
tree during the devel cycle, then those maintainers absolutely must have a way
to identify which patches are destined for their tree, and which can be ignored.
To not have that invites duplicated work at best (as multiple maintainers apply
the same patch), and serious merge breakage at worst (as multiple massaged patch
applications conflict during the merge).  We can manage it with tagged
submissions, but relying on developers to use those tags consistently is very
hit or miss.  It would be much more desireable to split development into lists
that correspond with the subtrees, so that posting to a list has a 1:1
correlation with the tree it was intended to be merged to.  As I noted
previously, subscribing to several lists and treating them as a single inbox is
a trivial operation.

> 
> > >
> > 
> > > > 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).
> 
Yeah, apparently I misspoke here.  I never meant to indicate that the merge
window could be smaller/shorter/what have you.  I only meant to indicate that,
if Thomas's primary role is merging pull requests from subtrees, then his job
takes much less time than it otherwise would if he's applying individual
patches, which in turn makes the need for backups (due to
vacation/illness/whatever), less of a pressing issue.


> 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?
> 
I would think that we could merge the roles into one.  That is to say, if we
assume that sub-tree maintainers are implicitly trusted by Thomas to send good
pul requests, then they also would make good backups for him.  i.e. if you
volunteer to be a sub-tree maintainer, you get added to the list of master tree
backups, in some order to be determined by Thomas should he need to take an
absence for any reason.  Just my $0.02 on that, we can organize that however you
would like.

I'd be willing to be a subtree maintainer.  I'll handle any tree, once we have
consensus on the segmentation, and list relationships.

Regards
Neil
> 
> John
> 
> 
>