Hi Ferruh,
On 10/13/2017 5:21 AM, Thomas Monjalon wrote:
13/10/2017 01:31, Ferruh Yigit:
Hi Thomas, et al
Previously it has been mentioned [1] to have vendor specific driver
trees under next-net.
And recently Mellanox agreed to have a Mellanox tree [2].
Intel also agrees to have next-net-intel, and Helin will be maintaining
it, thanks to Helin for volunteering.
Good news, thanks
Other vendors with multiple drivers are Cavium, 6wind and NXP.
- Is there a name for Mellanox maintainer?
- What do other vendors, mentioned above, thinks about creating their
own sub-tree?
- Are the vendor sub-trees and their maintainers need to be approved by
tech-board?
Yes every dpdk.org git trees must be approved by the techboard.
The next meeting is tomorrow.
And what I understand from vendor specific sub-trees is, instead of
driver patches going into next-net directly, they will go into vendor
tree and next-net will pull from them.
I am trying to understand the purpose for it. Typically vendors maintain
their own tree and send the patches up-stream post internal reviews only.
- it is because different groups within a vendor company are sending
patches and you want one maintainer to confirm/review before they come
to next-net?
- Or, too many patch series dependencies between the vendor patches. It
is getting difficult to manage.
Consider the scenerio, developer 'A' sent patches for NXP. I as
maintainer of NXP, allowed them in next-net-NXP. But when I raised pull
request to next-net - you have comments. Now I have to follow up with
developer 'A' as from patchwork point of view, his patches are accepted
and merged.
Also, it may impact the quality of review, if all pull requests are
raised around RC1 time.
Regards,
Hemant
Yes we are creating a new git tree layer below next-net.
This will distribute the maintenance work among the vendors, also will
give more control to vendors on their patches.
It is very good to distribute workload.
In 17.11-rc1, there were more than 500 patches managed in next-net.
Thanks Ferruh
Thanks,
ferruh
[1]
http://dpdk.org/ml/archives/dev/2017-September/075094.html
[2]
http://dpdk.org/ml/archives/dev/2017-October/078277.html
