Note changes to perlvar in perldelta

[perl5.git] / pod / perlrepository.pod

diff --git a/pod/perlrepository.pod b/pod/perlrepository.pod
index bf7e511..f369add 100644 (file)
--- a/pod/perlrepository.pod
+++ b/pod/perlrepository.pod
@@ -336,12 +336,69 @@ And you can see the changes:
    Lesley Binks                   <lesley.binks@gmail.com>
    Lincoln D. Stein               <lstein@cshl.org>
 
+For changes significant enough to warrant a F<pod/perldelta.pod> entry, the
+porters would greatly appreciate it if you submit an entry along with your
+actual change. Significant changes include, but are not limited to:
+
+=over 4
+
+=item *
+
+adding, deprecating, or removing core features
+
+=item *
+
+adding, deprecating, removing, or upgrading core or dual-life modules
+
+=item *
+
+adding new core tests
+
+=item *
+
+fixing security issues and user-visible bugs in the core
+
+=item *
+
+changes that might break existing code, either on the perl or C level
+
+=item *
+
+significant performance improvements
+
+=item *
+
+adding, removing, or significantly changing documentation in the F<pod/>
+directory
+
+=item *
+
+important platform-specific changes
+
+=back
+
+Please make sure you add the perldelta entry to the right section within
+F<pod/perldelta.pod>. More information on how to write good perldelta entries is
+available in the C<Style> section of F<Porting/how_to_write_a_perldelta.pod>.
+
 Now commit your change locally:
 
   % git commit -a -m 'Rename Leon Brocard to Orange Brocard'
   Created commit 6196c1d: Rename Leon Brocard to Orange Brocard
    1 files changed, 1 insertions(+), 1 deletions(-)
 
+The C<-a> option is used to include all files that git tracks that you have
+changed.  If at this time, you only want to commit some of the files you have
+worked on, you can omit the C<-a> and use the command C<S<git add I<FILE ...>>>
+before doing the commit.  C<S<git add --interactive>> allows you to even just
+commit portions of files instead of all the changes in them.
+
+The C<-m> option is used to specify the commit message.  If you omit it, git
+will open a text editor for you to compose the message interactively.  This
+is useful when the changes are more complex than the sample given here, and,
+depending on the editor, to know that the first line of the commit message
+doesn't exceed the 50 character legal maximum.
+
 You can examine your last commit with:
 
   % git show HEAD
@@ -416,17 +473,6 @@ $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?