From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 9E7B1B6D for ; 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 ) id 1c9e0t-0002dZ-Il; Wed, 23 Nov 2016 15:19:30 -0500 Date: Wed, 23 Nov 2016 15:19:19 -0500 From: Neil Horman To: Yuanhan Liu Cc: "Mcnamara, John" , Thomas Monjalon , "dev@dpdk.org" , Jerin Jacob , Stephen Hemminger Message-ID: <20161123201919.GE6961@hmsreliant.think-freely.org> References: <20161118161025.GC29049@hmsreliant.think-freely.org> <1855350.07sWV4iMZa@xps13> <20161122195215.GA4463@hmsreliant.think-freely.org> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. >