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
56 making.  Do not let their form of expression or your own pride keep that
63 reviewers.  If you believe that the reviewer has misunderstood your code,
65 suggested change, describe it and justify your solution to the problem.  If
66 your explanations make sense, the reviewer will accept them.  Should your
69 be easy to become blinded by your own solution to a problem to the point
81 that your patches go nowhere.
90 when they revisit your code.
127 What may also happen at this point, depending on the nature of your patch,
133 everything applies cleanly.  This work can be a pain, but count your
138 Some day, if all goes well, you'll log on and see that your patch has been
144 To begin with, the visibility of your patch has increased yet again.  There
147 longer any question of your code being merged.  Resist that temptation,
151 More importantly, though: inclusion into the mainline puts your code into
154 how many people will build your code into their kernels.  And, of course,
157 The worst sort of bug reports are regressions.  If your patch causes a
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,
167 bugs to deal with.  The stabilization period is your best opportunity to
168 fix these bugs and ensure that your code's debut in a mainline kernel
176 up a version of the kernel containing your patch, etc.  Continuing to
177 respond to these reports is a matter of basic pride in your work.  If that
188 One day, you may open your mail client and see that somebody has mailed you
189 a patch to your code.  That is one of the advantages of having your code
193 your own), or send an Acked-by: response back and let the original poster
205 developer posts a different solution to your problem.  At that point,
209 really only one way to respond: be pleased that your problem got solved and
210 get on with your work.  Having one's work shoved aside in this manner can
211 be hurtful and discouraging, but the community will remember your reaction