linux-kernel - Re: [PATCH] Documentation/process: Add text to indicate supporters should be mailed

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, 28 Sep 2022 12:48:50 +0100
From:   Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To:     Thorsten Leemhuis <linux@...mhuis.info>, corbet@....net,
        konstantin@...uxfoundation.org, krzysztof.kozlowski@...aro.org,
        linux-doc@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Documentation/process: Add text to indicate supporters
 should be mailed

On 28/09/2022 05:34, Thorsten Leemhuis wrote:
> On 28.09.22 02:30, Bryan O'Donoghue wrote:
>> Recently when submitting a yaml change I found that I had omitted the
>> maintainer whose tree the change needed to go through.
>>
>> The reason for that is the path in MAINTAINERS is marked as Supported not
>> Maintained. Reading MAINTAINERS we see quote:
>>
>>             Supported:   Someone is actually paid to look after this.
>>             Maintained:  Someone actually looks after it.
>>
>> The current submitting-patches.rst only says to mail maintainers though not
>> supporters. When we run scripts/get_maintainer.pl anybody who is denoted a
>> paid maintainer will appear as a supporter.
>>
>> Let's add some text to the submitting-patches.rst to indicate that
>> supporters should similarly be mailed so that you can't do as I did and
>> mail every maintainer get_maintainer.pl tells you to, without actually
>> mailing the one supporter you need to.
>>
>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
> 
> Looks good to me, but while at it, one quick question: Would
> Documentation/process/5.Posting.rst (which sadly covers exactly the same
> topic) benefit from a similar clarification, even if it doesn't mention
> get_maintainers explicitly?

Yes.

> Which leads to two other question: Are there any other places that might
> benefit from such a clarification? Or would it be even make sense to
> change the format of MAINTAINERS to avoid the problem in the first
> place? Maybe something like "Maintained(v)" (Someone volunteered to look
> after it in spare hours.) and "Maintained(p)" (Someone is actually paid
> to look after this.). Ahh, no, that doesn't look good. But you get the idea.

We could update get_maintainer to print out something else

such as

scripts/get_maintainer.pl 
Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml

Andy Gross <agross@...nel.org> (maintainer:ARM/QUALCOMM SUPPORT)
Bjorn Andersson <bjorn.andersson@...aro.org> (maintainer:ARM/QUALCOMM 
SUPPORT)
Konrad Dybcio <konrad.dybcio@...ainline.org> (reviewer:ARM/QUALCOMM SUPPORT)
Lee Jones <lee@...nel.org> (maintainer-supporter:MULTIFUNCTION DEVICES 
(MFD))

or say

scripts/get_maintainer.pl 
Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
Andy Gross <agross@...nel.org> (maintainer:ARM/QUALCOMM SUPPORT)
Bjorn Andersson <bjorn.andersson@...aro.org> (maintainer:ARM/QUALCOMM 
SUPPORT)
Konrad Dybcio <konrad.dybcio@...ainline.org> (reviewer:ARM/QUALCOMM SUPPORT)
Lee Jones <lee@...nel.org> (supporting-maintainer:MULTIFUNCTION DEVICES 
(MFD))

it would be less churn but, I still think we would need to update the 
documentation to be very explicit that "supporting-maintainer or 
maintainer" needs to be emailed with your patch so that sufficiently 
talented idiots such as myself, know who to mail.

Although thinking about it we would be introducing yet another term 
"supporting-maintainer" to which people would say "what is that"

Feels a little less confusing to me to leave supporter as-is and just 
document expectations for patch submission better.

>> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
>> index be49d8f2601b4..5f97379da41da 100644
>> --- a/Documentation/process/submitting-patches.rst
>> +++ b/Documentation/process/submitting-patches.rst
>> @@ -227,9 +227,11 @@ You should always copy the appropriate subsystem maintainer(s) on any patch
>>   to code that they maintain; look through the MAINTAINERS file and the
>>   source code revision history to see who those maintainers are.  The
>>   script scripts/get_maintainer.pl can be very useful at this step (pass paths to
>> -your patches as arguments to scripts/get_maintainer.pl).  If you cannot find a
>> -maintainer for the subsystem you are working on, Andrew Morton
>> -(akpm@...ux-foundation.org) serves as a maintainer of last resort.
>> +your patches as arguments to scripts/get_maintainer.pl).  You should mail
>> +everyone who appears as "maintainer" or "supporter" in the
>> +scripts/get_maintainer.pl output.
> 
> Side note and bikeshedding: Not sure, I wonder if the 'in the
> scripts/get_maintainer.pl output' can be dropped to make things shorter.
> Or maybe even shorter along the lines of 'Mail everyone listed as
> "maintainer" or "supporter"'?
> 
> Whatever, not that important.

Sure NP.

---
bod