Lines Matching full:that
8 patches. One of the biggest mistakes that even experienced kernel
9 developers can make is to conclude that their work is now done. In truth,
13 It is a rare patch which is so good at its first posting that there is no
16 code. You, as the author of that code, will be expected to work with the
17 kernel community to ensure that your code is up to the kernel's quality
32 value and why you went to the trouble of writing it. But that value
36 to substantial rewrites - come from the understanding that Linux will
49 be working on the kernel years from now, but they understand that their
57 the same. Sometimes this means that the clever hack in your driver
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
63 making. Do not let their form of expression or your own pride keep that
66 that the reviewer is asking you to fix. And respond back to the reviewer:
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,
77 that you don't realize that something is fundamentally wrong or, perhaps,
80 Andrew Morton has suggested that every review comment which does not result
81 in a code change should result in an additional code comment instead; that
85 One fatal mistake is to ignore review comments in the hope that they will
88 that your patches go nowhere.
90 Speaking of reposting code: please bear in mind that reviewers are not
102 honestly believe that this decision is going against you wrongly, you can
103 always try appealing to a higher power. As of this writing, that higher
108 in mind, of course, that he may not agree with you either.
116 entry into a subsystem maintainer's tree. How that works varies from one
128 patch. Now other developers working with that tree will get the patch by
131 there's a good chance that you will get more comments from a new set of
135 is that conflicts with work being done by others turn up. In the worst
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
145 Some day, if all goes well, you'll log on and see that your patch has been
154 longer any question of your code being merged. Resist that temptation,
175 fix these bugs and ensure that your code's debut in a mainline kernel
177 the problems if at all possible. That's what the stabilization period is
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
185 is insufficient motivation, though, it's also worth considering that the
188 it with the assumption that you will not be around to maintain it
192 Other things that can happen
195 One day, you may open your mail client and see that somebody has mailed you
196 a patch to your code. That is one of the advantages of having your code
199 proper From: line so that the attribution is correct, and add a signoff of
212 developer posts a different solution to your problem. At that point,
213 chances are that one of the two patches will not be merged, and "mine was
216 really only one way to respond: be pleased that your problem got solved and