linux-kernel - Re: [PATCH 1/1] MAINTAINERS: Add maintainer for NXP S32G boards

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: <bcb79af4-56d9-4204-9503-cff996f1ba41@oss.nxp.com>
Date: Wed, 21 Feb 2024 19:00:10 +0200
From: Ghennadi Procopciuc <ghennadi.procopciuc@....nxp.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
 Chester Lin <chester62515@...il.com>, krzysztof.kozlowski+dt@...aro.org,
 Andreas Färber <afaerber@...e.de>,
 Matthias Brugger <mbrugger@...e.com>, robh+dt@...nel.org
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 soc@...nel.org, NXP S32 Linux Team <s32@....com>,
 Ghennadi Procopciuc <ghennadi.procopciuc@....com>
Subject: Re: [PATCH 1/1] MAINTAINERS: Add maintainer for NXP S32G boards

On 2/21/24 17:43, Krzysztof Kozlowski wrote:
> On 21/02/2024 16:19, Ghennadi Procopciuc wrote:
>> On 2/21/24 16:45, Krzysztof Kozlowski wrote:
>>> On 21/02/2024 15:42, Krzysztof Kozlowski wrote:
>>>> On 21/02/2024 13:01, Ghennadi Procopciuc wrote:
>>>>> From: Ghennadi Procopciuc <ghennadi.procopciuc@....com>
>>>>>
>>>>> Add myself as a maintainer of the NXP S32G DT files.
>>>>
>>>> No need for cover letters for single patches. OTOH, this commit msg is
>>>> empty...
>> Thank you, I can correct that.
>>
>>>> Plus your patch looks corrupted (wrong encoding): F??rber
>>
>> Indeed, it is due to 'Content-Type: text/plain; charset="us-ascii"'.
>> I can fix this as part of v2.
>>
>>>> BTW, did you contribute anything to the upstream Linux kernel? Do you
>>>> know the process? Downstream does not really matter.
>>>
>>> I found the answer:
>>>
>>> From: Ghennadi Procopciuc <ghennadi.procopciuc@....com>
>>> Signed-off-by: Ghennadi Procopciuc <ghennadi.procopciuc@....nxp.com>
>>>
>>> Does not look like. Please get some upstream work experience first.
>>>
>>> https://lore.kernel.org/all/?q=f%3Aghennadi.procopciuc%40oss.nxp.com
>>
>> Although I am new to upstream communities and may make mistakes, I am
>> eager to learn and improve.
>>
>> After leaving SuSe[0], the current maintainer of the NXP S32G DT files
>> became inactive[1]. As a result, this area is not currently being
>> maintained. This is the actual reason why I attempted to add myself as a
>> maintainer of that area. Although I acknowledge that I may not have
>> enough experience to become a maintainer, I am concerned that the NXP
>> S32G DT patch submission may be blocked for everyone due to the current
>> situation.
> 
> I would be just happy to see first actual contributions or any sort of
> activity, like reviewing, before taking over something.
> 
> You do not need to become maintainer to provide reviews. By reviewing
> patches you already reduce burden/work from the maintainers.
> 
> Best regards,
> Krzysztof
> 

I fully understand and agree with your perspective on this matter and
accept the fact that I will not be a maintainer as initially intended.
Furthermore, I am very willing to participate in any reviews related to
S32G SoCs.

Patches, including those I have created ([0], [1]), will likely be
submitted for this area. This is because each enabled driver for S32G
SoCs is expected to have at least one node in the device tree. These
patches will undergo review and receive feedback. However, the upstream
process will come to a halt at this point since there are no maintainers
to apply and integrate them. 

I do not know how this situation should be handled, given my lack of
experience in upstreaming maintenance. The documentation for the Linux
kernel is insufficient in providing guidance [2] on how to handle
inactive maintainers and it is unclear who should take over their
responsibilities. This is likely not the first time this has happened in
the kernel's history.

Could you please guide me on how these patches should be integrated into
a maintainer's  tree and by whom?

[0]
https://lore.kernel.org/all/94742ebd-bc3a-4726-9ba7-5954203e4da1@suse.com/
[1]
https://lore.kernel.org/all/372ed255-85b7-4f18-a28e-82e18171f7e3@suse.com/
[2]
https://docs.kernel.org/maintainer/feature-and-driver-maintainers.html#non-compliance

Best regards,
Ghennadi