Add Danny Sadinoff's old email address to Porting/checkAUTHORS.pl

[perl5.git] / Porting / release_managers_guide.pod

diff --git a/Porting/release_managers_guide.pod b/Porting/release_managers_guide.pod
index 780e636..dfffe17 100644 (file)
--- a/Porting/release_managers_guide.pod
+++ b/Porting/release_managers_guide.pod
@@ -216,8 +216,10 @@ Ensure dual-life CPAN modules are stable, which comes down to:
 
 I<You MAY SKIP this step for SNAPSHOT>
 
-Similarly, monitor the smoking of core tests, and try to fix.
-See L<http://doc.procura.nl/smoke/index.html> for a summary.
+Similarly, monitor the smoking of core tests, and try to fix.  See
+L<http://doc.procura.nl/smoke/index.html> for a summary. See also
+L<http://www.nntp.perl.org/group/perl.daily-build.reports/> which has
+the raw reports.
 
 =item *
 
@@ -392,6 +394,15 @@ For example:
   $ git log --pretty=fuller v5.13.2..HEAD | \
     perl Porting/checkAUTHORS.pl --who -
 
+Look at the previous L<perldelta> for how to write the opening
+paragraph of the Acknowledgements section. To get the amount of
+changed files and number of lines use this command:
+
+  $ git diff --shortstat v5.13.8..v5.13.9 | \
+    ./perl -Ilib -nE 'my ($files, $insert, $delete) = /(\d+)/ga; say "$files files and ", $insert + $delete, " lines changed"'
+
+Making sure to round off the number of lines changed.
+
 Re-read the perldelta to try to find any embarrassing typos and thinkos;
 remove any C<TODO> or C<XXX> flags; update the "Known Problems" section
 with any serious issues for which fixes are not going to happen now; and
@@ -403,7 +414,7 @@ run through pod and spell checkers, e.g.
 Also, you may want to generate and view an HTML version of it to check
 formatting, e.g.
 
-    $ perl pod/pod2html pod/perldelta.pod > /tmp/perldelta.html
+    $ ./perl -Ilib ext/Pod-Html/pod2html pod/perldelta.pod > /tmp/perldelta.html
 
 Another good HTML preview option is http://search.cpan.org/pod2html
 
@@ -480,8 +491,8 @@ appear in the final release, and leave as-is for the later RCs and final).
 Edit the version number in the new C<< 'Module::CoreList' => 'X.YZ' >>
 entry, as that is likely to reflect the previous version number.
 
-Also edit Module::CoreList's new version number in its F<Changes> file and
-in its F<META.yml> file.
+Also edit Module::CoreList's new version number in its F<Changes>
+file.
 
 You should also add the version you're about to release to the
 L<Module::CoreList/CAVEATS> section which enumerates the perl releases
@@ -673,7 +684,7 @@ which is why you should test from the tarball.
 
 Run the Installation Verification Procedure utility:
 
-    $ bin/perlivp
+    $ ./perl utils/perlivp
     ...
     All tests successful.
     $
@@ -770,6 +781,12 @@ based on (or at least the last commit of any consequence).
 Then check that the smoke tests pass (particularly on Win32). If not, go
 back and fix things.
 
+Note that for I<BLEAD> releases this may not be practical. It takes a
+long time for the smokers to catch up, especially the Win32
+smokers. This is why we have a RC cycle for I<MAINT> releases, but for
+I<BLEAD> releases sometimes the best you can do is to plead with
+people on IRC to test stuff on their platforms, fire away, and then
+hope for the best.
 
 =item *