Lines Matching +full:in +full:- +full:and +full:- +full:around
6 At this point, you have followed the guidelines given so far and, with the
9 developers can make is to conclude that their work is now done. In truth,
15 and, as a result, is heavily oriented toward the improvement of posted
18 standards. A failure to participate in this process is quite likely to
23 ----------------------
25 A patch of any significance will result in a number of comments from other
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
34 like to maintain a kernel with this code in it five or ten years later?
35 Many of the changes you may be asked to make - from coding style tweaks
36 to substantial rewrites - come from the understanding that Linux will
37 still be around and under development a decade from now.
39 - Code review is hard work, and it is a relatively thankless occupation;
42 they see the same mistakes being made over and over again. If you get a
44 impulse to respond in kind. Code review is about the code, not about
45 the people, and code reviewers are not attacking you personally.
47 - Similarly, code reviewers are not trying to promote their employers'
54 - Be prepared for seemingly silly requests for coding style changes
55 and requests to factor out some of your code to shared parts of
57 the same. Sometimes this means that the clever hack in your driver
58 to get around a problem actually needs to become a generalized
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.
72 suggested change, describe it and justify your solution to the problem. If
81 in a code change should result in an additional code comment instead; that
83 around.
85 One fatal mistake is to ignore review comments in the hope that they will
90 Speaking of reposting code: please bear in mind that reviewers are not
92 around. So it is always a good idea to remind reviewers of previously
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
104 power tends to be Andrew Morton. Andrew has a great deal of respect in the
107 though, and not before all other alternatives have been explored. And bear
108 in mind, of course, that he may not agree with you either.
112 -----------------
114 If a patch is considered to be a good thing to add to the kernel, and once
118 things. In particular, there may be more than one tree - one, perhaps,
119 dedicated to patches planned for the next merge window, and another for
120 longer-term work.
124 being -mm. Patches which affect multiple subsystems can also end up going
125 through the -mm tree.
129 default. Subsystem trees typically feed linux-next as well, making their
132 reviewers; these comments need to be answered as in the previous round.
135 is that conflicts with work being done by others turn up. In the worst
136 case, heavy patch conflicts can result in some work being put on the back
137 burner so that the remaining patches can be worked into shape and merged.
139 developers and, possibly, moving some patches between trees to ensure that
141 blessings: before the advent of the linux-next tree, these conflicts often
142 only turned up during the merge window and had to be addressed in a hurry.
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
161 how many people will build your code into their kernels. And, of course,
167 unable to fix the regression (and nobody else does it for you), your patch
171 well make it harder for you to get work merged in the future.
175 fix these bugs and ensure that your code's debut in a mainline kernel
176 release is as solid as possible. So, please, answer bug reports, and fix
181 And don't forget that there are other milestones which may also create bug
184 respond to these reports is a matter of basic pride in your work. If that
186 development community remembers developers who lose interest in their code
188 it with the assumption that you will not be around to maintain it
193 -----------------------------
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
199 proper From: line so that the attribution is correct, and add a signoff of
200 your own), or send an Acked-by: response back and let the original poster
206 are opposed by the author and maintainer of the code, but it only goes so
208 eventually flow around you and get into the mainline anyway. In the Linux
213 chances are that one of the two patches will not be merged, and "mine was
215 somebody else's patch displaces yours and gets into the mainline, there is
216 really only one way to respond: be pleased that your problem got solved and
217 get on with your work. Having one's work shoved aside in this manner can
218 be hurtful and discouraging, but the community will remember your reaction