Lines Matching full:you
6 At this point, you have followed the guidelines given so far and, with the
16 code. You, as the author of that code, will be expected to work with the
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
35 Many of the changes you may be asked to make - from coding style tweaks
42 they see the same mistakes being made over and over again. If you get a
45 the people, and code reviewers are not attacking you personally.
54 What all of this comes down to is that, when reviewers send you comments,
55 you need to pay attention to the technical observations that they are
57 from happening. When you get review comments on a patch, take the time to
59 that the reviewer is asking you to fix. And respond back to the reviewer:
60 thank them, and describe how you will answer their questions.
62 Note that you do not have to agree with every change suggested by
63 reviewers. If you believe that the reviewer has misunderstood your code,
64 explain what is really going on. If you have a technical objection to a
70 that you don't realize that something is fundamentally wrong or, perhaps,
71 you're not even solving the right problem.
79 go away. They will not go away. If you repost code without having
80 responded to the comments you got the time before, you're likely to find
84 going to remember all the details of the code you posted the last time
86 raised issues and how you dealt with them; the patch changelog is a good
89 time; if you help them get a running start, they will be in a better mood
92 What if you've tried to do everything right and things still aren't going
94 but there are times when somebody simply has to make a decision. If you
95 honestly believe that this decision is going against you wrongly, you can
101 in mind, of course, that he may not agree with you either.
124 there's a good chance that you will get more comments from a new set of
138 Some day, if all goes well, you'll log on and see that your patch has been
140 complete (and you have added yourself to the MAINTAINERS file), though, it
148 though; you still need to be responsive to developers who have questions or
152 the hands of a much larger group of testers. Even if you have contributed
153 a driver for hardware which is not yet available, you will be surprised by
158 regression, you'll find an uncomfortable number of eyes upon you;
159 regressions need to be fixed as soon as possible. If you are unwilling or
160 unable to fix the regression (and nobody else does it for you), your patch
162 negating all of the work you have done to get your patch into the mainline,
164 well make it harder for you to get work merged in the future.
171 for; you can start creating cool new patches once any problems with the old
180 after it's merged. The next time you post a patch, they will be evaluating
181 it with the assumption that you will not be around to maintain it
188 One day, you may open your mail client and see that somebody has mailed you
190 out there in the open, after all. If you agree with the patch, you can
196 If you disagree with the patch, send a polite response explaining why. If
198 acceptable to you. There is a certain resistance to merging patches which
200 far. If you are seen as needlessly blocking good work, those patches will
201 eventually flow around you and get into the mainline anyway. In the Linux
204 On very rare occasion, you may see something completely different: another