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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <21f8d79a-0ad4-b28b-15d8-f4be0cfd9730@gmail.com>
Date:   Fri, 30 Sep 2022 23:47:48 +0900
From:   Akira Yokosawa <akiyks@...il.com>
To:     Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Cc:     corbet@....net, konstantin@...uxfoundation.org,
        krzysztof.kozlowski@...aro.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux@...mhuis.info, tytso@....edu,
        Akira Yokosawa <akiyks@...il.com>
Subject: Re: [PATCH v3] Documentation/process: Add text to indicate supporters
 should be mailed

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?

> 
> 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@...aro.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@...ux-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@....net> (maintainer:DOCUMENTATION)
> +    linux-doc@...r.kernel.org (open list:DOCUMENTATION)
> +    linux-kernel@...r.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.
 2) The -f flag contradicts the instruction above:
    (pass paths to your *patches* as arguments to scripts/get_maintainer.pl).
 3) There can be cases where --git-fallback (default) is useful.
 4) The output can change any time.
 5) There is no point in using Jon's actual name and email address.

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

Please take your time before sending out v4 to make sure your change
will improve things.

Regards,
Akira

>  
>  You should also normally choose at least one mailing list to receive a copy
>  of your patch set.  linux-kernel@...r.kernel.org should be used by default

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ