From 2693bef3c97701c246466329ed4ef1794f4b15ad Mon Sep 17 00:00:00 2001 From: Ricardo Signes Date: Wed, 23 Dec 2020 22:28:44 -0500 Subject: pod: update a few documents for perlgov changes (cherry picked from commit 66c65f79d3ac3abda04a869359d6f034ab2c32aa) --- pod/perlhack.pod | 6 +++--- pod/perlhist.pod | 4 ++-- pod/perlpolicy.pod | 57 +++++++++++++++++++++++++++++---------------------- pod/perlsecpolicy.pod | 6 +++--- 4 files changed, 41 insertions(+), 32 deletions(-) diff --git a/pod/perlhack.pod b/pod/perlhack.pod index ba5725992d..8e856cfd4e 100644 --- a/pod/perlhack.pod +++ b/pod/perlhack.pod @@ -684,7 +684,7 @@ still options for the future of prototypes that haven't been addressed. Good patches (tight code, complete, correct) stand more chance of going in. Sloppy or incorrect patches might be placed on the back burner -until the pumpking has time to fix, or might be discarded altogether +until fixes can be made, or they might be discarded altogether without further notice. =head3 Is the implementation generic enough to be portable? @@ -721,7 +721,7 @@ man's pointless cruft. =head3 Does it create too much work? -Work for the pumpking, work for Perl programmers, work for module +Work for the committers, work for Perl programmers, work for module authors, ... Perl is supposed to be easy. =head3 Patches speak louder than words @@ -1162,7 +1162,7 @@ functions do, as well as the many macros used in the source. =item * F This is a collection of words of wisdom for a Perl porter; some of it -is only useful to the pumpkin holder, but most of it applies to anyone +is only useful to the pumpkin holders, but most of it applies to anyone wanting to go about Perl development. =back diff --git a/pod/perlhist.pod b/pod/perlhist.pod index 5b7c2e18c6..091c4e7de4 100644 --- a/pod/perlhist.pod +++ b/pod/perlhist.pod @@ -65,8 +65,8 @@ the strings?). =head1 THE RECORDS Pump- Release Date Notes - king (by no means - comprehensive, + kin (by no means + Holder comprehensive, see Changes* for details) ====================================================================== diff --git a/pod/perlpolicy.pod b/pod/perlpolicy.pod index 35f2a9a630..ba54b92598 100644 --- a/pod/perlpolicy.pod +++ b/pod/perlpolicy.pod @@ -24,22 +24,26 @@ some are actively patching their pet area (threads, Win32, the regexp -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 Raku, while Perl 5 is -shepherded by a "pumpking", a porter responsible for deciding what +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: @@ -61,6 +65,10 @@ regardless of whether he previously invoked Rule 1. 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, which spells it all +out in detail. + =head1 MAINTENANCE AND SUPPORT Perl 5 is developed by a community, not a corporate entity. Every change @@ -168,7 +176,7 @@ Using a lexical pragma to enable or disable legacy behavior should be 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 @@ -263,8 +271,9 @@ 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 below).) +out the maint-release manager or overwhelming other committers voting on +changes to be included (see L +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: @@ -328,7 +337,8 @@ The following types of change are NOT acceptable: =item * -Patches that break binary compatibility. (Please talk to a pumpking.) +Patches that break binary compatibility. (Please talk to the steering +council.) =item * @@ -356,11 +366,11 @@ be included. =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 @@ -383,7 +393,7 @@ 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 +for the maint-release manager to obtain votes on changes required by the F where such changes can be applied by the means of cherry-picking from blead. @@ -436,7 +446,7 @@ should be respected whenever possible. =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 @@ -451,7 +461,7 @@ of the change acknowledged. 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. @@ -464,10 +474,9 @@ reasonable compromises when there are disagreements). 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 if at all possible be done only after direct input diff --git a/pod/perlsecpolicy.pod b/pod/perlsecpolicy.pod index ad555f074a..07a702495d 100644 --- a/pod/perlsecpolicy.pod +++ b/pod/perlsecpolicy.pod @@ -30,7 +30,7 @@ security team. You should receive an initial response to your report within 72 hours. If you do not receive a response in that time, please contact the security team lead L and -the Perl pumpking L. +the L. When members of the security team reply to your messages, they will generally include the perl-security@perl.org address in the "To" or "CC" @@ -297,8 +297,8 @@ open and transparent as possible about the state of your security report. New vulnerability reports will receive an initial reply within 72 hours from the time they arrive at the security team's mailing list. If you do not receive any response in that time, contact the security team lead -L and the Perl pumpking -L. +L and the the L. The initial response sent by the security team will confirm your message was received and provide an estimated time frame for the security team's -- cgit v1.2.1