=item *
-We "officially" support the two most recent stable release series. 5.14.x
-and earlier are now out of support. As of the release of 5.20.0, we will
-"officially" end support for Perl 5.16.x, other than providing security
+We "officially" support the two most recent stable release series. 5.20.x
+and earlier are now out of support. As of the release of 5.26.0, we will
+"officially" end support for Perl 5.22.x, other than providing security
updates as described below.
=item *
advice to you as you do so and, where possible will try to apply
those patches to the relevant -maint branches in git, though we may or
may not choose to make numbered releases or "official" patches
-available. Contact us at E<lt>perl5-security-report@perl.orgE<gt>
-to begin that process.
+available. See L<perlsec/SECURITY VULNERABILITY CONTACT INFORMATION>
+for details on how to begin that process.
=back
=head1 MAINTENANCE BRANCHES
+New releases of maintenance branches should only contain changes that fall into
+one of the "acceptable" categories set out below, but must not contain any
+changes that fall into one of the "unacceptable" categories. (For example, a
+fix for a crashing bug must not be included if it breaks binary compatibility.)
+
+It is not necessary to include every change meeting these criteria, and in
+general the focus should be on addressing security issues, crashing bugs,
+regressions and serious installation issues. The temptation to include a
+plethora of minor changes that don't affect the installation or execution of
+perl (e.g. spelling corrections in documentation) should be resisted in order
+to reduce the overall risk of overlooking something. The intention is to
+create maintenance releases which are both worthwhile and which users can have
+full confidence in the stability of. (A secondary concern is to avoid burning
+out the maint-pumpking or overwhelming other committers voting on changes to be
+included (see L</"Getting changes into a maint branch"> below).)
+
+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 *
-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.
+Patches that fix CVEs or security issues. These changes should
+be passed using the security reporting mechanism rather than applied
+directly; see L<perlsec/SECURITY VULNERABILITY CONTACT INFORMATION>.
=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.
+Patches that fix crashing bugs, assertion failures and
+memory corruption but which do not otherwise change perl's
+functionality or negatively impact performance.
=item *
-Acceptable documentation updates are those that correct factual errors,
-explain significant bugs or deficiencies in the current implementation,
-or fix broken markup.
+Patches that fix regressions in perl's behavior relative to previous
+releases, no matter how old the regression, since some people may
+upgrade from very old versions of perl to the latest version.
=item *
-Patches that add new warnings or errors or deprecate features
-are not acceptable.
+Patches that fix bugs in features that were new in the corresponding 5.x.0
+stable release.
=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.
+Patches that fix anything which prevents or seriously impacts the build
+or installation of perl.
=item *
-Patches that fix CVEs or security issues are acceptable, but should
-be run through the perl5-security-report@perl.org mailing list
-rather than applied directly.
+Portability fixes, such as changes to Configure and the files in
+the hints/ folder.
=item *
-Patches that fix regressions in perl's behavior relative to previous
-releases are acceptable.
+Minimal patches that fix platform-specific test failures.
+
+=item *
+
+Documentation updates that correct factual errors, explain significant
+bugs or deficiencies in the current implementation, or fix broken markup.
=item *
Updates to dual-life modules should consist of minimal patches to
-fix crashing or security issues (as above).
+fix crashing bugs or security issues (as above). Any changes made to
+dual-life modules for which CPAN is canonical should be coordinated with
+the upstream author.
+
+=back
+
+The following types of change are NOT acceptable:
+
+=over
=item *
-Minimal patches that fix platform-specific test failures or build or
-installation issues are acceptable. When these changes are made
-to dual-life modules for which CPAN is canonical, any changes
-should be coordinated with the upstream author.
+Patches that break binary compatibility. (Please talk to a pumpking.)
=item *
-New versions of dual-life modules should NOT be imported into maint.
-Those belong in the next stable series.
+Patches that add or remove features.
=item *
-Patches that add or remove features are not acceptable.
+Patches that add new warnings or errors or deprecate features.
=item *
-Patches that break binary compatibility are not acceptable. (Please
-talk to a pumpking.)
+Ports of Perl to a new platform, architecture or OS release that
+involve changes to the implementation.
+
+=item *
+
+New versions of dual-life modules should NOT be imported into maint.
+Those belong in the next stable series.
=back
+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.
=head2 Getting changes into a maint branch
other committers respond to the list giving their assent. (This policy
applies to current and former pumpkings, as well as other committers.)
+Other voting mechanisms may be used instead, as long as the same number of
+votes is gathered in a transparent manner. Specifically, proposals of
+which changes to cherry-pick must be visible to everyone on perl5-porters
+so that the views of everyone interested may be heard.
+
+It is not necessary for voting to be held on cherry-picking perldelta
+entries associated with changes that have already been cherry-picked, nor
+for the maint-pumpking to obtain votes on changes required by the
+F<Porting/release_managers_guide.pod> where such changes can be applied by
+the means of cherry-picking from blead.
+
=head1 CONTRIBUTED MODULES
sarcasm. It is not enough to be factual. You must also be civil. Responding
in kind to incivility is not acceptable.
+While civility is required, kindness is encouraged; if you have any doubt about
+whether you are being civil, simply ask yourself, "Am I being kind?" and aspire
+to that.
+
If the list moderators tell you that you are not being civil, carefully
-consider how your words have appeared before responding in any way. You may
-protest, but repeated protest in the face of a repeatedly reaffirmed decision
-is not acceptable.
+consider how your words have appeared before responding in any way. Were they
+kind? You may protest, but repeated protest in the face of a repeatedly
+reaffirmed decision is not acceptable.
Unacceptable behavior will result in a public and clearly identified warning.
Repeated unacceptable behavior will result in removal from the mailing list and
warning, a user's ban length is reset. Removals, like warnings, are public.
The list of moderators will be public knowledge. At present, it is:
-Aaron Crane, Andy Dougherty, Ricardo Signes, Steffen Müller.
+Aaron Crane, Andy Dougherty, Ricardo Signes, Sawyer X, Steffen Müller.
=head1 CREDITS
https://perl5.git.perl.org / perl5.git / blobdiff