DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] volunteer to be the maintainer of driver/net/intel sub-tree
Date: Thu, 22 Oct 2015 10:17:27 +0200	[thread overview]
Message-ID: <2241359.mdZUFIHDJv@xps13> (raw)
In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC0909020A1938@shsmsx102.ccr.corp.intel.com>

Hi Wenzhuo,

2015-10-22 02:49, Lu, Wenzhuo:
> Hi all,
> Following the discussion of DPDK user space and the maintenance of development sub-trees, I'd like to volunteer myself to be the maintainer of sub-tree driver/net/intel. It includes all the PMD of Intel NICs. And Helin can be my backup.

Thanks for proposing.
You are already doing part of the work being maintainer of e1000,
and Helin for ixgbe and i40e.

> I suggest we create a new directory to move the driver/net/e1000, driver/net/fm10k... to it. And we can also create directories for other vendors just like the kernel driver do.

We don't need to move files to be able to manage them in a sub-tree.
For the day to day tasks, it's better to limit directory depth.
And think about what happened with Broadcom and Qlogic, we are not going
to move files when Intel will buy the NIC xyz.
Generally speaking, it's better to keep company names outside of technical things.

> Additionally, as we observed, some patch sets will not only change the files in drivers/net, but also some files in lib/librte_ether, doc, app, examples... Only being drivers/net/intel maintainer cannot work for these patch sets, especially for the new features. Applying partial feature patch set is not ideal. Ideally we need a maintainer to drive the RTE_ETHER discussion. Maybe Bruce can be a top-level maintainer. So, he can help when we face this scenario.

A sub-tree is not restricted to some directories. It must manage an
expertise zone, a technical domain, an area of interest, choose your words ;)

Today we have no working sub-tree. So we should start splitting areas in
some large grain and make it work. Then we can split more with a top down
approach.
So I think we should first create the subtree for networking drivers and wait
a little before having a subtree for Intel NICs.

Do you agree?

  reply	other threads:[~2015-10-22  8:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-22  2:49 Lu, Wenzhuo
2015-10-22  8:17 ` Thomas Monjalon [this message]
2015-10-22 12:00   ` Lu, Wenzhuo

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=2241359.mdZUFIHDJv@xps13 \
    --to=thomas.monjalon@6wind.com \
    --cc=dev@dpdk.org \
    --cc=wenzhuo.lu@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).