diff options
Diffstat (limited to 'Master/tlpkg/tlperl/lib/pods/perlpolicy.pod')
-rw-r--r-- | Master/tlpkg/tlperl/lib/pods/perlpolicy.pod | 479 |
1 files changed, 0 insertions, 479 deletions
diff --git a/Master/tlpkg/tlperl/lib/pods/perlpolicy.pod b/Master/tlpkg/tlperl/lib/pods/perlpolicy.pod deleted file mode 100644 index 7e713b4920a..00000000000 --- a/Master/tlpkg/tlperl/lib/pods/perlpolicy.pod +++ /dev/null @@ -1,479 +0,0 @@ -=head1 NAME - -perlpolicy - Various and sundry policies and commitments related to the Perl core - -=head1 DESCRIPTION - -This document is the master document which records all written -policies about how the Perl 5 Porters collectively develop and maintain -the Perl core. - -=head1 GOVERNANCE - -=head2 Perl 5 Porters - -Subscribers to perl5-porters (the porters themselves) come in several flavours. -Some are quiet curious lurkers, who rarely pitch in and instead watch -the ongoing development to ensure they're forewarned of new changes or -features in Perl. Some are representatives of vendors, who are there -to make sure that Perl continues to compile and work on their -platforms. Some patch any reported bug that they know how to fix, -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. - -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 -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. - -You might sometimes see reference to Rule 1 and Rule 2. Larry's power -as Supreme Court is expressed in The Rules: - -=over 4 - -=item 1 - -Larry is always by definition right about how Perl should behave. -This means he has final veto power on the core functionality. - -=item 2 - -Larry is allowed to change his mind about any matter at a later date, -regardless of whether he previously invoked Rule 1. - -=back - -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. - -=head1 MAINTENANCE AND SUPPORT - -Perl 5 is developed by a community, not a corporate entity. Every change -contributed to the Perl core is the result of a donation. Typically, these -donations are contributions of code or time by individual members of our -community. On occasion, these donations come in the form of corporate -or organizational sponsorship of a particular individual or project. - -As a volunteer organization, the commitments we make are heavily dependent -on the goodwill and hard work of individuals who have no obligation to -contribute to Perl. - -That being said, we value Perl's stability and security and have long -had an unwritten covenant with the broader Perl community to support -and maintain releases of Perl. - -This document codifies the support and maintenance commitments that -the Perl community should expect from Perl's developers: - -=over - -=item * - -We "officially" support the two most recent stable release series. 5.12.x -and earlier are now out of support. As of the release of 5.18.0, we will -"officially" end support for Perl 5.14.x, other than providing security -updates as described below. - -=item * - -To the best of our ability, we will attempt to fix critical issues -in the two most recent stable 5.x release series. Fixes for the -current release series take precedence over fixes for the previous -release series. - -=item * - -To the best of our ability, we will provide "critical" security patches -/ releases for any major version of Perl whose 5.x.0 release was within -the past three years. We can only commit to providing these for the -most recent .y release in any 5.x.y series. - -=item * - -We will not provide security updates or bug fixes for development -releases of Perl. - -=item * - -We encourage vendors to ship the most recent supported release of -Perl at the time of their code freeze. - -=item * - -As a vendor, you may have a requirement to backport security fixes -beyond our 3 year support commitment. We can provide limited support and -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. - -=back - -=head1 BACKWARD COMPATIBILITY AND DEPRECATION - -Our community has a long-held belief that backward-compatibility is a -virtue, even when the functionality in question is a design flaw. - -We would all love to unmake some mistakes we've made over the past -decades. Living with every design error we've ever made can lead -to painful stagnation. Unwinding our mistakes is very, very -difficult. Doing so without actively harming our users is -nearly impossible. - -Lately, ignoring or actively opposing compatibility with earlier versions -of Perl has come into vogue. Sometimes, a change is proposed which -wants to usurp syntax which previously had another meaning. Sometimes, -a change wants to improve previously-crazy semantics. - -Down this road lies madness. - -Requiring end-user programmers to change just a few language constructs, -even language constructs which no well-educated developer would ever -intentionally use is tantamount to saying "you should not upgrade to -a new release of Perl unless you have 100% test coverage and can do a -full manual audit of your codebase." If we were to have tools capable of -reliably upgrading Perl source code from one version of Perl to another, -this concern could be significantly mitigated. - -We want to ensure that Perl continues to grow and flourish in the coming -years and decades, but not at the expense of our user community. - -Existing syntax and semantics should only be marked for destruction in -very limited circumstances. If a given language feature's continued -inclusion in the language will cause significant harm to the language -or prevent us from making needed changes to the runtime, then it may -be considered for deprecation. - -Any language change which breaks backward-compatibility should be able to -be enabled or disabled lexically. Unless code at a given scope declares -that it wants the new behavior, that new behavior should be disabled. -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. - -When a backward-incompatible change can't be toggled lexically, the decision -to change the language must be considered very, very carefully. If it's -possible to move the old syntax or semantics out of the core language -and into XS-land, that XS module should be enabled by default unless -the user declares that they want a newer revision of Perl. - -Historically, we've held ourselves to a far higher standard than -backward-compatibility -- bugward-compatibility. Any accident of -implementation or unintentional side-effect of running some bit of code -has been considered to be a feature of the language to be defended with -the same zeal as any other feature or functionality. No matter how -frustrating these unintentional features may be to us as we continue -to improve Perl, these unintentional features often deserve our -protection. It is very important that existing software written in -Perl continue to work correctly. If end-user developers have adopted a -bug as a feature, we need to treat it as such. - -New syntax and semantics which don't break existing language constructs -and syntax have a much lower bar. They merely need to prove themselves -to be useful, elegant, well designed, and well tested. - -=head2 Terminology - -To make sure we're talking about the same thing when we discuss the removal -of features or functionality from the Perl core, we have specific definitions -for a few words and phrases. - -=over - -=item experimental - -If something in the Perl core is marked as B<experimental>, we may change -its behaviour, deprecate or remove it without notice. While we'll always -do our best to smooth the transition path for users of experimental -features, you should contact the perl5-porters mailinglist if you find -an experimental feature useful and want to help shape its future. - -=item deprecated - -If something in the Perl core is marked as B<deprecated>, we may remove it -from the core in the next stable release series, though we may not. As of -Perl 5.12, deprecated features and modules warn the user as they're used. -If you use a deprecated feature and believe that its removal from the Perl -core would be a mistake, please contact the perl5-porters mailinglist and -plead your case. We don't deprecate things without a good reason, but -sometimes there's a counterargument we haven't considered. Historically, -we did not distinguish between "deprecated" and "discouraged" features. - -=item discouraged - -From time to time, we may mark language constructs and features which we -consider to have been mistakes as B<discouraged>. Discouraged features -aren't candidates for removal in the next major release series, but -we may later deprecate them if they're found to stand in the way of a -significant improvement to the Perl core. - -=item removed - -Once a feature, construct or module has been marked as deprecated for a -stable release cycle, we may remove it from the Perl core. Unsurprisingly, -we say we've B<removed> these things. - -=back - -=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. - -=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. - -=item * - -Acceptable documentation updates are those that correct factual errors, -explain significant bugs or deficiencies in the current implementation, -or fix broken markup. - -=item * - -Patches that add new warnings or errors or deprecate features -are not acceptable. - -=item * - -Patches that fix crashing bugs that do not otherwise change Perl's -functionality or negatively impact performance are acceptable. - -=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. - -=item * - -Patches that fix regressions in perl's behavior relative to previous -releases are acceptable. - -=item * - -Updates to dual-life modules should consist of minimal patches to -fix crashing or security issues (as above). - -=item * - -Minimal patches that fix platform-specific test failures 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. - -=item * - -New versions of dual-life modules should NOT be imported into maint. -Those belong in the next stable series. - -=item * - -Patches that add or remove features are not acceptable. - -=item * - -Patches that break binary compatibility are not acceptable. (Please -talk to a pumpking.) - -=back - - -=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, we're going to try out a new process for -maint-5.12. - -Any committer may cherry-pick any commit from blead to maint-5.12 if -they send mail to perl5-porters announcing their intent to cherry-pick -a specific commit along with a rationale for doing so and at least two -other committers respond to the list giving their assent. (This policy -applies to current and former pumpkings, as well as other committers.) - -=head1 CONTRIBUTED MODULES - - -=head2 A Social Contract about Artistic Control - -What follows is a statement about artistic control, defined as the ability -of authors of packages to guide the future of their code and maintain -control over their work. It is a recognition that authors should have -control over their work, and that it is a responsibility of the rest of -the Perl community to ensure that they retain this control. It is an -attempt to document the standards to which we, as Perl developers, intend -to hold ourselves. It is an attempt to write down rough guidelines about -the respect we owe each other as Perl developers. - -This statement is not a legal contract. This statement is not a legal -document in any way, shape, or form. Perl is distributed under the GNU -Public License and under the Artistic License; those are the precise legal -terms. This statement isn't about the law or licenses. It's about -community, mutual respect, trust, and good-faith cooperation. - -We recognize that the Perl core, defined as the software distributed with -the heart of Perl itself, is a joint project on the part of all of us. -From time to time, a script, module, or set of modules (hereafter referred -to simply as a "module") will prove so widely useful and/or so integral to -the correct functioning of Perl itself that it should be distributed with -the Perl core. This should never be done without the author's explicit -consent, and a clear recognition on all parts that this means the module -is being distributed under the same terms as Perl itself. A module author -should realize that inclusion of a module into the Perl core will -necessarily mean some loss of control over it, since changes may -occasionally have to be made on short notice or for consistency with the -rest of Perl. - -Once a module has been included in the Perl core, however, everyone -involved in maintaining Perl should be aware that the module is still the -property of the original author unless the original author explicitly -gives up their ownership of it. In particular: - -=over - -=item * - -The version of the module in the Perl core should still be considered the -work of the original author. All patches, bug reports, and so -forth should be fed back to them. Their development directions -should be respected whenever possible. - -=item * - -Patches may be applied by the pumpkin holder 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 -given back to the author when possible, and if the author decides on -an alternate fix in their version, that fix should be strongly -preferred unless there is a serious problem with it. Any changes not -endorsed by the author should be marked as such, and the contributor -of the change acknowledged. - -=item * - -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 -version of the module distributed with Perl to the latest version -until the latest version has had sufficient testing. - -=back - -In other words, the author of a module should be considered to have final -say on modifications to their module whenever possible (bearing in mind -that it's expected that everyone involved will work together and arrive at -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 -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 -from Larry. If this is done, it must then be made explicit in the -module as distributed with the Perl core that it is a forked version and -that while it is based on the original author's work, it is no longer -maintained by them. This must be noted in both the documentation and -in the comments in the source of the module. - -Again, this should be a last resort only. Ideally, this should never -happen, and every possible effort at cooperation and compromise should be -made before doing this. If it does prove necessary to fork a module for -the overall health of Perl, proper credit must be given to the original -author in perpetuity and the decision should be constantly re-evaluated to -see if a remerging of the two branches is possible down the road. - -In all dealings with contributed modules, everyone maintaining Perl should -keep in mind that the code belongs to the original author, that they may -not be on perl5-porters at any given time, and that a patch is not -official unless it has been integrated into the author's copy of the -module. To aid with this, and with points #1, #2, and #3 above, contact -information for the authors of all contributed modules should be kept with -the Perl distribution. - -Finally, the Perl community as a whole recognizes that respect for -ownership of code, respect for artistic control, proper credit, and active -effort to prevent unintentional code skew or communication gaps is vital -to the health of the community and Perl itself. Members of a community -should not normally have to resort to rules and laws to deal with each -other, and this document, although it contains rules so as to be clear, is -about an attitude and general approach. The first step in any dispute -should be open communication, respect for opposing views, and an attempt -at a compromise. In nearly every circumstance nothing more will be -necessary, and certainly no more drastic measure should be used until -every avenue of communication and discussion has failed. - - -=head1 DOCUMENTATION - -Perl's documentation is an important resource for our users. It's -incredibly important for Perl's documentation to be reasonably coherent -and to accurately reflect the current implementation. - -Just as P5P collectively maintains the codebase, we collectively -maintain the documentation. Writing a particular bit of documentation -doesn't give an author control of the future of that documentation. -At the same time, just as source code changes should match the style -of their surrounding blocks, so should documentation changes. - -Examples in documentation should be illustrative of the concept -they're explaining. Sometimes, the best way to show how a -language feature works is with a small program the reader can -run without modification. More often, examples will consist -of a snippet of code containing only the "important" bits. -The definition of "important" varies from snippet to snippet. -Sometimes it's important to declare C<use strict> and C<use warnings>, -initialize all variables and fully catch every error condition. -More often than not, though, those things obscure the lesson -the example was intended to teach. - -As Perl is developed by a global team of volunteers, our -documentation often contains spellings which look funny -to I<somebody>. Choice of American/British/Other spellings -is left as an exercise for the author of each bit of -documentation. When patching documentation, try to emulate -the documentation around you, rather than changing the existing -prose. - -In general, documentation should describe what Perl does "now" rather -than what it used to do. It's perfectly reasonable to include notes -in documentation about how behaviour has changed from previous releases, -but, with very few exceptions, documentation isn't "dual-life" -- -it doesn't need to fully describe how all old versions used to work. - - -=head1 CREDITS - -"Social Contract about Contributed Modules" originally by Russ Allbery E<lt>rra@stanford.eduE<gt> and the perl5-porters. - |