linux/Documentation/development-process/6.Followthrough
<<
>>
Prefs
   16: FOLLOWTHROUGH
   2
   3At this point, you have followed the guidelines given so far and, with the
   4addition of your own engineering skills, have posted a perfect series of
   5patches.  One of the biggest mistakes that even experienced kernel
   6developers can make is to conclude that their work is now done.  In truth,
   7posting patches indicates a transition into the next stage of the process,
   8with, possibly, quite a bit of work yet to be done.
   9
  10It is a rare patch which is so good at its first posting that there is no
  11room for improvement.  The kernel development process recognizes this fact,
  12and, as a result, is heavily oriented toward the improvement of posted
  13code.  You, as the author of that code, will be expected to work with the
  14kernel community to ensure that your code is up to the kernel's quality
  15standards.  A failure to participate in this process is quite likely to
  16prevent the inclusion of your patches into the mainline.
  17
  18
  196.1: WORKING WITH REVIEWERS
  20
  21A patch of any significance will result in a number of comments from other
  22developers as they review the code.  Working with reviewers can be, for
  23many developers, the most intimidating part of the kernel development
  24process.  Life can be made much easier, though, if you keep a few things in
  25mind:
  26
  27 - If you have explained your patch well, reviewers will understand its
  28   value and why you went to the trouble of writing it.  But that value
  29   will not keep them from asking a fundamental question: what will it be
  30   like to maintain a kernel with this code in it five or ten years later?
  31   Many of the changes you may be asked to make - from coding style tweaks
  32   to substantial rewrites - come from the understanding that Linux will
  33   still be around and under development a decade from now.
  34
  35 - Code review is hard work, and it is a relatively thankless occupation;
  36   people remember who wrote kernel code, but there is little lasting fame
  37   for those who reviewed it.  So reviewers can get grumpy, especially when
  38   they see the same mistakes being made over and over again.  If you get a
  39   review which seems angry, insulting, or outright offensive, resist the
  40   impulse to respond in kind.  Code review is about the code, not about
  41   the people, and code reviewers are not attacking you personally.
  42
  43 - Similarly, code reviewers are not trying to promote their employers'
  44   agendas at the expense of your own.  Kernel developers often expect to
  45   be working on the kernel years from now, but they understand that their
  46   employer could change.  They truly are, almost without exception,
  47   working toward the creation of the best kernel they can; they are not
  48   trying to create discomfort for their employers' competitors.
  49
  50What all of this comes down to is that, when reviewers send you comments,
  51you need to pay attention to the technical observations that they are
  52making.  Do not let their form of expression or your own pride keep that
  53from happening.  When you get review comments on a patch, take the time to
  54understand what the reviewer is trying to say.  If possible, fix the things
  55that the reviewer is asking you to fix.  And respond back to the reviewer:
  56thank them, and describe how you will answer their questions.
  57
  58Note that you do not have to agree with every change suggested by
  59reviewers.  If you believe that the reviewer has misunderstood your code,
  60explain what is really going on.  If you have a technical objection to a
  61suggested change, describe it and justify your solution to the problem.  If
  62your explanations make sense, the reviewer will accept them.  Should your
  63explanation not prove persuasive, though, especially if others start to
  64agree with the reviewer, take some time to think things over again.  It can
  65be easy to become blinded by your own solution to a problem to the point
  66that you don't realize that something is fundamentally wrong or, perhaps,
  67you're not even solving the right problem.
  68
  69Andrew Morton has suggested that every review comment which does not result
  70in a code change should result in an additional code comment instead; that
  71can help future reviewers avoid the questions which came up the first time
  72around.
  73
  74One fatal mistake is to ignore review comments in the hope that they will
  75go away.  They will not go away.  If you repost code without having
  76responded to the comments you got the time before, you're likely to find
  77that your patches go nowhere.
  78
  79Speaking of reposting code: please bear in mind that reviewers are not
  80going to remember all the details of the code you posted the last time
  81around.  So it is always a good idea to remind reviewers of previously
  82raised issues and how you dealt with them; the patch changelog is a good
  83place for this kind of information.  Reviewers should not have to search
  84through list archives to familiarize themselves with what was said last
  85time; if you help them get a running start, they will be in a better mood
  86when they revisit your code.
  87
  88What if you've tried to do everything right and things still aren't going
  89anywhere?  Most technical disagreements can be resolved through discussion,
  90but there are times when somebody simply has to make a decision.  If you
  91honestly believe that this decision is going against you wrongly, you can
  92always try appealing to a higher power.  As of this writing, that higher
  93power tends to be Andrew Morton.  Andrew has a great deal of respect in the
  94kernel development community; he can often unjam a situation which seems to
  95be hopelessly blocked.  Appealing to Andrew should not be done lightly,
  96though, and not before all other alternatives have been explored.  And bear
  97in mind, of course, that he may not agree with you either.
  98
  99
 1006.2: WHAT HAPPENS NEXT
 101
 102If a patch is considered to be a good thing to add to the kernel, and once
 103most of the review issues have been resolved, the next step is usually
 104entry into a subsystem maintainer's tree.  How that works varies from one
 105subsystem to the next; each maintainer has his or her own way of doing
 106things.  In particular, there may be more than one tree - one, perhaps,
 107dedicated to patches planned for the next merge window, and another for
 108longer-term work.
 109
 110For patches applying to areas for which there is no obvious subsystem tree
 111(memory management patches, for example), the default tree often ends up
 112being -mm.  Patches which affect multiple subsystems can also end up going
 113through the -mm tree.
 114
 115Inclusion into a subsystem tree can bring a higher level of visibility to a
 116patch.  Now other developers working with that tree will get the patch by
 117default.  Subsystem trees typically feed linux-next as well, making their
 118contents visible to the development community as a whole.  At this point,
 119there's a good chance that you will get more comments from a new set of
 120reviewers; these comments need to be answered as in the previous round.
 121
 122What may also happen at this point, depending on the nature of your patch,
 123is that conflicts with work being done by others turn up.  In the worst
 124case, heavy patch conflicts can result in some work being put on the back
 125burner so that the remaining patches can be worked into shape and merged.
 126Other times, conflict resolution will involve working with the other
 127developers and, possibly, moving some patches between trees to ensure that
 128everything applies cleanly.  This work can be a pain, but count your
 129blessings: before the advent of the linux-next tree, these conflicts often
 130only turned up during the merge window and had to be addressed in a hurry.
 131Now they can be resolved at leisure, before the merge window opens.
 132
 133Some day, if all goes well, you'll log on and see that your patch has been
 134merged into the mainline kernel.  Congratulations!  Once the celebration is
 135complete (and you have added yourself to the MAINTAINERS file), though, it
 136is worth remembering an important little fact: the job still is not done.
 137Merging into the mainline brings its own challenges.
 138
 139To begin with, the visibility of your patch has increased yet again.  There
 140may be a new round of comments from developers who had not been aware of
 141the patch before.  It may be tempting to ignore them, since there is no
 142longer any question of your code being merged.  Resist that temptation,
 143though; you still need to be responsive to developers who have questions or
 144suggestions.
 145
 146More importantly, though: inclusion into the mainline puts your code into
 147the hands of a much larger group of testers.  Even if you have contributed
 148a driver for hardware which is not yet available, you will be surprised by
 149how many people will build your code into their kernels.  And, of course,
 150where there are testers, there will be bug reports.
 151
 152The worst sort of bug reports are regressions.  If your patch causes a
 153regression, you'll find an uncomfortable number of eyes upon you;
 154regressions need to be fixed as soon as possible.  If you are unwilling or
 155unable to fix the regression (and nobody else does it for you), your patch
 156will almost certainly be removed during the stabilization period.  Beyond
 157negating all of the work you have done to get your patch into the mainline,
 158having a patch pulled as the result of a failure to fix a regression could
 159well make it harder for you to get work merged in the future.
 160
 161After any regressions have been dealt with, there may be other, ordinary
 162bugs to deal with.  The stabilization period is your best opportunity to
 163fix these bugs and ensure that your code's debut in a mainline kernel
 164release is as solid as possible.  So, please, answer bug reports, and fix
 165the problems if at all possible.  That's what the stabilization period is
 166for; you can start creating cool new patches once any problems with the old
 167ones have been taken care of.
 168
 169And don't forget that there are other milestones which may also create bug
 170reports: the next mainline stable release, when prominent distributors pick
 171up a version of the kernel containing your patch, etc.  Continuing to
 172respond to these reports is a matter of basic pride in your work.  If that
 173is insufficient motivation, though, it's also worth considering that the
 174development community remembers developers who lose interest in their code
 175after it's merged.  The next time you post a patch, they will be evaluating
 176it with the assumption that you will not be around to maintain it
 177afterward.
 178
 179
 1806.3: OTHER THINGS THAT CAN HAPPEN
 181
 182One day, you may open your mail client and see that somebody has mailed you
 183a patch to your code.  That is one of the advantages of having your code
 184out there in the open, after all.  If you agree with the patch, you can
 185either forward it on to the subsystem maintainer (be sure to include a
 186proper From: line so that the attribution is correct, and add a signoff of
 187your own), or send an Acked-by: response back and let the original poster
 188send it upward.
 189
 190If you disagree with the patch, send a polite response explaining why.  If
 191possible, tell the author what changes need to be made to make the patch
 192acceptable to you.  There is a certain resistance to merging patches which
 193are opposed by the author and maintainer of the code, but it only goes so
 194far.  If you are seen as needlessly blocking good work, those patches will
 195eventually flow around you and get into the mainline anyway.  In the Linux
 196kernel, nobody has absolute veto power over any code.  Except maybe Linus.
 197
 198On very rare occasion, you may see something completely different: another
 199developer posts a different solution to your problem.  At that point,
 200chances are that one of the two patches will not be merged, and "mine was
 201here first" is not considered to be a compelling technical argument.  If
 202somebody else's patch displaces yours and gets into the mainline, there is
 203really only one way to respond: be pleased that your problem got solved and
 204get on with your work.  Having one's work shoved aside in this manner can
 205be hurtful and discouraging, but the community will remember your reaction
 206long after they have forgotten whose patch actually got merged.
 207
lxr.linux.no kindly hosted by Redpill Linpro AS, provider of Linux consulting and operations services since 1995.