summaryrefslogtreecommitdiff
path: root/Documentation/process
diff options
context:
space:
mode:
authorJakub Kicinski <kuba@kernel.org>2023-06-30 10:15:50 -0700
committerJonathan Corbet <corbet@lwn.net>2023-07-03 08:35:23 -0600
commitb45d8f3871574999002b79d551cac51a20bcfae6 (patch)
treeb043bd89a349372e20eefebe2c97ece9d160401d /Documentation/process
parentc398488dab7d731f942da9f34981b536fe187e3f (diff)
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 'Documentation/process')
-rw-r--r--Documentation/process/6.Followthrough.rst7
1 files changed, 7 insertions, 0 deletions
diff --git a/Documentation/process/6.Followthrough.rst b/Documentation/process/6.Followthrough.rst
index a173cd5f93d2..66fa400c6d94 100644
--- a/Documentation/process/6.Followthrough.rst
+++ b/Documentation/process/6.Followthrough.rst
@@ -51,6 +51,13 @@ mind:
working toward the creation of the best kernel they can; they are not
trying to create discomfort for their employers' competitors.
+ - Be prepared for seemingly silly requests for coding style changes
+ and requests to factor out some of your code to shared parts of
+ the kernel. One job the maintainers 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.
+
What all of this comes down to is that, when reviewers send you comments,
you need to pay attention to the technical observations that they are
making. Do not let their form of expression or your own pride keep that