=head1 MAINTENANCE BRANCHES
-=over
-
-=item *
-
New releases of maint should contain as few changes as possible.
If there is any question about whether a given patch might merit
inclusion in a maint release, then it almost certainly should not
be included.
+The following types of change may be considered acceptable, as long as they do
+not also fall into any of the "unacceptable" categories set out below:
+
+=over
+
=item *
Portability fixes, such as changes to Configure and the files in
-hints/ are acceptable. Ports of Perl to a new platform, architecture
-or OS release that involve changes to the implementation are NOT
-acceptable.
+hints/ are acceptable.
=item *
=item *
-Patches that add new warnings or errors or deprecate features
-are not acceptable.
-
-=item *
-
Patches that fix crashing bugs, assertion failures and
memory corruption that do not otherwise change Perl's
functionality or negatively impact performance are acceptable.
to dual-life modules for which CPAN is canonical, any changes
should be coordinated with the upstream author.
+=back
+
+The following types of change are NOT acceptable:
+
+=over
+
+=item *
+
+Ports of Perl to a new platform, architecture
+or OS release that involve changes to the implementation are NOT
+acceptable.
+
+=item *
+
+Patches that add new warnings or errors or deprecate features
+are not acceptable.
+
=item *
New versions of dual-life modules should NOT be imported into maint.
=back
-
=head2 Getting changes into a maint branch
Historically, only the pumpking cherry-picked changes from bleadperl