Lines Matching refs:patch

10 It is a rare patch which is so good at its first posting that there is no
21 A patch of any significance will result in a number of comments from other
27  - If you have explained your patch well, reviewers will understand its
53 from happening.  When you get review comments on a patch, take the time to
82 raised issues and how you dealt with them; the patch changelog is a good
102 If a patch is considered to be a good thing to add to the kernel, and once
116 patch.  Now other developers working with that tree will get the patch by
122 What may also happen at this point, depending on the nature of your patch,
124 case, heavy patch conflicts can result in some work being put on the back
133 Some day, if all goes well, you'll log on and see that your patch has been
139 To begin with, the visibility of your patch has increased yet again.  There
141 the patch before.  It may be tempting to ignore them, since there is no
152 The worst sort of bug reports are regressions.  If your patch causes a
155 unable to fix the regression (and nobody else does it for you), your patch
157 negating all of the work you have done to get your patch into the mainline,
158 having a patch pulled as the result of a failure to fix a regression could
171 up a version of the kernel containing your patch, etc.  Continuing to
175 after it's merged.  The next time you post a patch, they will be evaluating
183 a patch to your code.  That is one of the advantages of having your code
184 out there in the open, after all.  If you agree with the patch, you can
190 If you disagree with the patch, send a polite response explaining why.  If
191 possible, tell the author what changes need to be made to make the patch
202 somebody else's patch displaces yours and gets into the mainline, there is
206 long after they have forgotten whose patch actually got merged.