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

[Neil Horman <nhorman@tuxdriver.com>]

On Wed, Nov 23, 2016 at 11:41:20PM +0800, Yuanhan Liu wrote:
> On Wed, Nov 23, 2016 at 09:11:54AM -0500, Neil Horman wrote:
> > > 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:
> 
> I would pull the git history to see which components are in
> active status in last release (or even, in last few release).
> And try to make a sub-tree if corresponding component is hot.
> 
> # the 2nd volume shows how many patches prefixed with a related component
> [yliu@yliu-dev ~/dpdk]$ git log --oneline v16.07..v16.11 | awk '{print $2}' | \
> 		        sort | uniq -c  | sort -nr | head -30 | nl
>      1       52 doc:
>      2       40 net/ixgbe/base:
>      3       38 app/test:
>      4       37 kni:
>      5       27 vhost:
>      6       27 net/virtio:
>      7       27 net/mlx5:
>      8       26 app/testpmd:
>      9       25 net/i40e:
>     10       23 net/pcap:
>     11       22 net/bnxt:
>     12       20 net/enic:
>     13       18 net/qede:
>     14       17 net/thunderx:
>     15       16 net/qede/base:
>     16       16 eal:
>     17       15 net/ixgbe:
>     18       14 net:
>     19       14 crypto/qat:
>     20       13 scripts:
>     21       13 net/bnx2x:
>     22       12 net/i40e/base:
>     23       12 examples/ipsec-secgw:
>     24       11 mbuf:
>     25       11 hash:
>     26       10 lib:
>     27       10 examples/ip_pipeline:
>     28       10 ethdev:
>     29        9 pci:
>     30        7 net/vmxnet3:
>     ...
>     46        3 pdump:
>     47        3 net/virtio_user:
>     48        3 net/ring:
>     49        3 net/nfp:
>     50        3 net/mlx:
>     51        3 net/ena:
>     52        3 net/e1000:
>     53        3 net/bonding:
>     ...
>     56        2 sched:
>     57        2 port:
>     ...
>     65        1 timer:
>     66        1 remove
>     67        1 pmdinfogen:
>     68        1 net/igb:
>     69        1 net/enic/base:
>     70        1 meter:
>     ...
>     84        1 cfgfile:
>     85        1 app/procinfo:
>     86        1 app/proc_info:
>     87        1 acl:
> 
> Something obvious is that:
> 
> - "doc" deserves a sub-tree, and John is a perfect committer for that
>   if he's willing to.
> 
> - generally, I'd agree with Neil that most (if not all) pmds may need
>   a sub-tree. While, some others may not, for example, net/ring, net/pcap.
> 
No, thats the opposite of what I think.  I think all net pmds should flow
through a single subtree, all crypto pmds through another, etc.

>   For those non-active pmds, I think it's okay to let the generic
>   pmd committer to cover them.
> 
Not sure what you're getting at here.  Low volume pms (or any library) can still
go through a subtree.  The goal is to fragmet the commit work so one person
doesn't have to do it all.

> - it's not that wise to me to list all the components we have so far
>   and make a sub-tree for each of them.
> 
I think you misunderstood the organization of my last note.  I agree with you
here.  When I listed the core and listed several libraries under it, my intent
was to create a core subtree that accepted patches for all of those libraries.

>   For example, some components like librte_{port, pdump, cfgfile, acl,
>   and etc} just have few (or even, just one) commits in last release.
>   It makes no sense to me to introduce a tree for each of them.
> 
Yes, this is what I was saying in my last note.

> Another thought is we could also create sub-trees based on category
> but not on components like Neil suggested, especially that EAL looks
> way too big to be maintained in one tree. Instead, it could be something
> like:
> 
> - a tree for BSD
> 
This gets tricky, because then several libraries will be covered by multiple
trees, and that leads to merge conflicts.

> - a tree for ARM (and some other trees for other platforms)
> 
> - a tree for mem related (mempool, mbuf, hugepage, etc)
> 
> - a tree for BUS
> 
> - ...
> 
> 
> Last but not the least, I think it's general good to have more and
> more trees in the end. But I don't think it's a good idea to go
> radically and create all those trees once (say in one release).
> 
> Something I would like to suggest is one or two (or a bit more) at
> a release. For example, if I remember them well, we have next-net
> tree at 16.04, and next-virtio (including vhost) at 16.07, and a
> recent one, next-crypto at 16.11.
> 
I'm not sure what you mean by this.  -next trees rather by definition should e
rebased on a release to start at the head of thomas's tree and add commits from
there based on their subject area.

Neil

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