From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <bruce.richardson@intel.com> Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 138CE1D8A for <dev@dpdk.org>; Tue, 12 Sep 2017 10:32:14 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2017 01:32:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,382,1500966000"; d="scan'208";a="1217655470" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.24]) by fmsmga002.fm.intel.com with SMTP; 12 Sep 2017 01:32:11 -0700 Received: by (sSMTP sendmail emulation); Tue, 12 Sep 2017 09:32:07 +0100 Date: Tue, 12 Sep 2017 09:32:07 +0100 From: Bruce Richardson <bruce.richardson@intel.com> To: Thomas Monjalon <thomas@monjalon.net> Cc: ferruh.yigit@intel.com, stephen@networkplumber.org, dev@dpdk.org Message-ID: <20170912083207.GC40060@bricha3-MOBL3.ger.corp.intel.com> References: <2737351.pD9poAUtZC@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2737351.pD9poAUtZC@xps> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.8.3 (2017-05-23) Subject: Re: [dpdk-dev] git trees organization X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <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: Tue, 12 Sep 2017 08:32:15 -0000 On Tue, Sep 12, 2017 at 12:03:30AM +0200, Thomas Monjalon wrote: > Hi all, > > As you know I am currently the only maintainer of the master tree. > It is very convenient because I need to synchronize with others > only when pulling "next-*" trees. > But the drawback is that I should be available very often to > avoid stalled patches waiting in patchwork backlog. > > I feel it is the good time to move to a slightly different organization. > I am working closely with Ferruh Yigit for almost one year, as next-net > maintainer, and I think it would be very efficient to delegate him some > work for the master tree. I think Ferruh has been doing an excellent job on the net tree, and would be an excellent candidate to help with the workload on the master tree. > I mean that I would use the patchwork delegation to explicitly divide > the workload given our different experiences. > Ferruh, do you agree taking this new responsibility? > > At the same time, we can think how to add more git sub-trees: In principle, I'm in favour, but I think that the subtrees of the master tree should be at a fairly coarse granularity, and not be too many of them. The more subtrees, the more likely we are to have issues with patchsets needing to be split across trees, or having to take bits from multiple trees in order to test if everything is working. > Should we create next-net-intel for Intel networking drivers? Given the number and size of intel drivers, this seems reasonable to start as a second-level subtree. > Any volunteer? > > Should we create next-bus for bus API and drivers? > Stephen Hemminger is working on a new bus. > Would you be interested by taking the responsibility of this git tree? Is this something that is going to need ongoing work and maintenance, or just something that would be needed while the current rework of introducing bus types is being done? If the former, a tree makes sense, but not if it's the latter case. > > Should we create next-mem for malloc/mempool? > Core libs tree, encompassing eal, mempool and 1 or 2 others? I don't think memory should have its own tree initially. > Should we take ethdev patches into next-net? Definitely! I think not doing so was a bit of a mistake when net tree was spun off. > > Other suggestions? Similar to above, cryptodev should be in crypto tree, eventdev in event tree etc. Other than that, all I can say is "let's do it!". We have quite a backlog to get through for 17.11, so anything that moves things along faster is to be welcomed. /Bruce