Lines Matching defs:patch

15 bug tracker, patch guidelines, and commentary on Perl development
20 If you just want to submit a single small patch like a pod fix, a test
73 The next step is to submit your patch to the Perl core ticket system.
108 know. Otherwise we will take your submission of a patch as permission
113 The next time you wish to make a patch, you need to start from the
152 The perl5-changes mailing list receives a copy of each patch that gets
209 If you have a small patch to submit, please submit it via the GitHub
214 When the patch is applied, the ticket will be updated and you will
217 In other cases, the patch will need more work or discussion.
219 your patch.  Sometimes your patch may get lost in the shuffle.  It's
226 branch.  If you think your patch is appropriate for the maintenance
230 =head2 Getting your patch accepted
232 If you are submitting a code patch there are several things that you
233 can do to help the Perl 5 Porters accept your patch.
237 Using the GitHub Pull Request workflow, your patch will automatically
238 be available in a suitable format.  If you wish to submit a patch to
242 format-patch> will produce a patch in a style suitable for Perl.  The
243 C<format-patch> command produces one patch file for each commit you
244 made.  If you prefer to send a single patch for all commits, you can
251 This produces a patch based on the difference between blead and your
259 patch.  You'll need a pristine copy of the Perl source to diff against.
270 As you craft each patch you intend to submit to the Perl core, it's
283 patch corrects or new functionality that the patch adds.
306 changing and what you expect your patch to do.
433 If your patch changes code (rather than just changing documentation),
527 and should not be applied to the Perl core individually.  If a patch to
586 =head2 What makes for a good patch?
590 but here are some questions to consider when developing a patch:
612 Keep it open and exciting to use/patch/advocate Perl everywhere.
667 series of small patches is greatly preferred over a single large patch.
671 A patch is likely to be rejected if it closes off future avenues of
672 development.  For instance, a patch that placed a true and final
697 broken the behaviour the patch implements? And without tests, how can
698 the patch's author be confident that his/her hard work put into the
699 patch won't be accidentally thrown away by someone in the future?
705 so submitting a patch for the appropriate pod docs as well as the
722 Working code is always preferred to pie-in-the-sky ideas.  A patch to
726 that someone took the time to make the patch demonstrates a strong
852 basic errors before you submit a patch.
1128 question, then to patch the source code at that point to facilitate a build.
1159 This document walks through the creation of a small patch to Perl's C
1236 who knows, you may unearth a bug in the patch...