[dpdk-dev] Proposal for a new Committer model
Neil Horman
nhorman at tuxdriver.com
Wed Nov 23 21:19:19 CET 2016
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 at 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.
>
More information about the dev
mailing list