Documentation/process/6.Followthrough.rst

6 At this point, you have followed the guidelines given so far and, with the
28 process.  Life can be made much easier, though, if you keep a few things in
31  - If you have explained your patch well, reviewers will understand its
32    value and why you went to the trouble of writing it.  But that value
35    Many of the changes you may be asked to make - from coding style tweaks
42    they see the same mistakes being made over and over again.  If you get a
45    the people, and code reviewers are not attacking you personally.
61 What all of this comes down to is that, when reviewers send you comments,
62 you need to pay attention to the technical observations that they are
64 from happening.  When you get review comments on a patch, take the time to
66 that the reviewer is asking you to fix.  And respond back to the reviewer:
67 thank them, and describe how you will answer their questions.
69 Note that you do not have to agree with every change suggested by
70 reviewers.  If you believe that the reviewer has misunderstood your code,
71 explain what is really going on.  If you have a technical objection to a
77 that you don't realize that something is fundamentally wrong or, perhaps,
78 you're not even solving the right problem.
86 go away.  They will not go away.  If you repost code without having
87 responded to the comments you got the time before, you're likely to find
91 going to remember all the details of the code you posted the last time
93 raised issues and how you dealt with them; the patch changelog is a good
96 time; if you help them get a running start, they will be in a better mood
99 What if you've tried to do everything right and things still aren't going
101 but there are times when somebody simply has to make a decision.  If you
102 honestly believe that this decision is going against you wrongly, you can
108 in mind, of course, that he may not agree with you either.
131 there's a good chance that you will get more comments from a new set of
145 Some day, if all goes well, you'll log on and see that your patch has been
147 complete (and you have added yourself to the MAINTAINERS file), though, it
155 though; you still need to be responsive to developers who have questions or
159 the hands of a much larger group of testers.  Even if you have contributed
160 a driver for hardware which is not yet available, you will be surprised by
165 regression, you'll find an uncomfortable number of eyes upon you;
166 regressions need to be fixed as soon as possible.  If you are unwilling or
167 unable to fix the regression (and nobody else does it for you), your patch
169 negating all of the work you have done to get your patch into the mainline,
171 well make it harder for you to get work merged in the future.
178 for; you can start creating cool new patches once any problems with the old
187 after it's merged.  The next time you post a patch, they will be evaluating
188 it with the assumption that you will not be around to maintain it
195 One day, you may open your mail client and see that somebody has mailed you
197 out there in the open, after all.  If you agree with the patch, you can
203 If you disagree with the patch, send a polite response explaining why.  If
205 acceptable to you.  There is a certain resistance to merging patches which
207 far.  If you are seen as needlessly blocking good work, those patches will
208 eventually flow around you and get into the mainline anyway.  In the Linux
211 On very rare occasion, you may see something completely different: another