Lines Matching +full:many +full:- +full:to +full:- +full:one
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,
11 with, possibly, quite a bit of work yet to be done.
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
18 standards. A failure to participate in this process is quite likely to
23 ----------------------
27 many developers, the most intimidating part of the kernel development
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
39 - Code review is hard work, and it is a relatively thankless occupation;
44 impulse to respond in kind. Code review is about the code, not about
47 - Similarly, code reviewers are not trying to promote their employers'
48 agendas at the expense of your own. Kernel developers often expect to
52 trying to create discomfort for their employers' competitors.
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
56 the kernel. One job the maintainers do is to keep things looking
58 to get around a problem actually needs to become a generalized
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
65 understand what the reviewer is trying to say. If possible, fix the things
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
71 explain what is really going on. If you have a technical objection to a
72 suggested change, describe it and justify your solution to the problem. If
74 explanation not prove persuasive, though, especially if others start to
75 agree with the reviewer, take some time to think things over again. It can
76 be easy to become blinded by your own solution to a problem to the point
85 One fatal mistake is to ignore review comments in the hope that they will
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
92 around. So it is always a good idea to remind reviewers of previously
94 place for this kind of information. Reviewers should not have to search
95 through list archives to familiarize themselves with what was said last
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
103 always try appealing to a higher power. As of this writing, that higher
104 power tends to be Andrew Morton. Andrew has a great deal of respect in the
105 kernel development community; he can often unjam a situation which seems to
106 be hopelessly blocked. Appealing to Andrew should not be done lightly,
112 -----------------
114 If a patch is considered to be a good thing to add to the kernel, and once
116 entry into a subsystem maintainer's tree. How that works varies from one
117 subsystem to the next; each maintainer has his or her own way of doing
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.
122 For patches applying to areas for which there is no obvious subsystem tree
124 being -mm. Patches which affect multiple subsystems can also end up going
125 through the -mm tree.
127 Inclusion into a subsystem tree can bring a higher level of visibility to a
129 default. Subsystem trees typically feed linux-next as well, making their
130 contents visible to the development community as a whole. At this point,
132 reviewers; these comments need to be answered as in the previous round.
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.
147 complete (and you have added yourself to the MAINTAINERS file), though, it
151 To begin with, the visibility of your patch has increased yet again. There
153 the patch before. It may be tempting to ignore them, since there is no
155 though; you still need to be responsive to developers who have questions or
161 how many people will build your code into their kernels. And, of course,
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,
170 having a patch pulled as the result of a failure to fix a regression could
171 well make it harder for you to get work merged in the future.
174 bugs to deal with. The stabilization period is your best opportunity to
183 up a version of the kernel containing your patch, etc. Continuing to
184 respond to these reports is a matter of basic pride in your work. If that
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
196 a patch to your code. That is one of the advantages of having your code
198 either forward it on to the subsystem maintainer (be sure to include a
200 your own), or send an Acked-by: response back and let the original poster
204 possible, tell the author what changes need to be made to make the patch
205 acceptable to you. There is a certain resistance to merging patches which
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
214 here first" is not considered to be a compelling technical argument. If
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