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]

Date: Thu, 22 Feb 2024 12:13:39 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Ghennadi Procopciuc <ghennadi.procopciuc@....nxp.com>,
 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 21/02/2024 18:00, Ghennadi Procopciuc wrote:
> 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.

Just give it some time...

> 
> 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. 

Indeed that's a problem.

> 
> 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?

Chester left Suse, so maybe this also means less interest in maintaining
it? Stepping up in such case, so your proposal, is reasonable, so in
general I agree and thank you for trying to do something here.

Andreas or Matthias,
Maybe you could change your R: into M: and take s32g patches?

If not, then I will ack this patch making Ghennadi the maintainer.

Best regards,
Krzysztof