A mechanism for inlineable OP equivalents of XSUBs is a TODO.
[p5sagit/p5-mst-13.2.git] / pod / perlrepository.pod
index eb1737c..46fbf66 100644 (file)
@@ -399,6 +399,17 @@ $install_root/lib.  If you are unsure about the proper location of a
 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?
@@ -418,7 +429,6 @@ important to write a good commit message.
 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
@@ -428,7 +438,8 @@ matters to Perl.
 
 =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
 
@@ -448,8 +459,6 @@ month or next year.
 
 =back
 
-
-
 =item Comments, Comments, Comments
 
 Be sure to adequately comment your code.  While commenting every line