file that may have gotten copied while building the source
distribution, consult the C<MANIFEST>.
+As a special case, several files are regenerated by 'make regen' if
+your patch alters C<embed.fnc>. These are needed for compilation, but
+are included in the distribution so that you can build perl without
+needing another perl to generate the files. You must test with these
+regenerated files, but it is preferred that you instead note that
+'make regen is needed' in both the email and the commit message, and
+submit your patch without them. If you're submitting a series of
+patches, it might be best to submit the regenerated changes
+immediately after the source-changes that caused them, so as to have
+as little effect as possible on the bisectability of your patchset.
+
=for XXX
What should we recommend about binary files now? Do we need anything?
Your commit message should start with a description of the problem that
the patch corrects or new functionality that the patch adds.
-
As a general rule of thumb, your commit message should let a programmer
with a reasonable familiarity with the Perl core quickly understand what
you were trying to do, how you were trying to do it and why the change
=item What
-Your commit message should describe what part of the Perl core you're changing and what you expect your patch to do.
+Your commit message should describe what part of the Perl core you're
+changing and what you expect your patch to do.
=item Why
=back
-
-
=item Comments, Comments, Comments
Be sure to adequately comment your code. While commenting every line