summaryrefslogtreecommitdiff
path: root/MAINTAINERS
diff options
context:
space:
mode:
authorJakub Kicinski <kuba@kernel.org>2023-06-30 20:15:50 +0300
committerJonathan Corbet <corbet@lwn.net>2023-07-03 17:35:23 +0300
commitb45d8f3871574999002b79d551cac51a20bcfae6 (patch)
treeb043bd89a349372e20eefebe2c97ece9d160401d /MAINTAINERS
parentc398488dab7d731f942da9f34981b536fe187e3f (diff)
downloadlinux-b45d8f3871574999002b79d551cac51a20bcfae6.tar.xz
docs: remove the tips on how to submit patches from MAINTAINERS
Having "how to submit patches" in MAINTAINTERS seems out of place. We have a whole section of documentation about it, duplication is harmful and a lot of the text looks really out of date. Sections 1, 2 and 4 look really, really old and not applicable to the modern process. Section 3 is obvious but also we have build bots now. Section 5 is a bit outdated (diff -u?!). But I like the part about factoring out shared code, so add that to process docs. Section 6 is unnecessary? Section 7 is covered by more appropriate docs. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20230630171550.128296-1-kuba@kernel.org>
Diffstat (limited to 'MAINTAINERS')
-rw-r--r--MAINTAINERS80
1 files changed, 2 insertions, 78 deletions
diff --git a/MAINTAINERS b/MAINTAINERS
index a73486c4aa6e..f73316d4ff34 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1,81 +1,5 @@
-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@kernel.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/process/security-bugs.rst for details.
-
-8. Happy hacking.
+List of maintainers
+===================
Descriptions of section entries and preferred order
---------------------------------------------------