linux-kernel - Re: [PATCH v2] MAINTAINERS: Update maintainer for Marvell Prestera Ethernet Switch driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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.