[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dc9fb975-6258-0473-3ed9-58d3a74e501a@plvision.eu>
Date: Wed, 7 Dec 2022 14:36:02 +0200
From: Taras Chornyi <taras.chornyi@...ision.eu>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Vadym Kochan <vadym.kochan@...ision.eu>,
"David S. Miller" <davem@...emloft.net>,
Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
Elad Nachman <enachman@...vell.com>,
Mickey Rachamim <mickeyr@...vell.com>,
linux-kernel@...r.kernel.org, Taras Chornyi <tchornyi@...vell.com>
Subject: Re: [PATCH v2] MAINTAINERS: Update maintainer for Marvell Prestera
Ethernet Switch driver
On 01.12.22 23:17, Jakub Kicinski wrote:
> On Thu, 1 Dec 2022 10:39:07 +0200 Taras Chornyi wrote:
>> On 30.11.22 07:14, Jakub Kicinski wrote:
>>> On Mon, 28 Nov 2022 11:39:34 +0200 Vadym Kochan wrote:
>>>> Add Elad Nachman as maintainer for Marvell Prestera Ethernet Switch driver.
>>>>
>>>> Change Taras Chornyi mailbox to plvision.
>>> This is a patch, so the description needs to explain why...
>>> and who these people are. It would seem more natural if you,
>>> Oleksandr and Yevhen were the maintainers.
>>>
>>> Seriously, this is a community project please act the part.
>> The Marvell Prestera Switchdev Kernel Driver's focus and maintenance are
>> shifted from PLVision (Marvell Contractors) to the Marvell team in Israel.
>> In the last 12 months, the driver's development efforts have been shared
>> between the PLVision team and Elad Nachman from the Marvell Israel group.
>
> Ah, damn, I was worried that's what you'd say :(
>
>> Elad Nachman is a veteran with over ten years of experience in Linux
>> kernel development.
>> He has made many Linux kernel contributions to several community
>> projects, including the Linux kernel, DPDK (KNI Linux Kernel driver) and
>> the DENT project.
>> Elad has done reviews and technical code contributions on Armada 3700,
>> Helping Pali Rohár, who is the maintainer of the Armada 3700 PCI
>> sub-system, as well as others in the Armada 3700 cpufreq sub-system.
>> In the last year and a half, Elad has internally dealt extensively with
>> the Marvell Prestera sub-system and has led various upstreaming
>> sub-projects related to the Prestera sub-system, Including Prestera
>> sub-system efforts related to the Marvell AC5/X SOC drivers upstreaming.
>> This included technical review and guidance on the technical aspects and
>> code content of the patches sent for review.
>> In addition, Elad is a member of the internal review group of code
>> before it applies as a PR.
>
> I see 4 mentions of Elad Nachman in the entire git history.
>
> The distinction between the kernel community and the corporate Linux
> involvement is something I don't quite know how to verbalize.
> And I don't know whether my perspective is shared by others.
>
> Linux has taken over the world (at least the technical world) so having
> Linux kernel exposure is common. But building a product based on Linux
> which is then packaged and shipped to customers, in the usual corp
> product development methodology, translates very poorly to developing
> upstream. This is more true in networking that other parts of the
> kernel, to my knowledge, because we attempt to build vendor-independent
> abstractions.
>
> While I do not mean to question Elad's expertise and capability as an
> engineer/lead/manager, and very much appreciate Marvell's investment
> in the upstream drivers for Prestera and in DENT -- I think the
> community involvement is lacking. Short to medium term we should try to
> find a way of improving this situation, we can clarify what we expect
> from you and if you have ideas on how we can make the involvement**
> easier - we'd love to hear them.
>
> ** community involvement ideas, less interested in how we can make the
> "ship products" part easier, but you can share those too
>
>> Finally, do note the fact that I will continue to maintain/support this
>> driver, but I would like to have someone that I can share the effort with.
>
> Understandable. I hope PLVision does not disappear form the picture.
> We are really allergic to the "push the driver upstream and disengage"
> or "throw it over the wall open source" model, if you will.
>
> Unfortunately we only have one nuclear button for discouraging such
> arrangements (git-rm), which will hopefully never be used.
>
> To conclude, I think we should have a call first, and then decide
> who the best choice for a maintainer is.
So we will drop this patch and create a new one with changing my email
to PLVision one.
Powered by blists - more mailing lists