misc small amendments to the RMG

(manually cherry picked from commit 6939dacb8e08ddbb23bbeedd753fa88eeb2887df)

1 files changed, 40 insertions, 23 deletions

diff --git a/Porting/release_managers_guide.pod b/Porting/release_managers_guide.pod
index 247713893f..d8a14496f9 100644
--- a/Porting/release_managers_guide.pod
+++ b/Porting/release_managers_guide.pod
@@ -144,7 +144,7 @@ Andreas' email address at:
 =head3 rt.perl.org update access
 
 Make sure you have permission to close tickets on L<http://rt.perl.org/>
-so you can respond to bug report as necessary during your stint.  If you
+so you can respond to bug reports as necessary during your stint.  If you
 don't, make an account (if you don't have one) and contact the pumpking
 with your username to get ticket-closing permission.
 
@@ -182,6 +182,7 @@ is only needed on the day of the release or shortly afterwards.
 =head3 Quotation for release announcement epigraph
 
 You will need a quotation to use as an epigraph to your release announcement.
+It will live forever (along with Perl), so make it a good one.
 
 =head3 Install the previous version of perl
 
@@ -243,7 +244,7 @@ necessary, fix things up. For example, you might think that both blead
 and maint are synchronised with a particular CPAN module, but one might
 have some extra changes.
 
-=head3 How to sync a CPAN module with a cpanE<sol> distro
+=head4 Sync CPAN modules with the corresponding cpanE<sol> distro
 
 In most cases, once a new version of a distribution shipped with core has been
 uploaded to CPAN, the core version thereof can be synchronized automatically
@@ -335,13 +336,14 @@ If everything is ok, commit the changes.
 For entries with a non-simple C<FILES> section, or with a C<MAP>, you
 may have to take more steps than listed above.
 
-=head3 dual-life CPAN module stability
+=head3 Ensure dual-life CPAN module stability
 
-Ensure dual-life CPAN modules are stable, which comes down to:
+This comes down to:
 
    for each module that fails its regression tests on $current
        did it fail identically on $previous?
-       if yes, "SEP" (Somebody Else's Problem)
+       if yes, "SEP" (Somebody Else's Problem, but try to make sure a
+         bug ticket is filed)
        else work out why it failed (a bisect is useful for this)
 
    attempt to group failure causes
@@ -386,7 +388,7 @@ L<http://analysis.cpantesters.org/beforemaintrelease?pair=5.20.2:5.22.0%20RC1>
 
 Get perldelta in a mostly finished state.
 
-Read  F<Porting/how_to_write_a_perldelta.pod>, and try to make sure that
+Read F<Porting/how_to_write_a_perldelta.pod>, and try to make sure that
 every section it lists is, if necessary, populated and complete. Copy
 edit the whole document.
 
@@ -495,7 +497,7 @@ blead release, so you may find nothing to do here.
 
 Check that the copyright years are up to date by running:
 
-    $ ./perl t/porting/copyright.t --now
+    $ pushd t; ./perl -I../lib porting/copyright.t --now
 
 Remedy any test failures by editing README or perl.c accordingly (search for
 the "Copyright"). If updating perl.c, check if the file's own copyright date in
@@ -533,11 +535,12 @@ If necessary update the list and the indicated version number.
 
 =head3 check a readonly build
 
-Even before other prep work, follow the steps in  L<build the tarball> and test
+Even before other prep work, follow the steps in L<build the tarball> and test
 it locally.  Because a perl source tarballs sets many files read-only, it could
 test differently than tests run from the repository.  After you're sure
 permissions aren't a problem, delete the generated directory and tarballs.
 
+
 =head2 Building a release - on the day
 
 This section describes the actions required to make a release
@@ -588,7 +591,7 @@ maintainer for 'cpan' upstream modules.
 
 =head4 Bump Module::CoreList* $VERSIONs
 
-If necessary, bump C<$Module::CoreList::VERSION> (there's no need to do this
+If necessary, bump C<$VERSION> (there's no need to do this
 for every RC; in RC1, bump the version to a new clean number that will
 appear in the final release, and leave as-is for the later RCs and final).
 It may also happen that C<Module::CoreList> has been modified in blead, and
@@ -600,7 +603,7 @@ C<$Module::CoreList::Utils::VERSION> should always be equal to
 C<$Module::CoreList::VERSION>. If necessary, bump those two versions to match
 before proceeding.
 
-The files to modify are:
+Once again, the files to modify are:
 
 =over 4
 
@@ -646,7 +649,7 @@ on HTTP::Tiny to fetch package metadata remotely.
 (If you'd prefer to have a full CPAN mirror, see
 L<http://www.cpan.org/misc/cpan-faq.html#How_mirror_CPAN>)
 
-Then change to your perl checkout, and if necessary,
+Change to your perl checkout, and if necessary,
 
     $ make
 
@@ -673,6 +676,8 @@ Check those files over carefully:
 
 Also edit Module::CoreList's new version number in its F<Changes> file.
 This file is F<dist/Module-CoreList/Changes>.
+(BLEAD-POINT releases should have had this done already as a post-release
+action from the last commit.)
 
 =head4 Add Module::CoreList version bump to perldelta
 
@@ -732,6 +737,7 @@ run through pod and spell checkers, e.g.
 
     $ podchecker -warnings -warnings pod/perldelta.pod
     $ spell pod/perldelta.pod
+    $ aspell list < pod/perldelta.pod | sort -u
 
 Also, you may want to generate and view an HTML version of it to check
 formatting, e.g.
@@ -932,18 +938,18 @@ Create a tarball. Use the C<-s> option to specify a suitable suffix for
 the tarball and directory name:
 
  $ cd root/of/perl/tree
- $ make distclean       # make sure distclean works
- $ git clean -xdf       # make sure perl and git agree on files
-                        # git clean should not output anything!
- $ git status           # and there's nothing lying around
+ $ make distclean           # make sure distclean works
+ $ git clean -xdf           # make sure perl and git agree on files
+                            # git clean should not output anything!
+ $ git status --ignored     # and there's nothing lying around
 
- $ perl Porting/makerel -bx -s RC1            # for a release candidate
- $ perl Porting/makerel -bx                   # for the release itself
+ $ perl Porting/makerel -bx -s RC1          # for a release candidate
+ $ perl Porting/makerel -bx                 # for the release itself
 
-This creates the  directory F<../perl-x.y.z-RC1> or similar, copies all
+This creates the directory F<../perl-x.y.z-RC1> or similar, copies all
 the MANIFEST files into it, sets the correct permissions on them, then
-tars it up as F<../perl-x.y.z-RC1.tar.gz>. With C<-b>, it also creates a
-C<tar.bz2> file. The C<-x> also produces a C<tar.xz> file.
+tars it up as F<../perl-x.y.z-RC1.tar.gz>.  With C<-b>, it also creates a
+C<tar.bz2> file.  The C<-x> also produces a C<tar.xz> file.
 
 If you're getting your tarball suffixed with -uncommitted and you're sure
 your changes were all committed, you can override the suffix with:
@@ -1107,7 +1113,7 @@ a new release with a new minor version or RC number.
 
     https://pause.perl.org/
 
-(Login, then select 'Upload a file to CPAN')
+(Log in, then select 'Upload a file to CPAN')
 
 If your workstation is not connected to a high-bandwidth,
 high-reliability connection to the Internet, you should probably use the
@@ -1127,6 +1133,13 @@ may need to contact a PAUSE administrator or even bump the version of perl.
 
 Upload the .gz, .xz, and .bz2 versions of the tarball.
 
+Note: You can also use the command-line utility to upload your tarballs, if
+you have it configured:
+
+    cpan-upload perl-5.X.Y.tar.gz
+    cpan-upload perl-5.X.Y.tar.xz
+    cpan-upload perl-5.X.Y.tar.bz2
+
 Do not proceed any further until you are sure that your tarballs are on CPAN.
 Check your authors directory www.cpan.org (the globally balanced "fast"
 mirror) to confirm that your uploads have been successful.
@@ -1163,7 +1176,8 @@ Be sure to commit your change:
 
 =head3 announce to p5p
 
-Mail p5p to announce your new release, with a quote you prepared earlier.
+Mail perl5-porters@perl.org to announce your new release, with a quote you prepared earlier.
+Get the SHA1 digests from the PAUSE email responses.
 
 Use the template at Porting/release_announcement_template.txt
 
@@ -1238,7 +1252,8 @@ Confirm that you have a clean checkout with no local changes.
 
 =item *
 
-Run F<Porting/new-perldelta.pl>
+Run:
+    perl Porting/new-perldelta.pl
 
 =item *
 
@@ -1259,6 +1274,8 @@ Skip to the end of its test output to see the options it offers you.
 
 When C<make test_porting> passes, commit the new perldelta.
 
+    git commit -m'new perldelta for 5.X.Y'
+
 =back
 
 At this point you may want to compare the commit with a previous bump to