Lines Matching refs:patches
12 If anything in this document becomes out of date, please send in patches
104 patches if these rules are followed, and many people will only
107 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
115 Following these rules will not guarantee success (as all patches are
119 Other excellent descriptions of how to create patches properly are:
162 :ref:`Documentation/process/applying-patches.rst <applying_patches>`
250 Linus, usually the patches that have already been included in the
253 can be found at https://git-scm.com/) but plain patches are also just
256 new kernel as rock solid as possible. Most of the patches at this point
263 patches to Linus after -rc1 is released, but the patches need to also be
322 revisions to it, and maintainers can mark patches as under review,
415 If you add patches to your mail, make sure they are plain readable text
416 as stated in :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
418 attachments or compressed patches; they may want to comment on
443 to be able to take criticism and comments about your patches, evaluate
444 them at a technical level and either rework your patches or provide
483 - "Here is a series of small patches that..."
533 1) Small patches increase the likelihood that your patches will be
540 Small patches also make it very easy to debug when something goes
541 wrong. It's much easier to back out patches one by one than it is
545 2) It's important not only to send small patches, but also to rewrite
546 and simplify (or simply re-order) patches before submitting them.
569 Also realize that it is not acceptable to send patches for inclusion
576 Along with breaking up your patches, it is very important for you to let
584 When sending in your patches, pay special attention to what you say in