Lines Matching refs:be

8 with, possibly, quite a bit of work yet to be done.
13 code. You, as the author of that code, will be expected to work with the
22 developers as they review the code. Working with reviewers can be, for
24 process. Life can be made much easier, though, if you keep a few things in
29 will not keep them from asking a fundamental question: what will it be
31 Many of the changes you may be asked to make - from coding style tweaks
33 still be around and under development a decade from now.
45 be working on the kernel years from now, but they understand that their
65 be easy to become blinded by your own solution to a problem to the point
85 time; if you help them get a running start, they will be in a better mood
89 anywhere? Most technical disagreements can be resolved through discussion,
93 power tends to be Andrew Morton. Andrew has a great deal of respect in the
95 be hopelessly blocked. Appealing to Andrew should not be done lightly,
102 If a patch is considered to be a good thing to add to the kernel, and once
106 things. In particular, there may be more than one tree - one, perhaps,
120 reviewers; these comments need to be answered as in the previous round.
125 burner so that the remaining patches can be worked into shape and merged.
128 everything applies cleanly. This work can be a pain, but count your
130 only turned up during the merge window and had to be addressed in a hurry.
131 Now they can be resolved at leisure, before the merge window opens.
140 may be a new round of comments from developers who had not been aware of
141 the patch before. It may be tempting to ignore them, since there is no
143 though; you still need to be responsive to developers who have questions or
148 a driver for hardware which is not yet available, you will be surprised by
150 where there are testers, there will be bug reports.
154 regressions need to be fixed as soon as possible. If you are unwilling or
156 will almost certainly be removed during the stabilization period. Beyond
161 After any regressions have been dealt with, there may be other, ordinary
175 after it's merged. The next time you post a patch, they will be evaluating
176 it with the assumption that you will not be around to maintain it
185 either forward it on to the subsystem maintainer (be sure to include a
191 possible, tell the author what changes need to be made to make the patch
200 chances are that one of the two patches will not be merged, and "mine was
201 here first" is not considered to be a compelling technical argument. If
203 really only one way to respond: be pleased that your problem got solved and
205 be hurtful and discouraging, but the community will remember your reaction