[dpdk-dev] git trees organization

[Bruce Richardson]

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