摘要

本 PEP 提案对 CPython 核心开发团队目前需要执行的几个繁琐、耗时的活动进行自动化投资。本提案旨在帮助核心开发人员更有效地利用他们贡献给 CPython 的时间，这也将为依赖核心团队将他们的更改整合进来的其他贡献者带来更好的体验。

PEP 撤回

本 PEP 已由作者 撤回，转而支持 PEP 507 中基于 GitLab 的提案。

如果其他人想接手此 PEP 的维护工作，请联系 core-workflow 邮件列表

更改核心开发工作流程的理由

目前将新功能合并到 POSIX 系统上的 CPython 的核心开发人员工作流程如下

1. 如果要应用另一个用户提交给 bugs.python.org 的更改，首先检查他们是否签署了 PSF 贡献者许可协议。如果没有，请在继续合并更改之前要求他们签署一份协议。
2. 将更改本地应用到 CPython 主仓库的当前检出版本（更改通常会在 bugs.python.org 上以补丁的形式讨论和审查，但这步骤目前对直接来自核心开发人员的更改来说并不是强制性的）。
3. 在本地运行测试套件，至少运行 make test 或 ./python -m test（取决于系统规格，这在默认配置下需要几分钟，但如果启用了所有可选资源，例如外部网络访问，则需要更长时间）。
4. 运行 make patchcheck 以修复任何空格问题，并提醒需要进行的其他更改（例如更新 Misc/ACKS 或在 Misc/NEWS 中添加条目）。
5. 提交更改并将其推送到主仓库。如果 hg 指示这将在远程仓库中创建一个新的头，则运行 hg pull --rebase（或等效命令）。理论上，您应该在此步骤中重新运行测试，但非常容易跳过此步骤。
6. 推送后，监控 稳定 buildbots，查看您的更改是否引入了任何新的错误。特别是，POSIX 系统上的开发人员经常会破坏 Windows buildbots，反之亦然。不太常见的是，Linux 或 Mac OS X 上的开发人员可能会破坏其他 POSIX 系统。

Windows 上所需的步骤类似，但使用的确切命令会有所不同。

与功能相比，错误修复的工作流程更复杂，而不是更简单！新功能的优势在于只应用于 default 分支，而错误修复还需要考虑是否将其包含在维护分支中。

• 如果错误修复适用于 Python 2.7，则它还会单独应用于 2.7 分支，该分支在 Mercurial 中作为独立的头进行维护。
• 如果错误修复适用于当前的 3.x 维护版本，则它首先应用于维护分支，然后合并到默认分支。这两个分支都会同时推送到 hg.python.org。

文档补丁比功能补丁更简单，但并非简单太多 - 主要优势在于只需要检查文档构建是否成功，而不需要运行测试套件。

我估计，即使一切顺利，我仍然需要至少 20-30 分钟才能提交一个能干净应用的错误修复补丁。鉴于可以自动化其中几个任务，我不相信我们当前的做法有效地利用了稀缺的核心开发人员资源。

当前工作流程中存在许多令人沮丧的地方，它们直接导致了一些不良的开发实践。

• 大部分这些开销都是针对每个应用的补丁产生的。这鼓励进行大型提交，而不是进行小的独立更改。提交 500 行功能所需的时间与提交 1 行错误修复所需的时间基本相同 - 大型更改所需的额外时间出现在任何先前的审查中，而不是作为提交过程的一部分。
• 应用错误修复的额外开销会造成额外动力去进行新功能开发，而新功能本身就 inherently 更有吸引力 - 它们不需要工作流程的困难来帮助它们！
• 在 bugs.python.org 上获得先前的审查是额外的工作，会造成动力直接提交更改，从而增加对 python-checkins 邮件列表上审查后的审查的依赖。
• 跟踪器上的补丁，如果已完成、正确且准备合并，仍然可能在很长一段时间内无人问津，等待有时间将其合并的核心开发人员。
• 推送竞赛（尤其是推送合并的错误修复时）的风险会让人忍不住跳过完整的本地测试运行（尤其是在遇到过一次推送竞赛之后），从而增加了破坏 buildbots 的可能性。
• buildbots 有时会长时间处于红色状态，这会导致本地测试运行出现错误，同时也意味着它们有时无法作为可靠的指标来判断补丁是否引入了跨平台问题。
• 会议后的开发冲刺是一场噩梦，因为它们会陷入推送竞赛的泥潭。人们忍不住想把补丁留在跟踪器上，直到冲刺结束后再清理它们。

核心开发人员也有很多机会犯下会给其他人带来不便的错误，无论是管理 Mercurial 分支，还是在无法及时修复的情况下破坏 buildbots。这既让现有的核心开发团队在授予新开发人员提交权限方面变得谨慎，也让这些新开发人员在真正利用他们获得的更高权限方面变得谨慎。

还有一些附带的烦恼（例如保持 NEWS 文件最新），也需要作为本提案的一部分进行解决。

一个志愿者驱动的开源项目最关键的资源之一是其贡献者的情感能量。目前更改合并方法在这一点上对任何人来说都不好。

• 对于核心开发人员来说，分支处理错误修复很微妙，也很容易出错。NEWS 文件上的冲突以及尝试上传更改时的推送竞赛，只会增加我们大多数人没有得到报酬而要花费时间处理的事情的烦恼（而对于那些得到报酬的人来说，为 CPython 贡献可能只是我们众多职责中的一项）。我们实际花在合并更改上的时间，是我们没有花在编码更多更改、编写或更新文档或审查其他人的贡献上的时间。
• 红色的 buildbots 会给其他开发人员带来困难（因为本地测试失败可能与该开发人员所做的事情无关），会给发布经理带来困难（因为他们可能需要寻求帮助来清理测试失败以进行发布），也会给开发人员自己带来困难（因为它会造成很大的压力，让我们必须立即修复我们无意中引入的任何错误，而不是在更方便的时候进行修复，而且还可能让 hg bisect 更难使用，如果 hg annotate 不足以识别新错误的来源）。
• 对于其他贡献者来说，核心开发人员花时间实际合并更改，就意味着核心开发人员无法审查和讨论问题跟踪器上的补丁，也无法有效地帮助其他人进行贡献。对于那些习惯于开发人员只需点击 "合并" 按钮就能合并已经通过项目的 CI 系统自动测试过的拉取请求（这在 GitHub 和 BitBucket 等网站上的常见工作流程），或者合并过程的审查后部分是完全自动化的（例如 OpenStack）的贡献者来说，这尤其令人沮丧。

当前工具

以下工具目前用于管理 CPython 核心开发工作流程的各个部分。

• Mercurial (hg.python.org) 用于版本控制
• Roundup (bugs.python.org) 用于问题跟踪
• Rietveld（也托管在 bugs.python.org 上）用于代码审查
• Buildbot (buildbot.python.org) 用于自动化测试

本提案建议用功能更全面的 Kallithea 驱动的 forge.python.org 服务取代 Rietveld 用于代码审查，该服务在 PEP 474 中提出。Guido 指出，最初的 Rietveld 实现主要是为了作为 Google App Engine 的公共演示应用程序，而切换到 Kallithea 将解决在 Roundup 上处理补丁文件以及在集成 Rietveld 实例中进行相关审查时，在识别目标分支方面出现的一些问题。

本提案还建议添加新工具，以自动化工作流程的更多部分，并对剩余的工具进行严格审查，以确定哪些工具（如果有）可以作为替换目标。

提案

本提案的核心是让 CPython 采用类似于 OpenStack 项目所采用的 "核心审查者" 开发模型。

CPython 核心开发团队遇到的工作流程问题并非独一无二。OpenStack 基础设施团队想出了一个设计精良的自动化工作流程，旨在确保

• 一旦补丁经过审查，只有在自动测试在合并之前失败时，才需要开发人员进一步参与
• 补丁在没有经过相对于分支当前状态的测试的情况下，绝不会被合并
• 主开发分支始终保持绿色。未通过自动测试的补丁将不会被合并

如果核心开发人员想要在合并之前调整补丁，他们会从审查工具中下载补丁，进行修改，并将其上传回审查工具，而不是直接将其推送到源代码仓库。

此工作流程的核心是使用名为 Zuul 的工具实现的，Zuul 是一种专门为 OpenStack 项目创建的 Python Web 服务，但其设计故意采用了基于插件的触发器和操作系统，以便更容易适应其他代码审查系统、问题跟踪器和 CI 系统。OpenStack 基础设施团队的 James Blair 在 2014 年的 linux.conf.au 上对 Zuul 做了一个很好的概述。

虽然 Zuul 处理 OpenStack 的多种工作流程，但本 PEP 特别关注的是“合并门控”工作流程。

对于此工作流程，Zuul 被配置为监控 Gerrit 代码审查系统中标记为“已批准”的补丁。一旦发现此类补丁，Zuul 会获取它并将其加入“候选合并”队列。然后，它会创建一个测试运行管道，这些管道在 Jenkins 中并行执行（以便在完整测试运行花费大部分时间的情况下，每天允许超过 24 次提交），并在测试通过时进行合并（以及队列中所有领先于它们的候选合并通过时）。如果补丁未通过测试，Zuul 会将其从队列中删除，取消该补丁之后队列中任何测试运行，并在没有失败补丁的情况下重建队列。

如果开发人员查看了合并失败的测试，并确定它是由于间歇性故障导致的，则他们可以重新提交该补丁以进行另一次合并尝试。

为了将此流程适应 CPython，应该可行的是让 Zuul 监控 Kallithea 上已批准的拉取请求（这可能需要在 Kallithea 中添加功能），将它们提交到 Buildbot 以在稳定构建机器上进行测试，然后在 Mercurial 中适当地合并更改。这个想法提出了一些技术挑战，这些挑战在下面有专门的部分进行讨论。

对于 CPython，我认为我们不需要利用 Zuul 并行执行测试的能力（至少在初始迭代中不是这样 - 如果我们到了一个点，合并门控系统对补丁的串行测试成为我们的主要瓶颈，而不是我们缺乏审核和批准补丁所需的人员，那将是一个非常美好的日子）。

但是，合并队列本身是一个非常强大的概念，应该能够直接解决上面理由中描述的几个问题。

延迟的提案

OpenStack 团队还使用 Zuul 来协调其他几项活动，包括：

• 针对发布到 Gerrit 的补丁运行初步“检查”测试。
• 在更改合并时创建更新的发布工件并重新发布文档。
• “弹性重新检查”功能，该功能使用 ElasticSearch 与垃圾邮件过滤器结合，监控测试输出并建议可能导致测试失败的特定间歇性故障，而无需用户手动搜索日志。

虽然这些都是未来值得探索的可能性（我看到的一个潜在好处是与 OpenStack 基础设施团队寻求更紧密的协调），但我认为它们不能提供与合并门控类似的根本性工作流程改进。

但是，如果我们发现门控中存在太多间歇性测试失败的问题，那么在初始部署中可能需要考虑引入“弹性重新检查”功能。

建议的变体

Terry Reedy 建议进行一个初始筛选，专门查找已批准的仅限文档的补丁（在 4000 多个未解决的 CPython 问题中，大约 700 个是纯粹的文档更新）。这种方法将避免与不稳定测试和跨平台测试相关的几个问题，同时仍然允许其他自动化流程进行处理（例如如何将补丁推送到合并队列）。

这种方法的主要缺点是 Zuul 无法像通常预期的那样完全控制合并过程，因此可能需要围绕此过程进行额外协调。

如果初始部署证明比预期存在更多测试可靠性问题，那么可以将这种方法作为备用选项。

也可以调整合并门控标准，如果它检测到补丁未修改“Docs”树之外的任何文件，则不运行测试套件，而只检查文档是否在没有错误的情况下构建。

作为另一种选择，可以合理地将某些文档部分（例如教程和 HOWTO 指南）从主源代码库中移出，并使用 PEP 474 中描述的更简单的基于拉取请求的模型进行管理。

预期收益

这个提议的益处最直接地体现在核心开发团队身上。首先，这意味着一旦我们在更新的代码审查系统中将补丁标记为“已批准”，我们通常就完成了。实际应用补丁、运行测试并将它合并到 Mercurial 的额外 20-30 分钟（或更长时间）将由 Zuul 全权负责。推送冲突也将成为过去 - 如果许多核心开发人员在冲刺中批准了补丁，那么这仅仅意味着 Zuul 中的队列更深了，而不是开发人员因试图合并更改并失败而感到沮丧。测试失败仍然会发生，但会导致受影响的补丁从合并队列中删除，而不是破坏主存储库中的代码。

随着大部分时间投入转移到审查流程中，这也鼓励了“为了可审查性而开发” - 补丁更小、更容易审查，因为 Zuul 而不是核心开发人员会承担多次运行测试的开销。

但是，从核心开发团队中移除这个时间消耗，也应该改善其他贡献者对 CPython 开发的体验，因为它消除了补丁被“丢弃”的几种可能性，同时也增加了核心开发人员可能用于审查贡献的补丁的时间。

另一个例子是其他贡献者的益处，当以新贡献者为主的冲刺运行时，只有单个核心开发人员在场（比如过去几年 PyCon AU 上的冲刺），合并队列将允许该开发人员将更多时间集中在审查补丁和帮助冲刺中的其他贡献者身上，因为接受一个补丁进行包含现在是 Kallithea UI 中的单击操作，而不是现在相对耗时的过程。即使有多个核心开发人员在场，让他们将时间和精力投入到与其他冲刺参与者互动中，也比让他们处理计算机可以（也应该）处理的机械性工作更好。

随着大多数在提交更改时可能出错的方式都被自动化地消除，当贡献者被提名为核心开发人员时，他们需要学习的新事物也明显减少了。这应该带来双重好处，既让现有核心开发人员更愿意授予这种额外的责任，也让新贡献者更愿意行使这种责任。

最后，CPython 中更稳定的默认分支，让其他 Python 项目更容易直接针对主存储库进行持续集成，而不需要等到我们进入新版本的发布候选阶段。目前，建立这样的系统并不特别吸引人，因为它需要包含额外的机制，等待 CPython 自己的 Buildbot 集群指示构建处于可用状态。使用提出的合并门控系统，主干始终保持可用状态。

技术挑战

将 Zuul 从 OpenStack 基础设施适应到 CPython 基础设施，至少需要开发额外的 Zuul 触发器和操作插件，并且可能需要在我们现有的一些工具中进行额外开发。

社会挑战

这里的主要社会挑战是让核心开发团队改变他们的实践。但是，该提案自动化的繁琐但必要的步骤应该为现有开发人员创造一个强大的激励，让他们接受这个想法。

我相信为了确保现有开发人员相信自动化此工作流程没有缺点，可能需要三个特定功能

• 仅需要核心开发人员的单一批准即可合并补丁。这可以在将来重新审视，但我们应该在初始推出时保留现状。
• 明确说明核心开发人员可以自由批准他们自己的补丁，除了在发布的候选发布阶段。这可以在将来重新审视，但我们应该在初始推出时保留现状。
• 确保至少发布经理具有“立即合并”功能，允许他们将特定补丁强制到合并队列的头部。为发布准备使用单独的克隆可能足以满足此目的。从长远来看，自动合并门控也可能允许更自动化地准备发布工件。

实际挑战

PSF 运行自己的直接和间接赞助的工作流程基础设施，主要是因为过去对免费提供给公众的基础设施性能和灵活性不可接受的差的经验。CPython 开发最初托管在 SourceForge 上，源代码控制在 SF 既缓慢地提供 Subversion 支持又遭受 CVS 性能问题的困扰时迁移到自托管（参见 PEP 347），而问题跟踪后来迁移到专门赞助的托管（来自 Upfront Systems）上的开源 Roundup 问题跟踪器，这是由于 SF 性能问题和当时 SF 跟踪器的通用可用性问题（新跟踪器选择的结果和过程记录在 python.org wiki 而不是在 PEP 中）。

因此，涉及为“SourceForge 可用性和可靠性问题第二轮”做好准备的提案将面临 CPython 核心开发团队中至少一些成员（包括本文档的作者）的强烈反对。该提案通过仅推荐可用于自托管的工具来尊重这种历史，这些工具是作为赞助或 PSF 资助的基础设施提供的，也是可以自定义以满足 CPython 核心开发团队需求的开源 Python 项目。

但是，为了使该提案成功（如果被接受），我们需要了解我们将如何执行必要的配置、定制、集成和部署工作。

最近一次尝试在 CPython 支持基础设施中添加一个新部分（speed.python.org）不幸地由于缺乏时间来推动该项目而失败，参与该项目的核心开发人员和 PSF 董事会成员，以及试图让其他人了解情况以领导该活动而遇到的困难（HP 为该项目捐赠的硬件目前正在用于支持 PyPy，但这种情况突出了依赖志愿者劳动力的挑战，这些志愿者在他们的时间上有许多其他优先级更高的需求，以引导项目完成）。

即使是最终成功的过去项目，例如从 CVS 到 Subversion 和从 Subversion 到 Mercurial 的源代码控制迁移，从 SourceForge 到 Roundup 的问题跟踪器迁移，Roundup 和 Rietveld 之间的代码审查集成以及 Buildbot 持续集成集群的引入，也花费了很长时间，因为志愿者克服了许多技术和社会挑战。

幸运的是，由于该提案和 PEP 474 的几个方面与 Red Hat 的 Beaker 开源硬件集成测试系统和其他与工作相关的项目正在考虑的各种工作流程改进相一致，我已经安排每周花大约一天时间来研究 CPython 基础设施项目。

再加上 Rackspace 对维护 pypi.python.org 基础设施的现有贡献，我个人认为这种安排表明 CPython 再分发者和主要用户中存在更普遍的认识，即通过直接贡献开发人员时间来帮助维持上游基础设施的价值，而不是期望志愿者贡献者完全在他们的业余时间维护该基础设施，或通过 PSF（以及随之而来的额外管理开销）间接资助它。我认为这是一个积极的趋势，我将尽我所能继续鼓励它。

开放问题

PEP 中几乎所有内容。我们是否要采用合并门控和 Zuul？我们如何解决各种技术挑战？Kallithea 和 Zuul 开发社区是否愿意进行这种合作，以使这项工作取得成功？

虽然我已经安排将我自己的工作时间的一部分用于此，但我们是否要联系 OpenStack 基金会寻求额外帮助，因为我们是 OpenStack 本身的关键依赖项，Zuul 是 OpenStack 基础设施团队的产物，而 OpenStack 的可用开发资源目前远远超过 CPython？

其他对 Python 再分发者和主要用户感兴趣的人是否也能够向他们的上级提出支持这项工作的商业案例？

下一步

如果实施，这将是 PEP 474 中基于 Kallithea 的 forge.python.org 提案的后续项目。请参阅该 PEP 以获取有关目前正在进行的讨论、审查和概念验证试点流程的更多详细信息。

鸣谢

感谢 Jesse Noller、Alex Gaynor 和 James Blair 对该提案的初步草案提供了宝贵的反馈，感谢 James 和 Monty Taylor 在发布初始草案后提供了额外的技术反馈。

感谢 Bradley Kuhn、Mads Kiellerich 和其他 Kallithea 开发人员围绕 PEP 474 进行的讨论，这些讨论导致对该提案进行了重大修订，使其基于使用 Kallithea 而不是现有的 Rietveld 安装来完成审查部分。

版权

本文档已置于公有领域。