summaryrefslogtreecommitdiff
path: root/Master/tlpkg/tlperl/lib/pods/perlpolicy.pod
diff options
context:
space:
mode:
Diffstat (limited to 'Master/tlpkg/tlperl/lib/pods/perlpolicy.pod')
-rw-r--r--Master/tlpkg/tlperl/lib/pods/perlpolicy.pod479
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.
-