[dpdk-dev] volunteer to be the maintainer of driver/net/intel sub-tree

[dpdk-dev] volunteer to be the maintainer of driver/net/intel sub-tree

[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.
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.

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.

Best regards
Wenzhuo Lu

Re: [dpdk-dev] volunteer to be the maintainer of driver/net/intel sub-tree

[Thomas Monjalon]

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?

Re: [dpdk-dev] volunteer to be the maintainer of driver/net/intel sub-tree

[Lu, Wenzhuo]

Hi Thomas,

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Thursday, October 22, 2015 4:17 PM
> To: Lu, Wenzhuo
> Cc: dev@dpdk.org; Zhang, Helin; Richardson, Bruce
> Subject: Re: volunteer to be the maintainer of driver/net/intel sub-tree
> 
> 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.
> 
I think you're reasonable. I thought adding a directory may make thing's simple,
but the reality is it may introduce something that's out of our control. :)
But a single directory also has its benefit, it can easily let us know all the things
in the directory is maintained by a or a group of owners. I think the key is how to
let the developers know what happens. If something can explain itself, we need not
clarify it. Agree we'd better not adding the company name. But I think it's still worth
thinking about how to make things more clear. Honestly, I don't have any proposal
now. Maybe we have to come out a doc at last. :)

> > 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?
Honestly, I cannot tell which is better that we begin with a big area or a small area.
But I agree we should have something working first. It can become a guide .
A sub-tree for networking drivers seems to be a good option. If it's not too bothering,
I'd like to mention again that the concern is the networking drivers are affinitive with
rte_eth.