Messages in this thread | | | Date | Fri, 30 Sep 2022 17:18:52 +0100 | Subject | Re: [PATCH v3] Documentation/process: Add text to indicate supporters should be mailed | From | Bryan O'Donoghue <> |
| |
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
| |