]> git.proxmox.com Git - mirror_ubuntu-kernels.git/commitdiff
Documentation/process: use scripts/get_maintainer.pl on patches
authorKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Wed, 27 Apr 2022 18:56:45 +0000 (20:56 +0200)
committerJonathan Corbet <corbet@lwn.net>
Mon, 9 May 2022 22:12:16 +0000 (16:12 -0600)
Explain that, when collecting list of people to Cc the patch,
scripts/get_maintainer.pl should be used on patches, not on the
directories.  The behavior is quite different, because with "-f" on
a directory, the maintainers of individual files will not be shown.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220427185645.677039-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Documentation/doc-guide/contributing.rst
Documentation/process/3.Early-stage.rst
Documentation/process/submitting-patches.rst

index 207fd93d7c807916b7a731524b30c6c9cb8b44e0..d4793826ad9a050111c1bb8acdc8f1f156f63bb3 100644 (file)
@@ -79,8 +79,9 @@ simplistic idea of what C comment blocks look like.  This problem had been
 present since that comment was added in 2016 — a full four years.  Fixing
 it was a matter of adding the missing asterisks.  A quick look at the
 history for that file showed what the normal format for subject lines is,
-and ``scripts/get_maintainer.pl`` told me who should receive it.  The
-resulting patch looked like this::
+and ``scripts/get_maintainer.pl`` told me who should receive it (pass paths to
+your patches as arguments to scripts/get_maintainer.pl).  The resulting patch
+looked like this::
 
   [PATCH] PM / devfreq: Fix two malformed kerneldoc comments
 
index 6bfd60d77d1adc5fa424e1733991c80340bbcf85..894a920041c6246a79aae2de37f755e871e38639 100644 (file)
@@ -154,10 +154,11 @@ that the kernel developers have added a script to ease the process:
 This script will return the current maintainer(s) for a given file or
 directory when given the "-f" option.  If passed a patch on the
 command line, it will list the maintainers who should probably receive
-copies of the patch.  There are a number of options regulating how hard
-get_maintainer.pl will search for maintainers; please be careful about
-using the more aggressive options as you may end up including developers
-who have no real interest in the code you are modifying.
+copies of the patch.  This is the preferred way (unlike "-f" option) to get the
+list of people to Cc for your patches.  There are a number of options
+regulating how hard get_maintainer.pl will search for maintainers; please be
+careful about using the more aggressive options as you may end up including
+developers who have no real interest in the code you are modifying.
 
 If all else fails, talking to Andrew Morton can be an effective way to
 track down a maintainer for a specific piece of code.
index bf5ead743ccfc1ff345b1b3b74203016ae9d15a3..a1cb6280fbcf4e1e563ec59c9330a41490754ff2 100644 (file)
@@ -227,9 +227,10 @@ Select the recipients for your patch
 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.  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.
+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.
 
 You should also normally choose at least one mailing list to receive a copy
 of your patch set.  linux-kernel@vger.kernel.org should be used by default