1 .. _development_followthrough:
2
3 Followthrough
4 =============
5
6 At this point, you have followed the guideline
7 addition of your own engineering skills, have
8 patches. One of the biggest mistakes that eve
9 developers can make is to conclude that their
10 posting patches indicates a transition into th
11 with, possibly, quite a bit of work yet to be
12
13 It is a rare patch which is so good at its fir
14 room for improvement. The kernel development
15 and, as a result, is heavily oriented toward t
16 code. You, as the author of that code, will b
17 kernel community to ensure that your code is u
18 standards. A failure to participate in this p
19 prevent the inclusion of your patches into the
20
21
22 Working with reviewers
23 ----------------------
24
25 A patch of any significance will result in a n
26 developers as they review the code. Working w
27 many developers, the most intimidating part of
28 process. Life can be made much easier, though
29 mind:
30
31 - If you have explained your patch well, revi
32 value and why you went to the trouble of wr
33 will not keep them from asking a fundamenta
34 like to maintain a kernel with this code in
35 Many of the changes you may be asked to mak
36 to substantial rewrites - come from the und
37 still be around and under development a dec
38
39 - Code review is hard work, and it is a relat
40 people remember who wrote kernel code, but
41 for those who reviewed it. So reviewers ca
42 they see the same mistakes being made over
43 review which seems angry, insulting, or out
44 impulse to respond in kind. Code review is
45 the people, and code reviewers are not atta
46
47 - Similarly, code reviewers are not trying to
48 agendas at the expense of your own. Kernel
49 be working on the kernel years from now, bu
50 employer could change. They truly are, alm
51 working toward the creation of the best ker
52 trying to create discomfort for their emplo
53
54 - Be prepared for seemingly silly requests fo
55 and requests to factor out some of your cod
56 the kernel. One job the maintainers do is t
57 the same. Sometimes this means that the cle
58 to get around a problem actually needs to b
59 kernel feature ready for next time.
60
61 What all of this comes down to is that, when r
62 you need to pay attention to the technical obs
63 making. Do not let their form of expression o
64 from happening. When you get review comments
65 understand what the reviewer is trying to say.
66 that the reviewer is asking you to fix. And r
67 thank them, and describe how you will answer t
68
69 Note that you do not have to agree with every
70 reviewers. If you believe that the reviewer h
71 explain what is really going on. If you have
72 suggested change, describe it and justify your
73 your explanations make sense, the reviewer wil
74 explanation not prove persuasive, though, espe
75 agree with the reviewer, take some time to thi
76 be easy to become blinded by your own solution
77 that you don't realize that something is funda
78 you're not even solving the right problem.
79
80 Andrew Morton has suggested that every review
81 in a code change should result in an additiona
82 can help future reviewers avoid the questions
83 around.
84
85 One fatal mistake is to ignore review comments
86 go away. They will not go away. If you repos
87 responded to the comments you got the time bef
88 that your patches go nowhere.
89
90 Speaking of reposting code: please bear in min
91 going to remember all the details of the code
92 around. So it is always a good idea to remind
93 raised issues and how you dealt with them; the
94 place for this kind of information. Reviewers
95 through list archives to familiarize themselve
96 time; if you help them get a running start, th
97 when they revisit your code.
98
99 What if you've tried to do everything right an
100 anywhere? Most technical disagreements can be
101 but there are times when somebody simply has t
102 honestly believe that this decision is going a
103 always try appealing to a higher power. As of
104 power tends to be Andrew Morton. Andrew has a
105 kernel development community; he can often unj
106 be hopelessly blocked. Appealing to Andrew sh
107 though, and not before all other alternatives
108 in mind, of course, that he may not agree with
109
110
111 What happens next
112 -----------------
113
114 If a patch is considered to be a good thing to
115 most of the review issues have been resolved,
116 entry into a subsystem maintainer's tree. How
117 subsystem to the next; each maintainer has his
118 things. In particular, there may be more than
119 dedicated to patches planned for the next merg
120 longer-term work.
121
122 For patches applying to areas for which there
123 (memory management patches, for example), the
124 being -mm. Patches which affect multiple subs
125 through the -mm tree.
126
127 Inclusion into a subsystem tree can bring a hi
128 patch. Now other developers working with that
129 default. Subsystem trees typically feed linux
130 contents visible to the development community
131 there's a good chance that you will get more c
132 reviewers; these comments need to be answered
133
134 What may also happen at this point, depending
135 is that conflicts with work being done by othe
136 case, heavy patch conflicts can result in some
137 burner so that the remaining patches can be wo
138 Other times, conflict resolution will involve
139 developers and, possibly, moving some patches
140 everything applies cleanly. This work can be
141 blessings: before the advent of the linux-next
142 only turned up during the merge window and had
143 Now they can be resolved at leisure, before th
144
145 Some day, if all goes well, you'll log on and
146 merged into the mainline kernel. Congratulati
147 complete (and you have added yourself to the M
148 is worth remembering an important little fact:
149 Merging into the mainline brings its own chall
150
151 To begin with, the visibility of your patch ha
152 may be a new round of comments from developers
153 the patch before. It may be tempting to ignor
154 longer any question of your code being merged.
155 though; you still need to be responsive to dev
156 suggestions.
157
158 More importantly, though: inclusion into the m
159 the hands of a much larger group of testers.
160 a driver for hardware which is not yet availab
161 how many people will build your code into thei
162 where there are testers, there will be bug rep
163
164 The worst sort of bug reports are regressions.
165 regression, you'll find an uncomfortable numbe
166 regressions need to be fixed as soon as possib
167 unable to fix the regression (and nobody else
168 will almost certainly be removed during the st
169 negating all of the work you have done to get
170 having a patch pulled as the result of a failu
171 well make it harder for you to get work merged
172
173 After any regressions have been dealt with, th
174 bugs to deal with. The stabilization period i
175 fix these bugs and ensure that your code's deb
176 release is as solid as possible. So, please,
177 the problems if at all possible. That's what
178 for; you can start creating cool new patches o
179 ones have been taken care of.
180
181 And don't forget that there are other mileston
182 reports: the next mainline stable release, whe
183 up a version of the kernel containing your pat
184 respond to these reports is a matter of basic
185 is insufficient motivation, though, it's also
186 development community remembers developers who
187 after it's merged. The next time you post a p
188 it with the assumption that you will not be ar
189 afterward.
190
191
192 Other things that can happen
193 -----------------------------
194
195 One day, you may open your mail client and see
196 a patch to your code. That is one of the adva
197 out there in the open, after all. If you agre
198 either forward it on to the subsystem maintain
199 proper From: line so that the attribution is c
200 your own), or send an Acked-by: response back
201 send it upward.
202
203 If you disagree with the patch, send a polite
204 possible, tell the author what changes need to
205 acceptable to you. There is a certain resista
206 are opposed by the author and maintainer of th
207 far. If you are seen as needlessly blocking g
208 eventually flow around you and get into the ma
209 kernel, nobody has absolute veto power over an
210
211 On very rare occasion, you may see something c
212 developer posts a different solution to your p
213 chances are that one of the two patches will n
214 here first" is not considered to be a compelli
215 somebody else's patch displaces yours and gets
216 really only one way to respond: be pleased tha
217 get on with your work. Having one's work shov
218 be hurtful and discouraging, but the community
219 long after they have forgotten whose patch act
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.