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]

Message-ID: <20221201131744.6e94c5f7@kernel.org>
Date:   Thu, 1 Dec 2022 13:17:44 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Taras Chornyi <taras.chornyi@...ision.eu>
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 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.