diff options
author | Jakub Kicinski <kuba@kernel.org> | 2023-06-30 20:15:50 +0300 |
---|---|---|
committer | Jonathan Corbet <corbet@lwn.net> | 2023-07-03 17:35:23 +0300 |
commit | b45d8f3871574999002b79d551cac51a20bcfae6 (patch) | |
tree | b043bd89a349372e20eefebe2c97ece9d160401d /Documentation | |
parent | c398488dab7d731f942da9f34981b536fe187e3f (diff) | |
download | linux-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 'Documentation')
-rw-r--r-- | Documentation/process/6.Followthrough.rst | 7 |
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 |