lkml.org 
[lkml]   [2022]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v3] Documentation/process: Add text to indicate supporters should be mailed
From
On 30/09/2022 15:47, Akira Yokosawa wrote:
> Hi,
>
> On Fri, 30 Sep 2022 07:46:29 +0100, 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.
>
> So the root cause of your confusion was you couldn't figure out
> the fact that "supporter" in the output of get_maintainver.pl means
> "maintainer of a supported subsystem", wasn't it?
>
> I guess all you need would be just a short notice along the lines of:
>
> "supporter" in the output from get_maintainer.pl means "maintainer
> of a supported subsystem".
>
> No?

We discussed that a bit earlier.

https://lore.kernel.org/lkml/20220928003006.230103-1-bryan.odonoghue@linaro.org/T/#u
https://lkml.org/lkml/2022/9/28/1394
https://lkml.org/lkml/2022/9/28/1511
https://lkml.org/lkml/2022/9/29/188

I think its fair to say the consensus so far is to leave the
get_maintainer.pl output as is.

>>
>> Add text to state that every mail address returned by get_maintainer.pl
>> --nogit-fallback should be included when submitting a patch, giving an
>> example of the same.>
>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>> ---
>> Documentation/process/submitting-patches.rst | 12 +++++++++---
>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
>> index be49d8f2601b4..18a1f52e0563a 100644
>> --- a/Documentation/process/submitting-patches.rst
>> +++ b/Documentation/process/submitting-patches.rst
>> @@ -227,9 +227,15 @@ 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@linux-foundation.org) serves as a maintainer of last resort.
>> +your patches as arguments to scripts/get_maintainer.pl). You should mail every
>> +email address returned by `scripts/get_maintainer.pl --nogit-fallback` when
>> +submitting a patch.
>> +For example::
>> +
>> + $ scripts/get_maintainer.pl --nogit-fallback -f submitting-patches.rst
>> + Jonathan Corbet <corbet@lwn.net> (maintainer:DOCUMENTATION)
>> + linux-doc@vger.kernel.org (open list:DOCUMENTATION)
>> + linux-kernel@vger.kernel.org (open list)
>
> This example has a number of issues...
>
> 1) The command line doesn't work when run under the top of kernel tree.

Well I didn't want to exceed 80 characters but I have no problem make it
top level explicit

> 2) The -f flag contradicts the instruction above:
> (pass paths to your *patches* as arguments to scripts/get_maintainer.pl).

I'm not sure I follow how it contradicts but, I will read it again.

> 3) There can be cases where --git-fallback (default) is useful.

Can you elaborate what your thinking is on that. I'm happy to try to
include it in the instructions we give.

> 4) The output can change any time.

What does this mean ? The output won't change for a given patch you are
trying to send.

Do you mean the output of get_maintainer.pl can change ?

It could but, how does that negate the value of documenting what it does
right now ?

> 5) There is no point in using Jon's actual name and email address.

Sure, I see your point. I'll use a fake email.


> Why not just add a short notice I mentioned above as a first step?

Please see above.

---
bod

\
 
 \ /
  Last update: 2022-09-30 18:20    [W:0.073 / U:0.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site