Documentation/process/6.Followthrough.rst

Source file repositories/reference/linux-study-clean/Documentation/process/6.Followthrough.rst

File Facts

System
Linux kernel
Corpus path
Documentation/process/6.Followthrough.rst
Extension
.rst
Size
12444 bytes
Lines
220
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. _development_followthrough:

Followthrough
=============

At this point, you have followed the guidelines given so far and, with the
addition of your own engineering skills, have posted a perfect series of
patches.  One of the biggest mistakes that even experienced kernel
developers can make is to conclude that their work is now done.  In truth,
posting patches indicates a transition into the next stage of the process,
with, possibly, quite a bit of work yet to be done.

It is a rare patch which is so good at its first posting that there is no
room for improvement.  The kernel development process recognizes this fact,
and, as a result, is heavily oriented toward the improvement of posted
code.  You, as the author of that code, will be expected to work with the
kernel community to ensure that your code is up to the kernel's quality
standards.  A failure to participate in this process is quite likely to
prevent the inclusion of your patches into the mainline.


Working with reviewers
----------------------

A patch of any significance will result in a number of comments from other
developers as they review the code.  Working with reviewers can be, for
many developers, the most intimidating part of the kernel development
process.  Life can be made much easier, though, if you keep a few things in
mind:

 - If you have explained your patch well, reviewers will understand its
   value and why you went to the trouble of writing it.  But that value
   will not keep them from asking a fundamental question: what will it be
   like to maintain a kernel with this code in it five or ten years later?
   Many of the changes you may be asked to make - from coding style tweaks
   to substantial rewrites - come from the understanding that Linux will
   still be around and under development a decade from now.

 - Code review is hard work, and it is a relatively thankless occupation;
   people remember who wrote kernel code, but there is little lasting fame
   for those who reviewed it.  So reviewers can get grumpy, especially when
   they see the same mistakes being made over and over again.  If you get a
   review which seems angry, insulting, or outright offensive, resist the
   impulse to respond in kind.  Code review is about the code, not about
   the people, and code reviewers are not attacking you personally.

 - Similarly, code reviewers are not trying to promote their employers'
   agendas at the expense of your own.  Kernel developers often expect to
   be working on the kernel years from now, but they understand that their
   employer could change.  They truly are, almost without exception,
   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
from happening.  When you get review comments on a patch, take the time to
understand what the reviewer is trying to say.  If possible, fix the things
that the reviewer is asking you to fix.  And respond back to the reviewer:
thank them, and describe how you will answer their questions.

Note that you do not have to agree with every change suggested by
reviewers.  If you believe that the reviewer has misunderstood your code,

Annotation

Implementation Notes