Lines Matching full:your

7 addition of your own engineering skills, have posted a perfect series of
17 kernel community to ensure that your code is up to the kernel's quality
19 prevent the inclusion of your patches into the mainline.
31  - If you have explained your patch well, reviewers will understand its
48    agendas at the expense of your own.  Kernel developers often expect to
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
63 making.  Do not let their form of expression or your own pride keep that
70 reviewers.  If you believe that the reviewer has misunderstood your code,
72 suggested change, describe it and justify your solution to the problem.  If
73 your explanations make sense, the reviewer will accept them.  Should your
76 be easy to become blinded by your own solution to a problem to the point
88 that your patches go nowhere.
97 when they revisit your code.
134 What may also happen at this point, depending on the nature of your patch,
140 everything applies cleanly.  This work can be a pain, but count your
145 Some day, if all goes well, you'll log on and see that your patch has been
151 To begin with, the visibility of your patch has increased yet again.  There
154 longer any question of your code being merged.  Resist that temptation,
158 More importantly, though: inclusion into the mainline puts your code into
161 how many people will build your code into their kernels.  And, of course,
164 The worst sort of bug reports are regressions.  If your patch causes a
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,
174 bugs to deal with.  The stabilization period is your best opportunity to
175 fix these bugs and ensure that your code's debut in a mainline kernel
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
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
200 your own), or send an Acked-by: response back and let the original poster
212 developer posts a different solution to your problem.  At that point,
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