From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 9CDB8567E for ; Wed, 23 Nov 2016 16:40:30 +0100 (CET) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga104.fm.intel.com with ESMTP; 23 Nov 2016 07:40:29 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,538,1473145200"; d="scan'208";a="34860607" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by fmsmga005.fm.intel.com with ESMTP; 23 Nov 2016 07:40:28 -0800 Date: Wed, 23 Nov 2016 23:41:20 +0800 From: Yuanhan Liu To: Neil Horman Cc: "Mcnamara, John" , Thomas Monjalon , "dev@dpdk.org" , Jerin Jacob , Stephen Hemminger Message-ID: <20161123154120.GB5048@yliu-dev.sh.intel.com> References: <20161118161025.GC29049@hmsreliant.think-freely.org> <1855350.07sWV4iMZa@xps13> <20161122195215.GA4463@hmsreliant.think-freely.org> <20161123141154.GB6961@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161123141154.GB6961@hmsreliant.think-freely.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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 15:40:31 -0000 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.