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

[Yuanhan Liu <yuanhan.liu@linux.intel.com>]

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.

  For those non-active pmds, I think it's okay to let the generic
  pmd committer to cover them.

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

  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.

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

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

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