-engine), while others seem to do nothing but complain. In other
words, it's your usual mix of technical people.
+Among these people are the core Perl team. These are trusted volunteers
+involved in the ongoing development of the Perl language and interpreter.
+They are not required to be language developers or committers.
+
Over this group of porters presides Larry Wall. He has the final word
in what does and does not change in any of the Perl programming languages.
-These days, Larry spends most of his time on Perl 6, while Perl 5 is
-shepherded by a "pumpking", a porter responsible for deciding what
+These days, Larry spends most of his time on Raku, while Perl 5 is
+shepherded by a steering council of porters responsible for deciding what
goes into each release and ensuring that releases happen on a regular
basis.
Larry sees Perl development along the lines of the US government:
-there's the Legislature (the porters), the Executive branch (the
--pumpking), and the Supreme Court (Larry). The legislature can
-discuss and submit patches to the executive branch all they like, but
-the executive branch is free to veto them. Rarely, the Supreme Court
-will side with the executive branch over the legislature, or the
-legislature over the executive branch. Mostly, however, the
-legislature and the executive branch are supposed to get along and
-work out their differences without impeachment or court cases.
+there's the Legislature (the porters, represented by the core team), the
+Executive branch (the steering council), and the Supreme Court (Larry).
+The legislature can discuss and submit patches to the executive branch
+all they like, but the executive branch is free to veto them. Rarely,
+the Supreme Court will side with the executive branch over the
+legislature, or the legislature over the executive branch. Mostly,
+however, the legislature and the executive branch are supposed to get
+along and work out their differences without impeachment or court cases.
You might sometimes see reference to Rule 1 and Rule 2. Larry's power
as Supreme Court is expressed in The Rules:
Got that? Larry is always right, even when he was wrong. It's rare
to see either Rule exercised, but they are often alluded to.
+For the specifics on how the members of the core team and steering
+council are elected or rotated, consult L<perlgov>, which spells it all
+out in detail.
+
=head1 MAINTENANCE AND SUPPORT
Perl 5 is developed by a community, not a corporate entity. Every change
=item *
-We "officially" support the two most recent stable release series. 5.22.x
-and earlier are now out of support. As of the release of 5.28.0, we will
-"officially" end support for Perl 5.24.x, other than providing security
+We "officially" support the two most recent stable release series. 5.26.x
+and earlier are now out of support. As of the release of 5.32.0, we will
+"officially" end support for Perl 5.28.x, other than providing security
updates as described below.
=item *
considered when appropriate, and in the absence of any pragma legacy
behavior should be enabled. Which backward-incompatible changes are
controlled implicitly by a 'use v5.x.y' is a decision which should be
-made by the pumpking in consultation with the community.
+made by the steering council in consultation with the community.
Historically, we've held ourselves to a far higher standard than
backward-compatibility -- bugward-compatibility. Any accident of
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).)
+out the maint-release manager 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:
=item *
-Patches that break binary compatibility. (Please talk to a pumpking.)
+Patches that break binary compatibility. (Please talk to the steering
+council.)
=item *
=head2 Getting changes into a maint branch
-Historically, only the pumpking cherry-picked changes from bleadperl
-into maintperl. This has scaling problems. At the same time,
-maintenance branches of stable versions of Perl need to be treated with
-great care. To that end, as of Perl 5.12, we have a new process for
-maint branches.
+Historically, only the single-person project manager cherry-picked
+changes from bleadperl into maintperl. This has scaling problems. At
+the same time, maintenance branches of stable versions of Perl need to
+be treated with great care. To that end, as of Perl 5.12, we have a new
+process for maint branches.
Any committer may cherry-pick any commit from blead to a maint branch by
first adding an entry to the relevant voting file in the maint-votes branch
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
+for the maint-release manager 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.
=item *
-Patches may be applied by the pumpkin holder without the explicit
+Patches may be applied by the steering council without the explicit
cooperation of the module author if and only if they are very minor,
time-critical in some fashion (such as urgent security fixes), or if
the module author cannot be reached. Those patches must still be
The version of the module distributed with Perl should, whenever
possible, be the latest version of the module as distributed by the
author (the latest non-beta version in the case of public Perl
-releases), although the pumpkin holder may hold off on upgrading the
+releases), although the steering council may hold off on upgrading the
version of the module distributed with Perl to the latest version
until the latest version has had sufficient testing.
As a last resort, however:
-
If the author's vision of the future of their module is sufficiently
-different from the vision of the pumpkin holder and perl5-porters as a
-whole so as to cause serious problems for Perl, the pumpkin holder may
+different from the vision of the steering council and perl5-porters as a
+whole so as to cause serious problems for Perl, the steering council may
choose to formally fork the version of the module in the Perl core from the
one maintained by the author. This should not be done lightly and
should B<always> if at all possible be done only after direct input
=head1 STANDARDS OF CONDUCT
The official forum for the development of perl is the perl5-porters mailing
-list, mentioned above, and its bugtracker at rt.perl.org. Posting to the
+list, mentioned above, and its bugtracker at GitHub. Posting to the
list and the bugtracker is not a right: all participants in discussion are
expected to adhere to a standard of conduct.
Unacceptable behavior will result in a public and clearly identified
warning. A second instance of unacceptable behavior from the same
-individual will result in removal from the mailing list and rt.perl.org,
-for a period of one calendar month. The rationale for this is to
+individual will result in removal from the mailing list and GitHub issue
+tracker, for a period of one calendar month. The rationale for this is to
provide an opportunity for the person to change the way they act.
After the time-limited ban has been lifted, a third instance of
Removals, like warnings, are public.
The list of moderators will be public knowledge. At present, it is:
-Aaron Crane, Andy Dougherty, Karen Etheridge, Ricardo Signes, Sawyer X,
-Steffen Müller, Todd Rinaldo.
+Karen Etheridge, Ricardo Signes, Sawyer X, Todd Rinaldo, Aaron Crane.
=head1 CREDITS
https://perl5.git.perl.org / perl5.git / blobdiff