From b45d8f3871574999002b79d551cac51a20bcfae6 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Fri, 30 Jun 2023 10:15:50 -0700 Subject: 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 Reviewed-by: Randy Dunlap Reviewed-by: Dan Williams Reviewed-by: Kees Cook Signed-off-by: Jonathan Corbet Message-ID: <20230630171550.128296-1-kuba@kernel.org> --- MAINTAINERS | 80 ++----------------------------------------------------------- 1 file changed, 2 insertions(+), 78 deletions(-) (limited to 'MAINTAINERS') 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 --------------------------------------------------- -- cgit v1.2.3