文档:珀尔政策

名称

perlpolicy-与Perl核心相关的各种各样的策略和承诺

描述

本文档是主文档,它记录了关于Perl5Porter如何共同开发和维护Perl核心的所有书面策略。

治理

Perl 5波特

perl5-porters(波特自己)的用户有几种口味。有些人是安静好奇的潜伏者,他们很少参与进来,而是关注正在进行的开发,以确保他们事先得到关于Perl中新更改或功能的警告。一些是供应商的代表,他们在那里确保Perl继续在他们的平台上编译和工作。一些人会修补他们知道如何修复的任何报告错误,一些人正在积极修补他们的宠物区域(线程、Win32、regexp引擎),而其他人似乎什么也不做,只是抱怨。换句话说,这是您通常的技术人员组合。

其中包括核心Perl团队。这些都是值得信赖的志愿者,参与了Perl语言和解释器的持续开发。他们不需要是语言开发人员或提交人。

拉里·沃尔(Larry Wall)是这群搬运工的负责人。在任何一种Perl编程语言中,他对什么可以改变,什么不可以改变都有最终决定权。这些天,Larry将大部分时间花在Raku上,而Perl 5则由一个由搬运工组成的指导委员会负责管理,该委员会负责决定每个版本的内容,并确保定期发布。

Larry认为Perl的发展符合美国政府的思路:有立法机构(由核心团队代表的搬运工)、行政部门(指导委员会)和最高法院(Larry)。立法机构可以随意讨论并向行政部门提交补丁,但行政部门可以自由否决。很少有情况下,最高法院会站在行政部门一边而不是立法机构一边,或者站在立法机构一边而不是行政部门。然而,大多数情况下,立法机关和行政部门应该和睦相处,在没有弹劾或法庭案件的情况下解决分歧。

您有时可能会看到对规则1和规则2的引用。Larry作为最高法院的权力在《规则:

  1. Larry对Perl应该如何表现的定义总是正确的。这意味着他对核心功能拥有最终否决权。

  2. 拉里被允许在以后改变对任何事情的想法,无论他之前是否援引了规则1。

明白了吗?拉里总是对的,即使他错了。很少看到这两条规则都得到了执行,但它们经常被提及。

有关如何选举或轮换核心团队和指导委员会成员的详细信息,请咨询珀尔戈夫,它详细地说明了这一切。

维护和支持

Perl 5是由社区而不是企业实体开发的。贡献给Perl核心的每一个更改都是捐赠的结果。通常,这些捐款是我们社区的个人成员贡献的代码或时间。有时,这些捐款以公司或组织对特定个人或项目的赞助形式进行。

作为一个志愿者组织,我们所做的承诺在很大程度上取决于那些没有义务为Perl做出贡献的个人的善意和辛勤工作。

话虽如此,我们重视Perl的稳定性和安全性,并且长期以来与更广泛的Perl社区就支持和维护Perl版本达成了不成文的约定。

本文档编纂了Perl社区应该从Perl开发人员那里得到的支持和维护承诺:

  • 我们“正式”支持两个最新的稳定版本系列。5.30.x及更早版本现已失去支持。从5.36.0版本开始,我们将“正式”终止对Perl 5.32.x的支持,而不是提供如下所述的安全更新。

  • 尽我们所能,我们将尝试修复最近两个稳定的5.x发行版系列中的关键问题。当前版本系列的修复程序优先于先前版本系列的修补程序。

  • 尽我们所能,我们将为过去三年内发布了5.x.0版本的任何主要Perl版本提供“关键”安全补丁/发行版。我们只能承诺为任何5.x.y系列中最新的.y版本提供这些。

  • 我们不会为Perl的开发版本提供安全更新或错误修复。

  • 我们鼓励供应商在代码冻结时发布最新的受支持的Perl版本。

  • 作为供应商,您可能需要在我们承诺的3年支持期之后再进行安全修复。我们可以在您这样做的时候为您提供有限的支持和建议,并在可能的情况下尝试将这些补丁应用于git中的相关-maint分支机构,尽管我们可能会也可能不会选择提供编号版本或“官方”补丁。请参见perlsec中的“安全漏洞联系信息”有关如何开始该过程的详细信息。

向后兼容性和折旧

我们的社区长期以来一直坚信,即使所讨论的功能是设计缺陷,后向兼容性也是一种美德。

我们都希望能够纠正过去几十年中犯下的一些错误。忍受我们曾经犯过的每一个设计错误都会导致痛苦的停滞。纠正我们的错误是非常非常困难的。在不主动伤害用户的情况下这样做几乎是不可能的。

最近,忽视或积极反对与早期版本的Perl的兼容性已成为时尚。有时,有人提出了一个改变,想篡夺以前有另一种含义的语法。有时,更改想要改进以前的疯狂语义。

沿着这条路走下去就是疯狂。

要求最终用户程序员只更改少数几个语言结构,即使是受过良好教育的开发人员都不会有意使用的语言结构,也无异于说“除非您有100%的测试覆盖率,并且能够对代码库进行全面的手动审核,否则不应该升级到新版本的Perl。”如果我们要有能够可靠地将Perl源代码从一个Perl版本升级到另一个版本的工具,那么这个问题就可以大大缓解。

我们希望确保Perl在未来几年和几十年内继续发展壮大,但不会以牺牲用户社区为代价。

现有的语法和语义只应在非常有限的情况下标记为销毁。如果认为它们很少使用,那么就阻碍了Perl语言或Perl解释器的实际改进,如果受影响的代码可以轻松更新以继续工作,那么可以考虑删除它们。当有疑问时,谨慎意味着我们将支持向后兼容性。当一个特性被弃用时,将发布一个描述决策过程的推理语句,并在相关的perldelta文档中提供指向它的链接。

在适当的时候应该考虑使用词法杂注来启用或禁用遗留行为,并且在没有任何杂注的情况下应该启用遗留行为。“使用v5.x.y”隐式控制哪些向后兼容的更改,应由指导委员会与社区协商后作出决定。

从历史上看,我们一直坚持比向后兼容更高的标准——错误兼容。任何实现上的意外或运行一些代码的无意副作用都被认为是该语言的一个特性,与任何其他特性或功能一样,都需要以同样的热情进行辩护。在我们继续改进Perl时,无论这些无意的特性对我们来说有多么令人沮丧,这些无意的功能通常都值得我们保护。用Perl编写的现有软件能够继续正常工作,这一点非常重要。如果最终用户开发人员采用了一个bug作为功能,我们需要这样对待它。

新的语法和语义不会破坏现有的语言结构和语法,其门槛要低得多。他们只需要证明自己是有用的、优雅的、设计良好的和经过良好测试的。在大多数情况下,这些添加将标记为实验的一段时间。详见下文。

术语

为了确保我们在讨论从Perl核心中删除特性或功能时谈论的是同一件事,我们对几个单词和短语有了特定的定义。

实验的

如果Perl核心中的某些内容标记为实验的,我们可能会更改其行为,弃用或删除它,恕不另行通知。虽然我们会尽最大努力为实验性功能的用户铺平过渡道路,但如果您发现某个实验性功能有用并希望帮助塑造其未来,则应联系perl5-porters邮件列表。

实验特性必须在两个稳定版本中进行实验,然后才能标记为非实验特性。只有当实验特性不再有任何针对它们的设计变更错误,并且在整个开发周期内行为保持不变时,它们的实验状态才会被撤销。换言之,如果且仅当v5.21.0中存在的功能在整个v5.21中的行为不变时,则v5.20.0中存在的功能可能在v5.22.0中被标记为不再是实验性的。

已弃用

如果Perl核心中的某些内容标记为已弃用,我们可能会在未来将其从核心中移除,但我们可能不会。通常,向后不兼容的更改在被删除之前,会有两个发布周期的弃用警告,但如果风险看起来很低或好处很高,则可以在一个周期后删除。

从Perl 5.12开始,弃用的功能和模块在使用时会向用户发出警告。当模块被弃用时,它也将在CPAN上可用。从CPAN安装它将使该模块的弃用警告静音。

如果您使用了一个弃用的特性或模块,并且认为将其从Perl核心中删除是一个错误,请联系perl5-porters邮件列表并为您辩护。我们不会在没有充分理由的情况下抨击,但有时会有我们没有考虑过的反驳。从历史上看,我们没有区分“弃用”和“不推荐”功能。

气馁的

有时,我们会将我们认为有错误的语言结构和特征标记为气馁的。不受欢迎的功能目前不适合删除,但如果发现它们阻碍了Perl核心的显著改进,我们可能会在以后反对使用它们。

远离的

一旦特性、构造或模块被标记为不推荐使用,我们可以将其从Perl核心中删除。不出所料,我们说远离的这些东西。删除模块后,它将不再随Perl一起提供,但仍将在CPAN上可用。

维护分公司

维护分支的新版本应仅包含属于以下“可接受”类别之一的更改,但不得包含属于“不可接受”类型之一的任何更改。(例如,如果崩溃错误破坏了二进制兼容性,则不得包含该错误的修复程序。)

没有必要包含所有符合这些标准的更改,一般来说,重点应该放在解决安全问题、崩溃错误、回归和严重的安装问题上。应该抵制包含大量不影响perl安装或执行的微小更改(例如文档中的拼写更正)的诱惑,以降低忽略某些内容的总体风险。其目的是创建既有价值又能让用户对的稳定性充满信心的维护版本。(第二个问题是避免让维护发布管理器筋疲力尽,或压倒其他提交人对要包含的更改进行投票(请参阅“将更改放入维护分支”)。)

以下类型的变更可以被视为可接受,只要它们不属于以下任何“不可接受”类别:

  • 修复CVE或安全问题的修补程序。这些更改应使用安全报告机制传递,而不是直接应用;看见perlsec中的“安全漏洞联系信息”.

  • 修补程序可以修复崩溃错误、断言失败和内存损坏,但不会改变perl的功能或对性能产生负面影响。

  • 修补perl相对于以前版本的行为回归的补丁,无论回归的时间有多长,因为有些人可能会从非常旧的perl版本升级到最新版本。

  • 修补了相应5.x.0稳定版本中新增功能中的错误的补丁。

  • 修补程序可以修复任何阻止或严重影响perl构建或安装的问题。

  • 可移植性修复,例如对Configure和提示/文件夹中的文件的更改。

  • 修复平台特定测试失败的最少补丁。

  • 文档更新可以更正事实错误,解释当前实现中的重大错误或缺陷,或者修复损坏的标记。

  • 对双生命模块的更新应该包括最少的补丁,以修复崩溃的错误或安全问题(如上所述)。对CPAN规范的双寿命模块所做的任何更改都应与上游作者协调。

以下类型的更改是不可接受的:

  • 破坏二进制兼容性的修补程序。(请与指导委员会讨论。)

  • 添加或删除功能的修补程序。

  • 添加新警告或错误或不推荐使用的功能的修补程序。

  • Perl到新平台、体系结构或操作系统版本的端口,这些都涉及到对实现的更改。

  • 新版本的双寿命模块不应导入维护。这些属于下一个稳定系列。

如果对给定的补丁是否值得包含在maint版本中有任何疑问,那么几乎可以肯定它不应该包含在内。

将更改放入维护分支

历史上,只有单人项目经理才从bleadperl更改为maintperl。这存在缩放问题。同时,需要非常小心地处理Perl稳定版本的维护分支。为此,从Perl 5.12开始,我们为维护分支提供了一个新的进程。

任何提交人都可以通过首先在维护投票分支的相关投票文件中添加一个条目来选择从blead到维护分支的任何提交,该条目将宣布该提交为回传候选,然后等待至少两个其他提交人添加他们的投票支持这一点(即,在提交可能被反向提交之前,至少需要三张投票)。

在收集合适的候选提交集和挑选三票通过的提交集时,大多数工作都将由maint分支发布经理完成,但其他任何人都可以自由添加其他建议,如果他们希望确保某些修复不会被忽略或担心它们已经被忽略。

只要以透明的方式收集相同数量的选票,也可以使用其他投票机制(例如,向perl5-porters和至少两个其他提交人发送邮件,对名单作出响应,表示同意)。具体来说,对樱桃采摘的修改建议必须让每一个15号搬运工都能看到,这样才能听取所有感兴趣的人的意见。

无需对与已选中的更改相关的选中perldelta条目进行投票,也无需维护发布管理器获得对移植/发布管理器指南.pod在那里,可以通过从blead中拾取樱桃来应用这些更改。

贡献模块

关于艺术控制的社会契约

下面是一个关于艺术控制的声明,定义为包的作者指导其代码的未来并保持对其作品的控制的能力。这是一种认识,即作者应该控制他们的作品,并且确保他们保持这种控制是Perl社区其他人的责任。它试图记录我们作为Perl开发人员想要遵守的标准。这是一种尝试,旨在写下我们作为Perl开发人员应该相互尊重的粗略指导原则。

此声明不是合法合同。本声明以任何方式、形状或形式都不是法律文件。Perl是根据GNU公共许可证和艺术许可证分发的;这些是确切的法律术语。本声明与法律或许可无关。它是关于社区、相互尊重、信任和真诚合作的。

我们认识到,Perl核心被定义为与Perl本身的核心一起分发的软件,是我们所有人的一个联合项目。有时,脚本、模块或模块集(以下简称为“模块”)将被证明对Perl本身的正确功能非常有用和/或不可或缺,因此它应该与Perl内核一起分发。如果没有作者的明确同意,并且所有部分都清楚地认识到这意味着模块是按照与Perl本身相同的条款分发的,那么就不应该这样做。模块作者应该意识到,将模块包含到Perl核心中必然意味着对其失去控制,因为有时可能需要在短时间内进行更改,或者为了与Perl的其余部分保持一致。

然而,一旦一个模块被包含在Perl核心中,参与维护Perl的每个人都应该意识到,除非原始作者明确放弃对它的所有权,否则该模块仍然是原始作者的财产。特别是:

  • Perl核心中模块的版本仍应视为原始作者的作品。所有补丁、错误报告等都应该反馈给他们。应尽可能尊重他们的发展方向。

  • 如果且仅当补丁非常小、以某种方式(例如紧急安全修复)非常关键,或者无法联系到模块作者时,指导委员会可以在没有模块作者明确合作的情况下应用补丁。在可能的情况下,这些补丁仍必须返回给作者,如果作者决定在其版本中使用替代修复程序,则应强烈建议使用该修复程序,除非存在严重问题。任何未经作者认可的更改都应标记为此类,并且更改的贡献者应予以承认。

  • 与Perl一起发布的模块版本应尽可能是作者发布的模块的最新版本(对于公共Perl发行版,是最新的非beta版本),尽管指导委员会可能会推迟将随Perl分发的模块版本升级到最新版本,直到最新版本经过充分测试。

换言之,模块的作者应被视为在可能的情况下对其模块的修改拥有最终发言权(记住,当出现分歧时,所有相关人员都应共同努力,达成合理的妥协)。

然而,作为最后的手段:

如果作者对其模块未来的展望与指导委员会和perl5-porters的展望有很大的不同,从而给Perl带来了严重的问题,那么指导委员会可以选择正式将Perl核心中的模块版本与作者维护的版本分开。这不应轻而易举,应该总是如果可能的话,只有在拉里直接提出意见后才能进行。如果做到了这一点,那么必须在模块中明确表示它是一个分叉版本,并且虽然它是基于原始作者的工作,但不再由他们维护。必须在文档和模块源代码中的注释中注明这一点。

同样,这应该只是最后的手段。理想情况下,这永远不应该发生,在这样做之前,应该尽一切可能进行合作和妥协。如果确实有必要为Perl的整体健康状况分叉一个模块,那么必须永远给予原始作者适当的信任,并且应该不断重新评估这个决定,看看是否可以在以后重新融合这两个分支。

在处理贡献的模块时,每个维护Perl的人都应该记住,代码属于原始作者,在任何给定的时间,它们都可能不在perl5-porters上,并且补丁程序不是官方的,除非它已经集成到了作者的模块副本中。为了帮助实现这一点,以及上面的第1、2和3点,所有贡献模块的作者的联系信息都应该保存在Perl发行版中。

最后,Perl社区作为一个整体认识到,尊重代码所有权、尊重艺术控制、适当的信用以及积极努力防止无意的代码偏斜或通信漏洞,对社区和Perl本身的健康至关重要。社区成员通常不必诉诸规则和法律来处理彼此之间的关系,尽管本文件包含了明确的规则,但它是关于态度和一般方法的。任何争端的第一步都应该是公开沟通,尊重对立的观点,并试图达成妥协。在几乎每一种情况下,都没有必要采取更多的措施,当然,在每一种沟通和讨论途径都失败之前,不应采取更严厉的措施。

文档

Perl的文档是我们用户的重要资源。Perl的文档保持合理的一致性并准确地反映当前的实现,这一点非常重要。

正如P5P共同维护代码库一样,我们共同维护文档。编写特定的文档并不能让作者控制文档的未来。同时,正如源代码的更改应该与其周围块的样式相匹配一样,文档也应该进行更改。

文档中的例子应该说明他们所解释的概念。有时,显示语言功能如何工作的最佳方法是使用一个小程序,读者可以不经修改运行该程序。更常见的是,示例将由只包含“重要”位的代码片段组成。“重要”的定义因代码段而异。有时申报很重要使用严格使用警告,初始化所有变量并完全捕获每个错误条件。然而,这些事情往往掩盖了这个例子要教给我们的教训。

由于Perl是由一个全球志愿者团队开发的,我们的文档中经常包含拼写,这些拼写看起来很有趣某人美国/英国/其他拼写的选择留给每一位文档作者练习。当修补文档时,尝试模仿您周围的文档,而不是更改现有的散文。

一般来说,文档应该描述Perl“现在”做什么,而不是它过去做什么。在文档中包含有关行为与以前版本相比发生了哪些变化的注释是完全合理的,但是,除了极少数例外,文档并不是“双重生命”的,它不需要完全描述所有旧版本是如何工作的。

行为标准

开发perl的官方论坛是上面提到的perl5-porters邮件列表及其GitHub上的错误跟踪器。发布到列表和bugtracker是不正确的:所有参与讨论的人都应该遵守行为标准。

  • 始终保持文明。

  • 注意主持人。

礼貌很简单:坚持事实,同时避免贬低他人、挖苦他人或推定不诚实。仅仅是事实是不够的。你也必须有礼貌。对不文明行为作出实物回应是不可接受的。如果您从第三方将其他发布的评论转发到列表中,您将对这些评论的内容负责,因此您必须确保这些评论是文明的。

虽然需要礼貌,但鼓励仁慈;如果你对自己是否有礼貌有任何疑问,只需问问自己,“我是不是很善良?”并立志做到这一点。

如果名单主持人告诉你你不礼貌,在做出任何回应之前,请仔细考虑你的话是如何出现的。他们善良吗?你可以抗议,但面对一再重申的决定,一再抗议是不可接受的。反复抗议主持人关于第三方的决定也是不可接受的,因为他们会继续就自己的决定与主持人进行名单外联系。

不可接受的行为将导致公开且明确的警告。同一个人的第二次不可接受行为将导致在一个日历月内从邮件列表和GitHub问题跟踪程序中删除。这样做的理由是为员工提供一个改变行为方式的机会。

在限时禁令解除后,第三次不可接受的行为将导致进一步的公众警告。第四次或随后的审判将导致无限期禁令。理由是,面对明显拒绝改变行为的情况,我们必须保护其他社区成员免受未来不可接受的行为的影响。如果当事人确认他们不会再次违规,主持人可以选择解除无限期禁令。

删除与警告一样是公开的。

主持人名单将由公众知晓。目前是:Karen Etheridge、Neil Bowers、Nicholas Clark、Ricardo Signes、Todd Rinaldo。

学分

Russ Allbery原创《贡献模块的社会契约》<rra@stanford.edu>和perl5-porters。