Lines Matching refs:patches

6 of conventions and procedures which are used in the posting of patches;
16 There is a constant temptation to avoid posting patches before they are
17 completely "ready."  For simple patches, that is not a problem.  If the
26 patches which are known to be half-baked, but those who do will come in
33 sending patches to the development community.  These include:
57 The preparation of patches for posting can be a surprising amount of work,
75 up patches is a bit of an art; some developers spend a long time figuring
107    to a single file as 500 separate patches - an act which did not make him
113    patches, but to leave that infrastructure unused until the final patch
127 So now you have a perfect series of patches for posting, but the work is
224 Be careful in the addition of tags to your patches: only Cc: is appropriate
230 Before you mail your patches, there are a couple of other things you should
233  - Are you sure that your mailer will not corrupt the patches?  Patches
240    specific mail clients work for sending patches.
243    run patches through scripts/checkpatch.pl and address the complaints it
245    embodiment of a fair amount of thought about what kernel patches should
254 When mailing patches, it is important to send copies to anybody who might
281 is possible to send patches directly to Linus Torvalds and have him merge
284 you will be wanting that maintainer to merge your patches.  If there is no
293 patches in the series, and "subsys" is the name of the affected subsystem.
296 If you have a significant series of patches, it is customary to send an
300 that the patches, themselves, have complete changelog information.
305 patches with the proper threading.  If you have a long series, though, and