Lines Matching refs:patch
79 a patch to the manual pages explaining the change to the manual pages
105 and send a patch, including (but not limited to):
116 "Linux kernel patch submission format"
117 http://linux.yyz.us/patch-format.html
153 A good introduction describing exactly what a patch is and how to
185 apply a patch.
194 will learn the basics of getting your patch into the Linux kernel tree,
307 in use, or patch queues being published as quilt series. Addresses of
311 Before a proposed patch is committed to such a subsystem tree, it is
315 interface which shows patch postings, any comments on a patch or
410 to comment on individual lines of your patch, which works only that way.
413 to apply your own patch by yourself. If that doesn't work, get your
423 there is. When you submit a patch for acceptance, it will be reviewed
432 Remember, this is part of getting your patch into the kernel. You have
440 - expect your patch to be accepted without question
443 - resubmit the patch without making any of the requested changes
446 there will always be differing opinions on how beneficial a patch is.
452 It is normal that the answers to your first patch might simply be a list
454 patch will not be accepted, and it is _not_ meant against you
455 personally. Simply correct all issues raised against your patch and
468 - "Here is a patch that explains what I am trying to describe."
481 - "Here's a 5000 line patch that..."
483 - "I have a deadline, and this patch needs to be applied now."
514 one time to a mailing list, your patch series should be smaller than
521 correctness. A 5 line patch can be applied by a maintainer with
522 barely a second glance. However, a 500 line patch may take hours to
524 proportional to the size of the patch, or something).
528 to dissect a very large patch after it's been applied (and broken
571 information for the patch, and will be preserved for everyone to see for
572 all time. It should describe the patch completely, containing:
574 - the overall design approach in the patch