perlpolicy - 关于 Perl 核心相关的各种政策和承诺
本文件是记录 Perl 5 维护者如何集体开发和维护 Perl 核心的所有书面政策的总纲。
perl5-porters 邮件列表的订阅者（维护者本身）有几种类型。有些人是安静的好奇的潜伏者，他们很少参与，而是观察正在进行的开发，以确保他们能够提前了解 Perl 中的新变化或功能。有些人是供应商的代表，他们在那里是为了确保 Perl 能够在他们的平台上继续编译和运行。有些人会修补他们知道的任何报告的错误，有些人积极地修补他们关注的领域（线程、Win32、正则表达式引擎），而另一些人似乎除了抱怨什么也不做。换句话说，这是一群典型的技术人员。
在这些人中，有 Perl 核心团队。他们是参与 Perl 语言和解释器持续开发的值得信赖的志愿者。他们不需要是语言开发者或提交者。
在这些维护者之上，是 Larry Wall。他对任何 Perl 编程语言的更改具有最终决定权。如今，Larry 将大部分时间花在 Raku 上，而 Perl 5 则由一个维护者指导委员会负责管理，该委员会负责决定每个版本中包含的内容，并确保版本定期发布。
Larry 将 Perl 开发比作美国政府：有立法机构（由核心团队代表的搬运工）、行政部门（指导委员会）和最高法院（Larry）。立法机构可以随意讨论和提交补丁给行政部门，但行政部门可以自由否决它们。很少情况下，最高法院会站在行政部门一边反对立法机构，或者站在立法机构一边反对行政部门。然而，大多数情况下，立法机构和行政部门应该相处融洽，并解决他们的分歧，而不会出现弹劾或诉讼。
你可能会看到关于规则 1 和规则 2 的引用。Larry 作为最高法院的权力在《规则》中表达。
Larry 总是被定义为对 Perl 应该如何表现的正确理解。这意味着他对核心功能拥有最终否决权。
Larry 被允许在以后的日期改变他对任何事物的想法，无论他之前是否援引了规则 1。
明白了吗？Larry 总是对的，即使他错了。很少看到任何规则被执行，但它们经常被提及。
有关核心团队和指导委员会成员如何选举或轮换的具体信息，请参阅 perlgov，其中详细说明了所有内容。
Perl 5 由一个社区开发，而不是一个企业实体。对 Perl 核心做出的每一个更改都是捐赠的结果。通常，这些捐赠是社区成员个人贡献的代码或时间。有时，这些捐赠以企业或组织赞助特定个人或项目的形式出现。
作为一个志愿者组织，我们做出的承诺在很大程度上取决于那些没有义务为 Perl 做出贡献的个人的善意和辛勤工作。
话虽如此，我们重视 Perl 的稳定性和安全性，并且长期以来与更广泛的 Perl 社区有一个不成文的约定，即支持和维护 Perl 的版本。
本文档将 Perl 社区应该从 Perl 开发人员那里得到的支持和维护承诺编纂成文。
我们“正式”支持两个最新的稳定版本系列。5.30.x 及更早版本现在已不再受支持。从 5.36.0 版本发布开始，我们将“正式”停止对 Perl 5.32.x 的支持，除了提供下面描述的安全更新之外。
尽我们所能，我们将尝试修复两个最新的稳定 5.x 版本系列中的关键问题。当前版本系列的修复优先于先前版本系列的修复。
在能力范围内，我们将为过去三年内发布的任何主要 Perl 版本（5.x.0 版本）提供“关键”安全补丁/版本。我们只能承诺为任何 5.x.y 系列中最新的 .y 版本提供这些补丁。
我们不会为 Perl 的开发版本提供安全更新或错误修复。
我们鼓励供应商在代码冻结时发布最新支持的 Perl 版本。
作为供应商，您可能需要将安全修复程序回溯到我们 3 年的支持承诺之外。我们可以为您提供有限的支持和建议，并在可能的情况下尝试将这些补丁应用到 git 中的相关 -maint 分支，但我们可能选择不发布编号版本或“官方”补丁。有关如何开始此过程的详细信息，请参阅 "perlsec 中的 SECURITY VULNERABILITY CONTACT INFORMATION"。
我们的社区长期以来一直认为向后兼容性是一种美德，即使所讨论的功能存在设计缺陷。
我们都希望能够撤销过去几十年来犯下的一些错误。忍受我们犯下的每一个设计错误会导致痛苦的停滞。撤销我们的错误非常非常困难。在不积极损害用户的情况下做到这一点几乎是不可能的。
最近，忽略或积极反对与早期 Perl 版本的兼容性已成为一种时尚。有时，会提出一个更改，希望取代以前具有其他含义的语法。有时，更改希望改进以前不合理的语义。
这条路通向疯狂。
要求最终用户程序员更改一些语言结构，即使是任何受过良好教育的开发人员永远不会故意使用的语言结构，也等同于说“除非您拥有 100% 的测试覆盖率并且可以对您的代码库进行完整的 手动审核，否则您不应该升级到新版本的 Perl”。如果我们拥有能够可靠地将 Perl 源代码从一个 Perl 版本升级到另一个版本的工具，那么这个问题可以得到很大程度的缓解。
我们希望确保 Perl 在未来几年和几十年中继续发展壮大，但不能以牺牲用户社区为代价。
现有的语法和语义只有在非常有限的情况下才会被标记为要删除。如果它们被认为很少使用，阻碍了对 Perl 语言或 perl 解释器的实际改进，并且如果受影响的代码可以轻松更新以继续工作，则可以考虑将其删除。如有疑问，谨慎的做法是优先考虑向后兼容性。当某个功能被弃用时，将发布一份说明决策过程的理由声明，并在相关的 perldelta 文档中提供指向该声明的链接。
在适当的情况下，应考虑使用词法 pragma 来启用或禁用旧行为，在没有 pragma 的情况下，应启用旧行为。哪些向后不兼容的更改由 'use v5.x.y' 隐式控制，应由指导委员会与社区协商决定。
从历史上看，我们一直坚持比向后兼容性更高的标准——bugward-compatibility。任何实现上的意外或运行某些代码的非预期副作用都被认为是语言的一个特性，应该与任何其他特性或功能一样受到保护。无论这些非预期特性在我们继续改进 Perl 时对我们来说有多么令人沮丧，这些非预期特性通常值得我们保护。现有用 Perl 编写的软件能够继续正常工作非常重要。如果最终用户开发人员将 bug 视为特性，我们需要将其视为特性。
不破坏现有语言结构和语法的新的语法和语义的标准要低得多。它们只需要证明自己有用、优雅、设计良好且经过良好测试。在大多数情况下，这些添加将被标记为实验性一段时间。有关详细信息，请参见下文。
为了确保我们在讨论从 Perl 核心删除特性或功能时谈论的是同一件事，我们对一些词语和短语有特定的定义。
如果 Perl 核心中的某些内容被标记为实验性，我们可能会在未经通知的情况下更改其行为、弃用或删除它。虽然我们会尽力为实验性功能的用户提供平滑的过渡路径，但如果您发现实验性功能有用并希望帮助塑造其未来，请与 perl5-porters 邮件列表联系。
实验性功能必须在两个稳定版本中处于实验性状态才能被标记为非实验性。只有当实验性功能不再有任何设计更改的 bug 针对它，并且在整个开发周期中其行为保持不变时，才会撤销其实验性状态。换句话说，如果 v5.20.0 中存在的功能在 v5.21 中的行为始终保持不变，则该功能在 v5.22.0 中可能被标记为不再是实验性的。
如果 Perl 核心中的某些内容被标记为已弃用，我们可能会在将来将其从核心移除，但我们也可能不会。通常，向后不兼容的更改将在移除之前进行两个发布周期的弃用警告，但如果风险似乎很低或收益很高，则可能在一个周期后移除。
从 Perl 5.12 开始，已弃用的功能和模块会在使用时向用户发出警告。当一个模块被弃用时，它也会在 CPAN 上提供。从 CPAN 安装它将使该模块的弃用警告静音。
如果您使用已弃用的功能或模块，并且认为将其从 Perl 核心移除将是一个错误，请与 perl5-porters 邮件列表联系并说明您的理由。我们不会无缘无故地弃用东西，但有时我们会遇到我们没有考虑到的反驳意见。从历史上看，我们没有区分“已弃用”和“不鼓励”的功能。
我们可能会不时地标记我们认为是错误的语言结构和功能，并将它们标记为不鼓励。不鼓励的功能目前不是移除的候选对象，但如果发现它们阻碍了对 Perl 核心的重大改进，我们可能会在将来将其弃用。
一旦一个功能、结构或模块被标记为已弃用，我们可能会将其从 Perl 核心移除。不出所料，我们说我们已经移除了这些东西。当一个模块被移除时，它将不再与 Perl 一起发布，但将继续在 CPAN 上提供。
维护分支的新版本应该只包含属于下面列出的“可接受”类别之一的更改，但不能包含属于“不可接受”类别之一的任何更改。（例如，如果修复了崩溃的错误，但它破坏了二进制兼容性，则不能包含它。）
不需要包含满足这些标准的每个更改，通常应该重点解决安全问题、崩溃错误、回归和严重的安装问题。应该抵制包含大量不影响 perl 安装或执行的微小更改（例如文档中的拼写更正）的诱惑，以降低整体遗漏某些内容的风险。目的是创建既有价值又让用户对稳定性充满信心的维护版本。（另一个考虑因素是避免让维护版本经理精疲力尽或压倒其他投票决定要包含的更改的提交者（参见下面"将更改纳入维护分支"）。）
以下类型的更改可能被认为是可接受的，只要它们也不属于下面列出的任何“不可接受”类别
修复 CVE 或安全问题的补丁。这些更改应通过安全报告机制传递，而不是直接应用；请参阅 "perlsec 中的 SECURITY VULNERABILITY CONTACT INFORMATION"。
修复崩溃错误、断言失败和内存损坏的补丁，但不会更改 perl 的功能或对性能产生负面影响。
修复 perl 相对于先前版本的行为回归的补丁，无论回归有多久，因为有些人可能会从非常旧版本的 perl 升级到最新版本。
修复相应 5.x.0 稳定版本中新功能的错误的补丁。
修复任何阻止或严重影响 perl 构建或安装的补丁。
可移植性修复，例如对 Configure 和 hints/ 文件夹中的文件进行的更改。
修复特定于平台的测试失败的最小补丁。
文档更新，更正事实错误，解释当前实现中的重大错误或缺陷，或修复损坏的标记。
对双重生命周期模块的更新应包括修复崩溃错误或安全问题的最小补丁（如上所述）。对 CPAN 为规范的双重生命周期模块所做的任何更改应与上游作者协调。
以下类型的更改是不可接受的
破坏二进制兼容性的补丁。（请与指导委员会联系。）
添加或删除功能的补丁。
添加新的警告或错误或弃用功能的补丁。
将 Perl 移植到新的平台、架构或操作系统版本，这些移植涉及对实现的更改。
双重生命周期模块的新版本不应导入到 maint 中。这些属于下一个稳定系列。
如果对某个补丁是否值得包含在 maint 版本中存在任何疑问，那么它几乎肯定不应该被包含。
从历史上看，只有单人项目经理从 bleadperl 中挑选更改到 maintperl。这存在扩展问题。同时，稳定版本的 Perl 的维护分支需要非常小心地对待。为此，从 Perl 5.12 开始，我们为 maint 分支制定了一个新流程。
任何提交者都可以通过首先在 maint-votes 分支中将相关投票文件添加一个条目来宣布该提交作为回溯的候选者，然后等待至少另外两名提交者添加他们的支持票（即，在提交可以回溯之前，至少需要三票），将任何提交从 blead 挑选到 maint 分支。
收集合适的候选提交集和挑选三个投票的提交集的大部分工作将由 maint 分支发布经理完成，但任何其他人如果热衷于确保某些修复不会被忽视或担心它们已经被忽视，都可以自由添加其他建议。
也可以使用其他投票机制（例如，向 perl5-porters 发送邮件，至少另外两名提交者回复列表表示同意），只要以透明的方式收集相同数量的投票。具体来说，关于挑选哪些更改的建议必须对 perl5-porters 上的每个人可见，以便所有感兴趣的人的意见都能被听到。
对于已经 cherry-pick 的更改相关的 perldelta 条目，无需进行投票，维护发布经理也不需要就《Porting/release_managers_guide.pod》中要求的更改进行投票，因为这些更改可以通过从 blead 中 cherry-pick 来实现。
以下是一份关于艺术控制的声明，艺术控制被定义为包作者引导其代码的未来并保持对其作品控制的能力。它承认作者应该对其作品拥有控制权，并且 Perl 社区的其他成员有责任确保他们保留这种控制权。它试图记录我们作为 Perl 开发人员想要遵守的标准。它试图写下关于我们作为 Perl 开发人员彼此之间应有的尊重的粗略指南。
这份声明不是一份法律合同。这份声明无论从任何方面、形状或形式上都不是一份法律文件。Perl 在 GNU 通用公共许可证和 Artistic 许可证下发布；这些是精确的法律条款。这份声明与法律或许可证无关。它与社区、相互尊重、信任和真诚合作有关。
我们认识到，Perl 核心（定义为与 Perl 本身核心一起发布的软件）是我们所有人的共同项目。有时，一个脚本、模块或一组模块（以下简称“模块”）将被证明对 Perl 本身的正确运行非常有用和/或不可或缺，因此应该与 Perl 核心一起发布。这绝不应该在没有作者明确同意的情况下进行，并且所有方面都应明确承认这意味着该模块将根据与 Perl 本身相同的条款进行分发。模块作者应该意识到，将模块包含到 Perl 核心将不可避免地意味着对其失去一些控制权，因为有时可能需要在短时间内进行更改，或者为了与 Perl 的其余部分保持一致。
但是，一旦模块被包含在 Perl 核心之中，所有参与维护 Perl 的人员都应该意识到，该模块仍然是原始作者的财产，除非原始作者明确放弃其所有权。特别是
Perl 核心中的模块版本仍然应被视为原始作者的作品。所有补丁、错误报告等都应反馈给他们。他们的开发方向应尽可能得到尊重。
如果满足以下条件，则指导委员会可以在没有模块作者明确合作的情况下应用补丁：补丁非常小，在某种程度上时间紧迫（例如紧急安全修复），或者无法联系到模块作者。这些补丁仍然应该在可能的情况下反馈给作者，如果作者决定在其版本中进行替代修复，则应强烈优先考虑该修复，除非该修复存在严重问题。任何未经作者认可的更改都应标记为这样，并应确认更改的贡献者。
与 Perl 一起分发的模块版本应尽可能为作者分发的最新版本（对于公共 Perl 版本，为最新的非测试版），尽管指导委员会可能会推迟将与 Perl 一起分发的模块版本升级到最新版本，直到最新版本经过充分测试。
换句话说，模块的作者应该被认为在尽可能的情况下对他们模块的修改拥有最终决定权（请记住，预计所有相关人员将共同努力，并在出现分歧时达成合理的妥协）。
然而，作为最后的手段，
如果作者对他们模块未来的愿景与指导委员会和整个 perl5-porters 的愿景存在严重分歧，以至于会给 Perl 带来严重问题，指导委员会可以选择正式将 Perl 核心中的模块版本从作者维护的版本中分离出来。这应该谨慎处理，并且在任何情况下，只有在获得 Larry 的直接意见后才能进行。如果这样做，则必须在与 Perl 核心一起分发的模块中明确说明它是分离的版本，并且虽然它基于原始作者的工作，但不再由他们维护。这必须在文档和模块源代码中的注释中都注明。
再说一次，这应该只是最后的手段。理想情况下，这种情况永远不会发生，在采取此措施之前，应尽一切努力进行合作和妥协。如果证明为了 Perl 的整体健康而必须分离一个模块，则必须永久性地给予原始作者应有的荣誉，并且应不断重新评估该决定，以查看是否可以在将来重新合并这两个分支。
在处理所有贡献模块时，所有维护 Perl 的人员都应牢记，代码属于原始作者，他们可能不会在任何给定时间加入 perl5-porters，并且补丁只有在被集成到作者的模块副本中后才算正式。为了帮助解决这个问题，以及上述第 1、2 和 3 点，所有贡献模块的作者的联系信息应与 Perl 分发版一起保存。
最后，整个 Perl 社区都认识到，尊重代码所有权、尊重艺术控制、适当的署名以及积极努力防止无意的代码偏差或沟通差距对于社区和 Perl 本身的健康至关重要。社区成员通常不应该诉诸规则和法律来处理彼此之间的关系，这份文件虽然包含规则以确保清晰，但它关乎态度和总体方法。任何争议的第一步应该是公开沟通、尊重对方观点并尝试达成妥协。在几乎所有情况下，这将是必要的，并且在所有沟通和讨论途径都失败之前，绝不应该采取更激烈的措施。
Perl 的文档是我们用户的重要资源。Perl 文档保持合理连贯并准确反映当前实现至关重要。
正如 P5P 集体维护代码库一样，我们也集体维护文档。编写特定文档的一部分并不赋予作者对该文档未来的控制权。同时，正如源代码更改应该与周围代码块的风格相匹配一样，文档更改也应该如此。
文档中的示例应该说明它们正在解释的概念。有时，展示语言特性工作原理的最佳方法是使用读者可以运行的小程序，而无需修改。更常见的是，示例将包含一个代码片段，其中只包含“重要”部分。 “重要”的定义因片段而异。有时，声明 use strict 和 use warnings、初始化所有变量并完全捕获所有错误条件很重要。但更多情况下，这些事情会掩盖示例旨在教授的课程。
由于 Perl 是由全球志愿者团队开发的，因此我们的文档中经常包含对某些人来说看起来很奇怪的拼写。美国/英国/其他拼写选择留给每个文档部分的作者作为练习。在修补文档时，尝试模仿周围的文档，而不是更改现有的散文。
一般来说，文档应该描述 Perl “现在”的行为，而不是它过去的行为。在文档中包含关于行为如何从以前版本更改的注释是完全合理的，但是，除了极少数例外，文档不是“双重生命”——它不需要完全描述所有旧版本的工作方式。
Perl 开发的官方论坛是上面提到的 perl5-porters 邮件列表及其在 GitHub 上的 bugtracker。在列表和 bugtracker 上发帖不是一种权利：所有参与讨论的人员都应遵守行为准则。
始终保持礼貌。
听从版主的指示。
礼貌很简单：坚持事实，避免贬低性言论、贬低他人、讽刺或恶意揣测。仅仅是事实是不够的。你必须保持礼貌。以牙还牙是不被接受的。如果你将来自第三方的未发布评论转发到列表中，你将对这些评论的内容负责，因此你必须确保它们是礼貌的。
虽然礼貌是必须的，但友善是值得鼓励的；如果你对自己的行为是否礼貌有任何疑问，只需问问自己，“我是否友善？”并以此为目标。
如果列表版主告诉你你不礼貌，请仔细考虑你的言辞在回复之前是如何出现的。它们友善吗？你可能会抗议，但在反复确认的决定面前反复抗议是不可接受的。反复抗议版主关于第三方的决定也是不可接受的，就像继续与版主进行关于他们决定的非列表联系一样。
不可接受的行为将导致公开和明确的警告。同一人的第二次不可接受的行为将导致从邮件列表和 GitHub 问题跟踪器中删除，期限为一个月。这样做的理由是为该人提供改变行为方式的机会。
在有限时间禁令解除后，第三次不可接受的行为将导致进一步的公开警告。第四次或后续的违规行为将导致无限期禁令。这样做的理由是，面对明显拒绝改变行为的情况，我们必须保护其他社区成员免受未来不可接受的行为。如果当事人确认他们不会再次违反规定，版主可以选择解除无限期禁令。
删除，就像警告一样，是公开的。
版主列表将公开。目前，他们是：Karen Etheridge、Neil Bowers、Nicholas Clark、Ricardo Signes、Todd Rinaldo。
"关于贡献模块的社会契约"最初由 Russ Allbery <[email protected]> 和 perl5-porters 撰写。