PEP 462 – CPython 核心开发工作流自动化
- 作者:
- Alyssa Coghlan <ncoghlan at gmail.com>
- 状态:
- 已撤回
- 类型:
- 流程
- 要求:
- 474
- 创建日期:
- 2014年1月23日
- 发布历史:
- 2014年1月25日,2014年1月27日,2015年2月1日
摘要
本 PEP 提议投入资源,自动化目前 CPython 核心开发团队在合并更改时所需的一些繁琐、耗时的工作。此提案旨在让核心开发者更有效地利用他们为 CPython 贡献的时间,这也有望改善依赖核心团队合并更改的其他贡献者的体验。
PEP 撤回
本 PEP 已被作者撤回,以支持 PEP 507 中基于 GitLab 的提案。
如果其他人想接手并倡导此 PEP,请联系 core-workflow 邮件列表
核心开发工作流变更的理由
CPython 核心开发者在 POSIX 系统上合并新功能的当前工作流程“如下”:
- 如果应用由其他用户提交到 bugs.python.org 的更改,首先检查他们是否已签署 PSF 贡献者许可协议。如果未签署,则要求他们在继续合并更改之前签署一份。
- 将更改本地应用到主 CPython 仓库的当前副本(更改通常会首先在 bugs.python.org 上作为补丁讨论和审查,但对于直接来自核心开发者的更改,此步骤目前不被认为是强制性的)。
- 在本地运行测试套件,至少运行
make test
或./python -m test
(根据系统规格,在默认配置下需要几分钟,但如果启用所有可选资源,例如外部网络访问,则需要更长时间)。 - 运行
make patchcheck
以修复任何空格问题,并提醒可能需要的其他更改(例如更新 Misc/ACKS 或在 Misc/NEWS 中添加条目) - 提交更改并将其推送到主仓库。如果 hg 指示这将在远程仓库中创建新的头部,则运行
hg pull --rebase
(或等效命令)。理论上,此时应该重新运行测试,但跳过这一步是_非常_诱人的。 - 推送后,监视稳定构建机器人,查看您的更改是否引入了任何新故障。特别是,POSIX 系统上的开发者经常会破坏 Windows 构建机器人,反之亦然。不那么常见的是,Linux 或 Mac OS X 上的开发者可能会破坏其他 POSIX 系统。
在 Windows 上所需的步骤类似,但使用的具体命令会有所不同。
错误修复的工作流程非但没有更简单,反而比新功能的工作流程_更_复杂!新功能的优势在于只应用于 default
分支,而错误修复还需要考虑包含在维护分支中。
- 如果某个错误修复适用于 Python 2.7,那么它也会单独应用于 2.7 分支,该分支在 Mercurial 中作为独立 HEAD 维护。
- 如果某个错误修复适用于当前的 3.x 维护版本,那么它首先应用于维护分支,然后向前合并到默认分支。两个分支同时推送到 hg.python.org。
文档补丁比功能补丁简单,但也没有简单多少——主要好处是只需要检查文档构建是否成功,而不是运行测试套件。
我估计,即使一切顺利,我也至少需要 20-30 分钟才能提交一个能干净应用的错误修复补丁。考虑到其中几项任务应该可以自动化,我不认为我们目前的做法有效地利用了稀缺的核心开发者资源。
当前的工作流程中存在许多令人沮丧的地方,这些直接导致了一些不良的开发实践。
- 大部分开销是按每个应用的补丁产生的。这鼓励了大型提交,而不是小的独立更改。提交一个 500 行功能所需的时间与提交一个 1 行错误修复所需的时间基本相同——大型更改所需的额外时间出现在任何先前的审查中,而不是作为提交过程的一部分。
- 修复错误的额外开销进一步鼓励了开发者转而开发新功能,而新功能本身就_更_有趣——它们不需要工作流上的困难来推波助澜!
- 在 bugs.python.org 上进行事先审查是_额外_的工作,这促使直接提交更改,从而增加了对 python-checkins 邮件列表上事后审查的依赖。
- 跟踪器上那些完整、正确且准备好合并的补丁,仍可能长时间无人问津,等待核心开发者有时间进行合并。
- 推送冲突的风险(尤其是在推送合并的错误修复时)促使开发者跳过完整的本地测试运行(尤其是在遇到一次推送冲突之后),从而增加了破坏构建机器人的可能性。
- 构建机器人有时会长时间处于红色状态,这会在本地测试运行中引入错误,也意味着它们有时无法可靠地指示补丁是否引入了跨平台问题。
- 会议后的开发冲刺是一场噩梦,因为它们会陷入推送冲突的泥潭。人们很想直接把补丁留在跟踪器上,直到冲刺结束再尝试清理。
核心开发者也有很多犯错的机会,这些错误会给其他人带来不便,包括管理 Mercurial 分支以及在无法及时修复的情况下破坏构建机器人。这既让现有的核心开发团队在授予新开发者提交权限时变得谨慎,也让这些新开发者在使用他们提升的权限时变得谨慎。
还有一些偶然的烦恼(例如保持 NEWS 文件更新),作为本提案的一部分,也必然会得到解决。
志愿者驱动的开源项目最关键的资源之一是其贡献者的情感能量。当前的代码合并方法在这方面对任何人来说表现都不佳。
- 对于核心开发者来说,错误修复的分支管理很精细,很容易出错。NEWS 文件冲突和尝试上传更改时的推送竞争增加了恼怒,而我们大多数人并没有为此付出时间(对于那些为此付出时间的人来说,为 CPython 贡献可能只是我们众多职责之一)。我们花在实际合并更改上的时间,就是我们没有花在编写额外更改、撰写或更新文档或审查他人贡献上的时间。
- 红色的构建机器人给其他开发者(因为本地测试失败可能_并非_由于该开发者的任何操作)、发布经理(因为他们可能需要在发布前寻求协助清理测试失败)以及开发者本身带来了困难(因为它产生了巨大的压力,要求我们_立即_修复我们无意中引入的任何故障,而不是在更方便的时间,以及如果
hg annotate
不足以识别新故障的来源,则可能使hg bisect
更难使用)。 - 对于其他贡献者来说,核心开发者花费时间实际合并更改,就意味着该开发者没有在问题跟踪器上审查和讨论补丁,也没有以其他方式帮助他人有效贡献。对于习惯于开发者只需在项目的 CI 系统中自动测试过的拉取请求上点击“合并”的简单流程的贡献者来说,尤其令人沮丧(这在 GitHub 和 BitBucket 等网站上是一种常见的工作流程),或者合并过程中的事后审查部分是完全自动化的(OpenStack 就是这种情况)。
现有工具
以下工具目前用于管理 CPython 核心开发工作流的各个部分。
- Mercurial (hg.python.org) 用于版本控制
- Roundup (bugs.python.org) 用于问题跟踪
- Rietveld(也托管在 bugs.python.org 上)用于代码审查
- Buildbot (buildbot.python.org) 用于自动化测试
本提案建议用 PEP 474 中提议的基于 Kallithea 的 forge.python.org 服务取代 Rietveld 进行代码审查,该服务功能更完善。Guido 曾表示,最初的 Rietveld 实现主要旨在作为 Google App Engine 的公共演示应用程序,而改用 Kallithea 将解决在使用 Roundup 上的补丁文件以及集成 Rietveld 实例中的相关审查时出现的识别预期目标分支的一些问题。
它还建议添加新工具以自动化工作流程的更多部分,并对现有工具进行批判性审查,以查看哪些工具(如果有的话)可能被替换。
提案
本提案的实质是 CPython 旨在采用“核心审查者”开发模式,类似于 OpenStack 项目所使用的模式。
CPython 核心开发团队遇到的工作流程问题并非独有。OpenStack 基础设施团队设计了一套完善的自动化工作流程,旨在确保:
- 一旦补丁经过审查,只有当自动化测试在合并前失败时,才需要进一步的开发者参与。
- 补丁在未针对分支当前状态进行测试的情况下绝不合并。
- 主开发分支始终保持绿色。未通过自动化测试的补丁不会被合并。
如果核心开发者希望在合并前调整补丁,他们会从审查工具中下载它,修改并_将其重新上传到审查工具_,而不是直接推送到源代码仓库。
这个工作流程的核心是使用一个名为 Zuul 的工具实现的,这是一个专门为 OpenStack 项目创建的 Python web 服务,但其设计有意采用了基于插件的触发器和操作系统,以便更容易地适应替代的代码审查系统、问题跟踪器和 CI 系统。OpenStack 基础设施团队的 James Blair 在 linux.conf.au 2014 上提供了对 Zuul 的精彩概述。
虽然 Zuul 处理 OpenStack 的多种工作流程,但本 PEP 感兴趣的特定工作流程是“合并门控”工作流程。
对于此工作流程,Zuul 被配置为监控 Gerrit 代码审查系统,以查找已标记为“已批准”的补丁。一旦发现此类补丁,Zuul 就会将其取走,并将其合并到“候选合并”队列中。然后,它会创建一系列在 Jenkins 中并行执行的测试运行(以便在完整测试运行需要将近一个小时的情况下,每天允许超过 24 次提交),并在通过后(以及队列中所有在其前面的候选合并通过后)合并。如果补丁测试失败,Zuul 会将其从队列中取出,取消该补丁之后队列中的任何测试运行,并在不包含失败补丁的情况下重新构建队列。
如果开发者查看合并失败的测试,并确定是由于间歇性故障,他们可以重新提交补丁以再次尝试合并。
为了使此过程适应 CPython,应该可以实现 Zuul 监控 Kallithea 中已批准的拉取请求(这可能需要在 Kallithea 中添加一项功能),将其提交给 Buildbot 以在稳定的 Buildbot 上进行测试,然后适当地在 Mercurial 中合并更改。这个想法带来了一些技术挑战,下面将有专门的章节讨论。
对于 CPython,我不认为我们需要利用 Zuul 并行执行测试的能力(至少在初始迭代中不需要——如果我们达到了合并门控系统对补丁进行串行测试成为主要瓶颈,而不是我们缺乏足够的人力来审查和批准补丁的程度,那将是非常好的一天)。
然而,合并队列本身是一个非常强大的概念,应该能直接解决上述“理由”中描述的几个问题。
延期提案
OpenStack 团队还使用 Zuul 协调其他一些活动:
- 针对发布到 Gerrit 的补丁运行初步的“检查”测试。
- 合并更改时创建更新的发布工件并重新发布文档。
- 弹性重新检查功能,它结合垃圾邮件过滤器使用 ElasticSearch 来监控测试输出,并建议可能导致测试失败的具体间歇性故障,而无需用户手动搜索日志。
虽然这些是未来值得探索的可能性(也是我认为寻求与 OpenStack 基础设施团队更紧密协调可能带来的好处之一),但我认为它们提供的根本性工作流改进不如合并门控那么显著。
然而,如果我们发现门控中出现太多间歇性测试失败问题,那么可能需要将“弹性重新检查”功能作为初始部署的一部分进行考虑。
建议变体
特里·里迪建议进行初步筛选,专门寻找已批准的仅文档补丁(在 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 触发器和动作插件,并可能需要对我们现有的一些工具进行额外开发。
Kallithea 与 Gerrit
Kallithea 目前不包含与 Gerrit 等效的投票/批准功能。对于 CPython,我们不需要像 Gerrit 投票系统那样复杂的功能——一个简单的核心开发者专用“已批准”标记来触发 Zuul 的操作就足够了。核心开发者身份标志在 Roundup 中可用,此外还有指示补丁上传者是否已签署 PSF 贡献者许可协议的标志,这可能需要进一步开发以链接 Kallithea 实例和 Roundup 之间的贡献者账户。
一些现有的 Zuul 触发器通过监控特定的注释来工作(特别是 recheck/reverify 注释,用于在更改之前因不相关的间歇性故障而被拒绝时,要求 Zuul 再次尝试合并)。我们可能还需要为 Kallithea 提供类似的显式触发器。
Gerrit 的现有 Zuul 插件通过监控 Gerrit 活动流中的特定事件来工作。如果 Kallithea 没有等效功能,我们将需要添加适合我们希望触发的事件的机制。
还需要进行开发工作,以创建监控 Kallithea 活动而不是 Gerrit 的 Zuul 插件。
Mercurial 与 Gerrit/git
Gerrit 使用 Git 作为补丁的实际存储机制,并自动处理已批准补丁的合并。相比之下,Kallithea 使用 RhodeCode 创建的 vcs 库作为特定 DVCS 实现(目前支持 Mercurial 和 Git 后端)的抽象层。
Zuul 也直接与 git 集成进行补丁操作——据我所知,设计中的这一部分目前无法插拔。然而,在 PyCon US 2014 上,冲刺中的 Mercurial 核心开发者表示有兴趣与核心开发团队和 Zuul 开发者合作,使 Zuul 除了支持 git 之外,还能支持 Mercurial。由于 Zuul 本身就是一个 Python 应用程序,将其迁移到使用与 RhodeCode 和 Kallithea 相同的 DVCS 抽象库,可能是实现这一目标的可行途径。
Buildbot 与 Jenkins
Zuul 与 CI 系统的交互也是可插拔的,使用 Gearman 作为首选接口。因此,将 CI 任务调整为在 Buildbot 而非 Jenkins 中运行,应该只是编写一个 Gearman 客户端的问题,该客户端可以处理来自 Zuul 的请求并将其传递给 Buildbot 主服务器。Zuul 使用纯 Python 的 gear 客户端库与 Gearman 进行通信,这个库也应该有助于处理 Buildbot 端的事情。
请注意,在初始迭代中,我建议我们_不_尝试流水线化测试执行。这意味着 Zuul 将以一种非常简单的模式运行,只有合并队列头部的补丁正在 Buildbot 机群上进行测试,而不是并行测试多个补丁。我设想的类似于从 Buildbot 主服务器请求强制构建,然后等待结果返回,然后才进入队列中的第二个补丁。
如果我们最终认为这还不够,并且需要开始使用 Zuul 的 CI 流水线功能,那么我们可能需要考虑将测试执行转移到动态供应的云镜像上,而不是像目前这样依赖志愿者维护的静态供应系统。OpenStack CI 基础设施团队正在探索用更简单的纯 Python 测试运行器取代他们目前使用的 Jenkins master 的想法,所以如果我们发现 Buildbot 无法有效地支持流水线化测试模型,我们可能会参与这项工作,而不是为 CPython 建立一个 Jenkins 实例。
在这种情况下,主要的技术风险将是确保我们支持 Linux 以外的平台上的测试(因为我们稳定的构建机器人目前除了几种不同的 Linux 变体之外,还覆盖了 Windows、Mac OS X、FreeBSD 和 OpenIndiana)。
在这种情况下,Buildbot 舰队仍将在对主仓库进行“检查”运行(无论是定期还是每次提交)中发挥作用,即使它不参与合并门控过程。更不寻常的配置(例如不带线程或不带 SSL/TLS 支持的构建)可能仍会以这种方式处理,而不是包含在门控标准中(至少在最初是这样)。
维护分支的处理
OpenStack 项目很大程度上将维护分支问题留给了下游供应商,而不是直接处理。这意味着需要解决一些关于我们如何调整 Zuul 来处理我们的维护分支的问题。
Python 2.7 可以通过将其视为一个独立的补丁队列来轻松处理。这将在 Kallithea 中通过提交独立的拉取请求来更新 Python 2.7 维护分支来实现。
Python 3.x 维护分支可能更复杂。我目前的建议是简单地停止使用 Mercurial 合并来管理它们,而是将它们视为独立的头部,类似于 Python 2.7 分支。对于活动的 Python 3 维护分支和默认开发分支,需要提交单独的拉取请求。这种方法的缺点是它增加了修复只合并到维护分支而没有提交到默认分支的风险,因此我们可能需要设计一些额外的工具,以确保每个维护分支的拉取请求在合并之前要么有一个相应的默认分支拉取请求,要么有一个明确的免责声明,表明它只适用于该分支,不需要向前移植到更高版本的分支。
这种方法的好处是,它能相对干净地适应我们有时会有两个活跃的 Python 3 维护分支的间歇性时期。
此问题确实提出了一些关于 Kallithea 的潜在用户界面想法,可能需要能够克隆拉取请求,以便将其应用于第二个分支。
安全分支的处理
为了简单起见,我建议保留仅限安全修复分支的处理方式:这些分支的发布经理将继续手动反向移植特定更改。唯一的改变是,如果他们希望在合并更新之前获得其他人的审查,他们可以使用 Kallithea 的拉取请求工作流程进行反向移植。
NEWS 文件更新的处理
我们目前处理 NEWS 文件更新的方法经常导致在将错误修复从活跃的维护分支向前合并到后续分支时出现虚假冲突。
问题 #18967* 讨论了该领域的一些可能改进,无论我们是否采用 Zuul 作为工作流自动化工具,这些改进都将是有益的。
“稳定”Buildbot 从属机的稳定性
在这个提案下,名义上稳定的构建机器人不稳定性将产生更大的影响。我们需要确保我们真正满意这些系统能够为开发分支的合并提供门控,否则就将其状态改为“不稳定”。
间歇性测试失败
一些测试,特别是时间测试,在现有 Buildbot 集群上表现出间歇性失败。特别是,作为虚拟机运行的测试系统,当虚拟机主机负载高于正常水平时,有时可能会出现时间失败。
OpenStack CI 基础设施包含许多额外功能,以帮助处理间歇性故障,其中最基本的功能是允许开发者在原始故障似乎是由于已知的间歇性故障(无论是 OpenStack 本身还是不稳定的测试)时,请求再次尝试合并补丁。
更复杂的弹性重新检查功能可能值得考虑,尤其是因为 CPython 测试套件的输出比 OpenStack 更复杂的多服务测试的输出要简单得多,因此可能更容易进行自动化分析。
自定义 Mercurial 客户端工作流支持
OpenStack 工作流程中一个有用的部分是“git review”插件,它使得将分支从本地 git 克隆推送到 Gerrit 进行审查相对容易。
PEP 474 提到了一个草案的自定义 Mercurial 扩展,它自动化了现有 CPython 核心开发工作流的一些方面。
作为本提案的一部分,该自定义扩展将扩展到支持基于 Kallithea 的新审查工作流,以及基于 Roundup/Rietveld 的旧审查工作流。
实际挑战
PSF 运行其自己的直接和间接赞助的工作流基础设施,主要是由于过去经历过免费提供给公众的基础设施性能不可接受的糟糕和缺乏灵活性。CPython 开发最初托管在 SourceForge 上,当 SF 在提供 Subversion 支持方面速度慢且 CVS 存在性能问题时(参见 PEP 347),源代码控制迁移到自托管;而问题跟踪后来迁移到专用赞助托管(来自 Upfront Systems)上的开源 Roundup 问题跟踪器,这是由于 SF 性能问题和当时 SF 跟踪器普遍可用性问题的综合原因(新跟踪器选择的结果和过程记录在 python.org wiki 上,而不是在 PEP 中)。
因此,涉及“SourceForge 可用性和可靠性问题,第二轮”的提案将面临至少一部分 CPython 核心开发团队成员(包括本 PEP 的作者)的强烈反对。本提案尊重这一历史,仅推荐那些可用于自托管作为赞助或 PSF 资助基础设施的工具,并且这些工具也是开源 Python 项目,可以根据 CPython 核心开发团队的需求进行定制。
然而,为了使本提案取得成功(如果获得通过),我们需要了解如何进行必要的配置、定制、集成和部署工作。
上次为 CPython 支持基础设施添加新组件(speed.python.org)的尝试不幸因核心开发者和 PSF 董事会成员缺乏时间来推动项目,以及难以让其他人迅速掌握并领导这项活动而搁浅(HP 捐赠给该项目的硬件目前用于支持 PyPy,但这种情况突显了依赖志愿者工作且他们有许多其他更高优先级需求来完成项目所面临的一些挑战)。
即使是最终成功的过去项目,例如从 CVS 到 Subversion,再从 Subversion 到 Mercurial 的源代码控制迁移,从 SourceForge 到 Roundup 的问题跟踪器迁移,Roundup 和 Rietveld 之间的代码审查集成,以及 Buildbot 持续集成舰队的引入,都经历了漫长的时间,因为志愿者们努力克服了涉及的众多技术和社会挑战。
幸运的是,由于本提案和 PEP 474 的几个方面与 Red Hat 的 Beaker 开源硬件集成测试系统以及其他与工作相关的项目中正在考虑的各种工作流程改进相吻合,我已安排每周投入约 1 天时间用于 CPython 基础设施项目。
连同 Rackspace 目前对维护 pypi.python.org 基础设施的贡献,我个人认为这种安排表明了 CPython 再分发商和主要用户之间更普遍的认识,即通过直接贡献开发时间来帮助维持上游基础设施的价值,而不是期望志愿者贡献者完全利用业余时间维护该基础设施,或通过 PSF 间接资助(这将涉及额外的管理开销)。我认为这是一个积极的趋势,我将尽我所能继续鼓励它。
开放问题
PEP 中的一切。我们是否要采用合并门控和 Zuul?我们如何解决各种技术挑战?Kallithea 和 Zuul 开发社区是否愿意进行成功所需的那种协作?
虽然我已经安排了一些自己的工作时间来做这件事,但我们是否要向 OpenStack 基金会寻求额外帮助,因为我们是 OpenStack 本身的关键依赖项,Zuul 是 OpenStack 基础设施团队的创建,而且 OpenStack 可用的开发资源目前远远超过 CPython?
为 Python 再分发商和主要用户工作的其他相关人员是否也能向其上级提出商业理由,以便投入开发时间来支持这项工作?
下一步
如果实施,这将是基于 Kallithea 的 forge.python.org 提案 PEP 474 的后续项目。有关目前正在进行的讨论、审查和概念验证试点过程的更多详情,请参阅该 PEP。
致谢
感谢 Jesse Noller、Alex Gaynor 和 James Blair 对本提案初稿提供了宝贵反馈,以及 James 和 Monty Taylor 在初稿发布后提供了额外的技术反馈。
感谢 Bradley Kuhn、Mads Kiellerich 和其他 Kallithea 开发者就 PEP 474 进行的讨论,这些讨论促使本提案进行了重大修订,改为基于 Kallithea 作为审查组件,而非现有 Rietveld 安装。
版权
本文档已置于公共领域。
来源:https://github.com/python/peps/blob/main/peps/pep-0462.rst
最后修改时间:2025-02-01 08:55:40 GMT
社会挑战
这里主要的社会挑战是让核心开发团队改变他们的做法。然而,该提案所自动化的那些繁琐但必要的步骤,应该会为现有开发者采纳这个想法创造强大的动力。
我相信可能需要三个具体功能来确保现有开发者确信此工作流自动化没有负面影响: