创建“Python 核心”团队

为了管理权限，将创建一个“Python 核心”团队，作为 python 组织 [16] 的一部分。任何被迁移的仓库都将添加“Python 核心”团队，并赋予写入权限 [17]。以前有权管理 hg.python.org 上的 SSH 密钥的任何人将成为“Python 核心”团队的团队维护者。

定义将 Mercurial 仓库迁移到 Git 的命令

由于迁移到 GitHub 也意味着迁移到 Git [4]，我们必须决定运行哪些工具和命令来将 Mercurial 仓库转换为 Git。专门为此次迁移开发的工具托管在 https://github.com/orsenthil/cpython-hg-to-git。

CLA 强制执行

任何开源项目的关键部分是确保其源代码能够获得适当的许可。这需要确保所有贡献者都已签署贡献者许可协议 (CLA) [18]。到目前为止，贡献代码的 CLA 签署由核心开发者通过检查某人用户名旁是否有 * 来强制执行，该星号位于 bugs.python.org [5]。通过此次迁移，计划是首先自动化检查和强制贡献者签署 CLA。

将旧仓库设为只读

在现在旧的 Mercurial 仓库的 [hooks] 部分中更新 .hg/hgrc，如下所示：

pretxnchangegroup.reject = echo " * This repo has been migrated to github.com/python/peps and does not accept new commits in Mercurial!" 2>&1; exit 1

将使仓库变为只读。

记录提交拉取请求的步骤

在选择新的开发工作流程过程中，决定采用线性历史。人们更喜欢单个提交代表单个更改，而不是一组不相关的提交导致一个代表单个更改的合并提交。这意味着 GitHub 拉取请求中方便的“合并”按钮将设置为只执行_压缩_提交，而不是合并提交。

还将编写第二套推荐命令，用于提交从上传到 bugs.python.org [5] 的补丁文件中的贡献。这显然有助于保持线性历史，但需要确保将贡献归因于补丁作者。

将作为核心开发者指南的确切命令序列是一个悬而未决的问题：Git CLI 命令用于将拉取请求提交到 cpython。

将拉取请求链接到问题

历史上，外部贡献通过文件上传的方式附着到 bugs.python.org [5] 上的问题。对于核心开发者直接提交的更改，在提交消息开头以 Issue # 格式指定问题编号会导致在问题上发布评论，链接到该提交。

更新用于将提交 ID 映射到 URL 的链接服务

目前，您可以使用 https://hg.python.org/lookup/，并提供 cpython 仓库 [15] 的 Subversion 或 Mercurial 副本的修订 ID，以重定向到 Mercurial 仓库中该修订的 URL。URL 重写器需要更新，以重定向到 Git 仓库并支持为 Git 仓库创建的新修订 ID。

最可能的设计是在迁移发生后静态地知道所有的 Mercurial 变更集编号。然后，查找代码将更新为接受 7 到 40 位十六进制数字的哈希。任何长度为 12 或 40 的十六进制数字将与 Mercurial 变更集编号进行比较。如果数字不匹配或长度在 7 到 40 之间，则假定为 Git 哈希。

bugs.python.org 提交编号重写器 也需要更新以接受最短 7 位的哈希，因为 Git 将匹配该长度或更长的哈希。

弃用 sys._mercurial

一旦 Python 不再使用 Mercurial，sys._mercurial 属性将需要更改为返回 ('CPython', '', '')。将添加一个等效的 sys._git 属性，它将满足相同的用例。

更新 devguide

开发指南需要更新以包含新工作流程的详细信息。最有可能的工作将在单独的分支中进行，直到迁移实际发生。

更新 PEP 101

发布流程将需要根据需要进行更新。

处理 Misc/NEWS

传统上，Misc/NEWS 文件 [19] 对于跨 Python 版本的更改来说一直是个问题。通常在提交 3.5 和 3.6 之间的更改时，只在 Misc/NEWS 文件中会出现合并冲突。事实上，这种情况非常普遍，以至于开发指南中的示例说明明确提到了如何解决 Misc/NEWS 文件中的冲突 [21]。作为我们工具现代化的一部分，处理 Misc/NEWS 文件将得到简化。

计划的方法是为每个新闻条目使用单独的文件，其中包含条目的文本。在这种情况下，每个功能版本将拥有自己的新闻条目目录，并在该目录中创建一个单独的文件，该文件以其关闭的问题或时间戳值命名（以防止冲突）。跨分支的合并将没有问题，因为新闻条目文件仍将具有唯一的名称，并位于包含修复的最新版本的目录中。一个脚本将收集所有新闻条目文件，无论它们位于哪个目录中，并创建一个适当的新闻文件（发布目录可以忽略，因为文件的存在足以表示该条目属于该版本）。分类可以通过新闻条目文件本身的关键字完成，或者通过在每个发布目录中使用代表每个新闻条目分类的子目录（或者可以放弃新闻条目的分类，因为关键信息由组织化的“What's New”文档捕获）。这种方法的优点是它将更改与实际更改的代码保持一致。它还将消息与引入更改的提交关联起来。对于通过 CLI 进行的提交，可以提供一个脚本来帮助生成文件。在机器人驱动的场景中，合并机器人可以有一种方法来指定特定的新闻条目，并作为其扁平化提交的一部分创建文件（同时最有可能也支持在未指定特定新闻条目时使用提交消息的第一行）。如果使用基于网络的流程，则可以使用状态检查来验证拉取请求中是否存在新的条目文件，以提醒文件缺失。以前已为 Mercurial 工作流编写了此方法的代码，网址为 http://bugs.python.org/issue18967。社区中还有像 https://pypi.python.org/pypi/towncrier、https://github.com/twisted/newsbuilder 和 http://docs.openstack.org/developer/reno/ 这样的工具。

2016 年 9 月 Python 核心开发者冲刺期间的讨论促成了这一决定，与本 PEP 的 Rejected Ideas 部分中概述的被拒绝方法相比。独立文件方法似乎在各种选项中兼顾了灵活性和潜在工具的正确平衡，同时解决了核心问题。

这项工作正在 https://github.com/python/core-workflow/issues/6 追踪。

处理 Misc/ACKS

传统上，Misc/ACKS 文件 [20] 是手动管理的。但由于 Git 支持每个提交的 author 值和 committer 值，提交的作者身份可以作为代码历史本身的一部分。

因此，Misc/ACKS 的手动管理将变为可选。将编写一个脚本，收集所有作者和提交者姓名，并将它们与迁移到 Git 之前列出的所有姓名合并到 Misc/ACKS 中。运行此脚本将成为发布过程的一部分。

该脚本还应生成自上次执行以来所有贡献者的列表。这将允许获得对特定版本做出贡献的人员列表，以便可以明确地感谢他们。

这项工作正在 https://github.com/python/core-workflow/issues/7 追踪。

创建 https://git.python.org

正如 hg.python.org [1] 目前指向 Python 的 Mercurial 仓库一样，git.python.org 也应该为 Git 仓库做同样的事情。

拉取请求数据备份

由于 GitHub [2] 将用于代码托管和代码审查，因此需要对这两项进行备份。在代码托管的情况下，备份是隐式的，因为所有非浅层 Git [4] 克隆都包含仓库的完整历史记录，因此将有许多仓库备份。

代码审查历史记录没有与仓库本身相同的隐式备份机制。这意味着应该每天进行代码审查历史记录的备份，以防 GitHub 出现任何问题导致数据丢失。它还有助于确保在 GitHub 突然消失的情况下，从 GitHub 迁移到其他代码审查系统是可行的。

生成 cherry-pick 拉取请求的机器人

由于已决定使用 cherry-pick 而不是向前合并分支，因此有一个机器人来根据 cherry-pick 为影响多个分支的任何拉取请求生成拉取请求将非常方便。最可能的设计是一个机器人，它监控已合并的拉取请求，并应用关键标签来区分拉取请求应 cherry-pick 到哪些分支。然后，机器人将为每个标签生成 cherry-pick 拉取请求，并在创建拉取请求时移除标签（这使得在自动 cherry-pick 失败时易于检测）。

这项工作正在 https://github.com/python/core-workflow/issues/8 追踪。

拉取请求提交队列

这将线性地应用已接受的拉取请求，并通过运行测试套件来验证提交是否相互干扰，如果测试运行失败则撤销提交。为了帮助加快测试速度，可以在一次测试运行中同时应用自上次测试运行以来提交的所有补丁，因为乐观的假设是这些补丁将协同工作。如果测试不稳定，将需要某种机制来重新运行测试，无论是通过移除“测试失败”标签、为核心开发者提供触发另一个测试事件的网页界面等。

机器人的灵感或基础可以借鉴现有的机器人，如 Homu [31] 或 Zuul [32]。

给这个机器人命名以发出命令是一个悬而未决的问题：机器人的命名。

CI 服务

有各种 CI 服务为托管在 GitHub [2] 上的开源项目提供免费支持。在尝试了几种 CI 服务后，决定选择 Travis [33]。

Python 目前的 CI 服务是 Pypatcher [38]。可以在 IRC 中提出请求，尝试 bugs.python.org [5] 中的补丁。结果可以在 https://ci.centos.org/job/cPython-build-patch/ 查看。

这项工作正在 https://github.com/python/core-workflow/issues/1 追踪。

测试覆盖率报告

获取 Python 标准库的最新测试覆盖率报告将非常有益，因为生成此类报告可能需要相当长的时间。

有几个现有的服务为开源项目提供免费的测试覆盖率。最终，Codecov [37] 被选为最佳选择。

这项工作正在 https://github.com/python/core-workflow/issues/2 追踪。

通知问题拉取请求评论

目前的开发流程不包括在 Rietveld [6] 上留下审查评论时通知 bugs.python.org [5] 上的问题。最好能解决这个问题，以便人们可以只订阅 bugs.python.org 上的评论，而不是 GitHub [2]，但仍然知道 GitHub 上关于相关拉取请求的审查评论何时发生。目前的想法是在一定时间内（例如，15 或 30 分钟，尽管现在 GitHub 支持 审查，时间方面可能不必要）至少有一条审查评论时，向 bugs.python.org 上的相关问题发布一条评论。这可以减少同时接收 GitHub 和 bugs.python.org 电子邮件通知的人的电子邮件量，同时仍然确保只关注 bugs.python.org 的人知道何时可能有审查评论需要处理。

允许 bugs.python.org 使用 GitHub 作为登录提供商

目前，bugs.python.org [5] 允许人们使用 Google、Launchpad 或 OpenID 凭据登录。最好能将其扩展到 GitHub 凭据。

用于重新生成 Web 内容的 Web 钩子

https://docs.pythonlang.cn/、https://docs.pythonlang.cn/devguide 和 https://pythonlang.cn/dev/peps/ 上的内容都源自本次迁移中要移动的仓库中的文件。因此，最好设置适当的 webhook，以便在它们所基于的文件更改时触发重新构建相应的网页内容，而不是不得不等待（例如）cronjob 触发。

如果文档是一个 Sphinx 项目，那么站点可以在 Read the Docs 上有一个非官方镜像，例如 http://cpython-devguide.readthedocs.io/，这可以部分解决这个问题。

这项工作正在 https://github.com/python/core-workflow/issues/9 追踪。

将 Web 内容链接回其生成的源文件

对于发现从文件生成的任何文档存在问题的人来说，如果每个页面上都有一个链接指向 GitHub [2] 上存储页面内容的文件，那将非常有帮助。这将允许快速拉取请求来修复简单的错误，例如拼写错误。

这项工作正在 http://bugs.python.org/issue28929 追踪。

将部分文档拆分为独立的仓库

虽然 https://docs.pythonlang.cn 上的部分文档会随代码更改而变化，但其他部分则相当静态，并且与 CPython 代码本身没有紧密绑定。以下文档部分属于这种变化缓慢、松散耦合的类别：

• 教程
• Python 安装与使用
• 操作指南
• 安装 Python 模块
• 分发 Python 模块
• 扩展和嵌入
• 常见问题解答

文档的这些部分可以拆分到各自的仓库中，以简化其维护并扩大对它们的提交权限，从而简化其维护。

也有人建议拆分 “新特性” 文档。这需要决定是否可以开发一种工作流程，使得很难忘记更新“新特性”（可能通过添加到 PR 的标签，例如“需要新特性”）。

Git 仓库备份

虽然不是必需的，但最好对各种 Git 仓库进行官方备份，以防灾难。这将由 PSF 基础设施委员会决定这是否值得或不必要。

识别潜在的新核心开发者

Python 开发团队长期以来都有选择新核心开发者的指导方针。指导方针的关键部分是，一个人需要贡献多个被接受的、质量和规模都足够高的补丁，以证明其对 Python 开发流程的理解。可以编写一个机器人来跟踪补丁接受率，并生成一份报告，以帮助识别那些值得考虑成为核心开发者的贡献者。这项工作甚至不一定需要 GitHub 集成，只要所有 git 提交中的 committer 字段都填写正确。

工作正在 https://github.com/python/core-workflow/issues/10 追踪。