All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Wiles, Keith" <keith.wiles@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: "Richardson, Bruce" <bruce.richardson@intel.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"stephen@networkplumber.org" <stephen@networkplumber.org>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: git trees organization
Date: Tue, 12 Sep 2017 13:01:16 +0000	[thread overview]
Message-ID: <823B49E6-AA06-4DE4-8AF1-BE205DFC324C@intel.com> (raw)
In-Reply-To: <1536607.mpdSPqACls@xps>


> On Sep 12, 2017, at 3:48 AM, Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> 12/09/2017 10:32, Bruce Richardson:
>> On Tue, Sep 12, 2017 at 12:03:30AM +0200, Thomas Monjalon wrote:
> [...]
>>> 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.
> 
> OK, we need the name of a volunteer :)

You miss-spelled ‘volunteer' it should be 'victim’ :-)

> 
>>> 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.
> 
> We are going to have many bus drivers (pci, vdev, fslmc, vmbus).
> If we look only at PCI, there are always some new patches to improve
> or fix things. So I think it is reasonnable to imagine that we will
> have some real activity with all bus drivers.
> 
>>> 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.
> 
> Sure it was a mistake, but it was assumed because net drivers is already
> a big work. I hope we can add it now while moving Intel drivers to
> a second level sub-tree.
> 
>>> Other suggestions?
>> 
>> Similar to above, cryptodev should be in crypto tree, eventdev in event
>> tree etc.
> 
> It is already the case. No change to do here :)
> 
>> 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.
> 
> Yes!

Regards,
Keith


  reply	other threads:[~2017-09-12 13:01 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-11 22:03 git trees organization Thomas Monjalon
2017-09-12  8:32 ` Bruce Richardson
2017-09-12  8:48   ` Thomas Monjalon
2017-09-12 13:01     ` Wiles, Keith [this message]
2017-09-12 16:34     ` Ferruh Yigit
2017-09-13  7:58   ` Adrien Mazarguil
2017-09-13 11:38     ` Ferruh Yigit
2017-09-13 12:25       ` Adrien Mazarguil
2017-09-13 13:21         ` Ferruh Yigit
2017-09-13 14:54           ` Adrien Mazarguil
2017-09-14  2:25             ` Stephen Hemminger
2017-09-14  8:22               ` Thomas Monjalon
2017-09-14  9:03                 ` Bruce Richardson
2017-09-14  9:18                   ` Thomas Monjalon
2017-09-14 12:50                     ` Wiles, Keith
2017-09-14  9:11                 ` Nélio Laranjeiro
2017-09-14 17:57                   ` Stephen Hemminger
2017-09-12 16:32 ` Ferruh Yigit
2017-09-12 20:20   ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=823B49E6-AA06-4DE4-8AF1-BE205DFC324C@intel.com \
    --to=keith.wiles@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.