diff options
Diffstat (limited to 'Master/tlpkg/tlperl/lib/pods/perlpolicy.pod')
-rw-r--r-- | Master/tlpkg/tlperl/lib/pods/perlpolicy.pod | 376 |
1 files changed, 376 insertions, 0 deletions
diff --git a/Master/tlpkg/tlperl/lib/pods/perlpolicy.pod b/Master/tlpkg/tlperl/lib/pods/perlpolicy.pod new file mode 100644 index 00000000000..5b078781588 --- /dev/null +++ b/Master/tlpkg/tlperl/lib/pods/perlpolicy.pod @@ -0,0 +1,376 @@ +=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 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 stabilty 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'. As of the release of 5.14.0, we will "officially" +end support for Perl 5.10, 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 initially released 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 thecore 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 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 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 * + +Documentation updates are acceptable. + +=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 * + +Updates to dual-life modules should consist of minimal patches to +fix crashing or security issues (as above). + +=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 +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 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 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 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 CREDITS + +Social Contract about Contributed Modules originally by Russ Allbery E<lt>rra@stanford.eduE<gt> and the perl5-porters. + |