Date:   Thu, 28 Jul 2022 09:47:24 -0600
From:   Jonathan Corbet <corbet@....net>
To:     Bagas Sanjaya <bagasdotme@...il.com>, linux-doc@...r.kernel.org
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Thorsten Leemhuis <linux@...mhuis.info>,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Hannu Hartikainen <hannu@...k.in>,
        Jiri Kosina <jkosina@...e.cz>, Miguel Ojeda <ojeda@...nel.org>,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>,
        linux-kernel@...r.kernel.org, Bagas Sanjaya <bagasdotme@...il.com>
Subject: Re: [PATCH] MAINTAINERS: remove outdated patch submission guidelines

Bagas Sanjaya <bagasdotme@...il.com> writes:

> The patch submission guidelines in MAINTAINERS are redundant, since
> submitting-patches does the job and more up-to-date to current kernel
> development process.
>
> Remove the guidelines, while also move trivial patch suggestion to
> submitting-patches.
>
> Signed-off-by: Bagas Sanjaya <bagasdotme@...il.com>
> ---
>  Documentation/process/submitting-patches.rst |  4 +-
>  MAINTAINERS                                  | 78 +-------------------
>  2 files changed, 6 insertions(+), 76 deletions(-)

So I'm generally in favor of this change, but ...

> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index a1cb6280fbcf4e..bb720c057de7d7 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -15,7 +15,9 @@ Documentation/process/submit-checklist.rst
>  for a list of items to check before submitting code.  If you are submitting
>  a driver, also read Documentation/process/submitting-drivers.rst; for device
>  tree binding patches, read

This won't apply - submitting-drivers.rst is gone.

> -Documentation/devicetree/bindings/submitting-patches.rst.
> +Documentation/devicetree/bindings/submitting-patches.rst. Not all suggestions
> +presented here matter on every patch (including trivial ones), so apply
> +some common sense.
>  
>  This documentation assumes that you're using ``git`` to prepare your patches.
>  If you're unfamiliar with ``git``, you would be well-advised to learn how to
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 64379c699903bc..8d668a0ec903e4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1,81 +1,9 @@
>  List of maintainers and how to submit kernel changes
>  ====================================================
>  
> -Please try to follow the guidelines below.  This will make things
> -easier on the maintainers.  Not all of these guidelines matter for every
> -trivial patch so apply some common sense.
> -
> -Tips for patch submitters
> --------------------------
> -
> -1.	Always *test* your changes, however small, on at least 4 or
> -	5 people, preferably many more.
> -
> -2.	Try to release a few ALPHA test versions to the net. Announce
> -	them onto the kernel channel and await results. This is especially
> -	important for device drivers, because often that's the only way
> -	you will find things like the fact version 3 firmware needs
> -	a magic fix you didn't know about, or some clown changed the
> -	chips on a board and not its name.  (Don't laugh!  Look at the
> -	SMC etherpower for that.)
> -
> -3.	Make sure your changes compile correctly in multiple
> -	configurations. In particular check that changes work both as a
> -	module and built into the kernel.
> -
> -4.	When you are happy with a change make it generally available for
> -	testing and await feedback.
> -
> -5.	Make a patch available to the relevant maintainer in the list. Use
> -	``diff -u`` to make the patch easy to merge. Be prepared to get your
> -	changes sent back with seemingly silly requests about formatting
> -	and variable names.  These aren't as silly as they seem. One
> -	job the maintainers (and especially Linus) do is to keep things
> -	looking the same. Sometimes this means that the clever hack in
> -	your driver to get around a problem actually needs to become a
> -	generalized kernel feature ready for next time.
> -
> -	PLEASE check your patch with the automated style checker
> -	(scripts/checkpatch.pl) to catch trivial style violations.
> -	See Documentation/process/coding-style.rst for guidance here.
> -
> -	PLEASE CC: the maintainers and mailing lists that are generated
> -	by ``scripts/get_maintainer.pl.`` The results returned by the
> -	script will be best if you have git installed and are making
> -	your changes in a branch derived from Linus' latest git tree.
> -	See Documentation/process/submitting-patches.rst for details.
> -
> -	PLEASE try to include any credit lines you want added with the
> -	patch. It avoids people being missed off by mistake and makes
> -	it easier to know who wants adding and who doesn't.
> -
> -	PLEASE document known bugs. If it doesn't work for everything
> -	or does something very odd once a month document it.
> -
> -	PLEASE remember that submissions must be made under the terms
> -	of the Linux Foundation certificate of contribution and should
> -	include a Signed-off-by: line.  The current version of this
> -	"Developer's Certificate of Origin" (DCO) is listed in the file
> -	Documentation/process/submitting-patches.rst.
> -
> -6.	Make sure you have the right to send any changes you make. If you
> -	do changes at work you may find your employer owns the patch
> -	not you.
> -
> -7.	When sending security related changes or reports to a maintainer
> -	please Cc: security@...nel.org, especially if the maintainer
> -	does not respond. Please keep in mind that the security team is
> -	a small set of people who can be efficient only when working on
> -	verified bugs. Please only Cc: this list when you have identified
> -	that the bug would present a short-term risk to other users if it
> -	were publicly disclosed. For example, reports of address leaks do
> -	not represent an immediate threat and are better handled publicly,
> -	and ideally, should come with a patch proposal. Please do not send
> -	automated reports to this list either. Such bugs will be handled
> -	better and faster in the usual public places. See
> -	Documentation/admin-guide/security-bugs.rst for details.
> -
> -8.	Happy hacking.
> +If you'd like to submit kernel changes (patches), refer to
> +:ref:`submittingpatches` for the guidelines, and
> +:ref:`development_process_main` for detailed guide on development process.

Let's not put RST directives into MAINTAINERS, which isn't an RST file.
Just mention Documentation/whatever and all will be good.

Thanks,

jon

Powered by blists - more mailing lists