From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <nhorman@tuxdriver.com>
Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])
by dpdk.org (Postfix) with ESMTP id 9E7B1B6D
for <dev@dpdk.org>; Wed, 23 Nov 2016 21:19:35 +0100 (CET)
Received: from cpe-2606-a000-111b-40ed-7aac-c0ff-fec2-933b.dyn6.twc.com
([2606:a000:111b:40ed:7aac:c0ff:fec2:933b] helo=localhost)
by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63)
(envelope-from <nhorman@tuxdriver.com>)
id 1c9e0t-0002dZ-Il; Wed, 23 Nov 2016 15:19:30 -0500
Date: Wed, 23 Nov 2016 15:19:19 -0500
From: Neil Horman <nhorman@tuxdriver.com>
To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Cc: "Mcnamara, John" <john.mcnamara@intel.com>,
Thomas Monjalon <thomas.monjalon@6wind.com>, "dev@dpdk.org" <dev@dpdk.org>,
Jerin Jacob <jerin.jacob@caviumnetworks.com>,
Stephen Hemminger <stephen@networkplumber.org>
Message-ID: <20161123201919.GE6961@hmsreliant.think-freely.org>
References: <B27915DBBA3421428155699D51E4CFE202661F22@IRSMSX103.ger.corp.intel.com>
<20161118161025.GC29049@hmsreliant.think-freely.org>
<1855350.07sWV4iMZa@xps13>
<20161122195215.GA4463@hmsreliant.think-freely.org>
<B27915DBBA3421428155699D51E4CFE2026648E4@IRSMSX103.ger.corp.intel.com>
<20161123141154.GB6961@hmsreliant.think-freely.org>
<20161123154120.GB5048@yliu-dev.sh.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161123154120.GB5048@yliu-dev.sh.intel.com>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Spam-Score: -2.9 (--)
X-Spam-Status: No
Subject: Re: [dpdk-dev] Proposal for a new Committer model
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Nov 2016 20:19:35 -0000
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.
>