Remove trailing white-space from RMG document

Author: bingos

Porting/release_managers_guide.pod

@@ -35,8 +35,8 @@ pumpking. Blead releases from 5.11.0 forward are made each month on the
 20th by a non-pumpking release engineer.  The release engineer roster
 and schedule can be found in Porting/release_schedule.pod.
 
-This document both helps as a check-list for the release engineer 
-and is a base for ideas on how the various tasks could be automated 
+This document both helps as a check-list for the release engineer
+and is a base for ideas on how the various tasks could be automated
 or distributed.
 
 The checklist of a typical release cycle is as follows:
@@ -65,7 +65,7 @@ The checklist of a typical release cycle is as follows:
 Some of the tasks described below apply to all four types of
 release of Perl. (blead, RC, final release of maint, final
 release of blead). Some of these tasks apply only to a subset
-of these release types.  If a step does not apply to a given 
+of these release types.  If a step does not apply to a given
 type of release, you will see a notation to that effect at
 the beginning of the step.
 
@@ -210,7 +210,7 @@ If you are making a MAINT release, run C<core-cpan-diff> on both blead and
 maint, then diff the two outputs. Compare this with what you expect, and if
 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. 
+have some extra changes.
 
 =head3 How to sync a CPAN module with a cpan/ distro
 
@@ -233,7 +233,7 @@ C<git checkout .gitignore> in the F<cpan/Distro> directory.
 =item *
 
 Remove files we do not need. That is, remove any files that match the
-entries in C<@IGNORE> in F<Porting/Maintainer.pl>, and anything that 
+entries in C<@IGNORE> in F<Porting/Maintainer.pl>, and anything that
 matches the C<EXCLUDED> section of the distro's entry in the C<%Modules>
 hash.
 
@@ -566,7 +566,7 @@ F<corelist.pl> uses ftp.funet.fi to verify information about dual-lived
 modules on CPAN. It can use a full, local CPAN mirror and/or fall back
 on HTTP::Tiny to fetch package metadata remotely.
 
-(If you'd prefer to have a full CPAN mirror, see 
+(If you'd prefer to have a full CPAN mirror, see
 http://www.cpan.org/misc/cpan-faq.html#How_mirror_CPAN)
 
 Then change to your perl checkout, and if necessary,
@@ -636,7 +636,7 @@ Add a perldelta entry for the new Module::CoreList version.
 
 In addition, if this is a final release (rather than a release candidate):
 
-=over 4 
+=over 4
 
 =item *
 
@@ -806,7 +806,7 @@ have access to.
 
 =head4 Download the tarball to another machine
 
-Download the tarball to some other machine. For a release candidate, 
+Download the tarball to some other machine. For a release candidate,
 you really want to test your tarball on two or more different platforms
 and architectures. The #p5p IRC channel on irc.perl.org is a good place
 to find willing victims.
@@ -829,7 +829,7 @@ Check that the test harness and install work on each test machine:
 
 Check that the output of C<perl -v> and C<perl -V> are as expected,
 especially as regards version numbers, patch and/or RC levels, and @INC
-paths. 
+paths.
 
 Note that the results may be different without a F<.git/> directory,
 which is why you should test from the tarball.
@@ -896,14 +896,14 @@ Test L<perlbug> with the following:
     $ bin/perlbug
     ...
     Subject: test bug report
-    Local perl administrator [yourself]: 
-    Editor [vi]: 
-    Module: 
-    Category [core]: 
-    Severity [low]: 
+    Local perl administrator [yourself]:
+    Editor [vi]:
+    Module:
+    Category [core]:
+    Severity [low]:
     (edit report)
     Action (Send/Display/Edit/Subject/Save to File): f
-    Name of file to save message in [perlbug.rep]: 
+    Name of file to save message in [perlbug.rep]:
     Action (Send/Display/Edit/Subject/Save to File): q
 
 and carefully examine the output (in F<perlbug.rep]>), especially