创建“Python核心”团队

为了管理权限，将作为 python 组织 [16] 的一部分创建“Python核心”团队。任何迁移的仓库都将添加“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 存储库中的 .hg/hgrc 文件的 [hooks] 部分中更新

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] 的补丁文件中提交贡献。这显然有助于保持线性历史记录，但需要对其进行修改，以便对补丁作者进行归属。

将作为指导核心开发人员的命令的确切序列是一个未解决的问题： 将拉取请求提交到 cpython 的 Git CLI 命令。

将拉取请求链接到问题

历史上，外部贡献是通过问题附加到 bugs.python.org [5] 上的，因为所有外部贡献都以文件的形式上传。对于由直接提交更改的核心开发人员提交的更改，在消息开头的提交消息中指定问题编号的格式为 Issue #，会导致将一条评论发布到问题中，并将链接指向提交。

更新链接服务以将提交 ID 映射到 URL

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

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

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

弃用 sys._mercurial

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

更新开发指南

devguide 需要更新有关新工作流的详细信息。在迁移实际发生之前，大部分工作很可能在单独的分支中进行。

更新 PEP 101

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

处理 Misc/NEWS

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

计划的方法是为每个新闻条目使用一个单独的文件，其中包含该条目的文本。在这种情况下，每个功能版本都将有自己的新闻条目目录，并且将在该目录中创建一个单独的文件，该文件要么以其关闭的问题命名，要么以时间戳值命名（这可以防止冲突）。跨分支的合并将没有问题，因为新闻条目文件仍将具有唯一的名称，并且位于包含修复程序的最新版本的目录中。一个脚本将收集所有新闻条目文件，无论它们位于哪个目录，并创建一个合适的新闻文件（可以忽略发布目录，因为文件的存在本身就足以表示该条目属于该发布版本）。分类可以通过新条目文件本身的关键字来完成，也可以通过在每个发布目录中使用表示每个新闻条目分类的子目录来完成（或者可以删除新闻条目的分类，因为关键信息由组织好的“新增功能”文档捕获）。这种方法的好处是它将更改与实际更改的代码保持在一起。它还将消息与引入更改的提交相关联。对于通过 CLI 进行的提交，可以提供一个脚本帮助生成文件。在机器人驱动的场景中，合并机器人可以有一种方法来指定特定的新闻条目，并在其扁平化的提交中创建文件（同时很可能也支持在未指定特定新闻条目时使用提交消息的第一行）。如果使用基于 Web 的工作流，则可以使用状态检查来验证拉取请求中是否存在新的条目文件，以提醒缺少该文件。之前已为 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将成为可选操作。我们将编写一个脚本，收集所有作者和提交者姓名，并将它们合并到Misc/ACKS中，所有姓名都列在迁移到 Git 之前。运行此脚本将成为发布流程的一部分。

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

此工作正在 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 进行跟踪。

拉取请求提交队列

这将线性应用已接受的拉取请求，并通过运行测试套件并回滚提交来验证提交之间是否没有干扰，如果测试运行失败。为了帮助加快测试速度，自上次测试运行以来提交的所有补丁可以在单个测试运行下一次应用，因为乐观的假设是这些补丁将协同工作。将需要某种机制来重新运行测试以防测试不稳定，无论是删除“测试失败”标签，还是核心开发人员的 Web 界面来触发另一个测试事件等。

可以从预先存在的机器人（例如 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 分钟）内至少有一条审查评论时，将评论发布到 bugs.python.org 上的相关问题（尽管 GitHub 现在支持 审查，因此时间方面可能是不必要的）。这可以降低接收 GitHub 和 bugs.python.org 电子邮件通知的人员的电子邮件数量，同时仍然确保仅关注 bugs.python.org 的人知道何时可能需要处理审查评论。

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

截至目前，bugs.python.org [5] 允许用户使用 Google、Launchpad 或 OpenID 凭据登录。将其扩展到 GitHub 凭据会很好。

用于重新生成 Web 内容的 Web Hook

位于 https://docs.pythonlang.cn/、https://docs.pythonlang.cn/devguide 和 https://pythonlang.cn/dev/peps/ 的内容都源自保存在要作为此迁移的一部分而移动的仓库之一中的文件。因此，在基于这些文件更改的文件时，设置适当的 Webhook 以触发重建相应的 Web 内容会很好，而不必等待例如 cron 作业触发。

如果文档是一个 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 设置和使用
• HOWTO
• 安装 Python 模块
• 分发 Python 模块
• 扩展和嵌入
• 常见问题解答

这些文档部分可以分解成它们自己的仓库，以简化它们的维护，并扩大对它们的提交权限，以方便它们的维护。

还建议拆分 新增功能 文档。这需要确定是否可以开发一个工作流程，在该工作流程中，忘记更新新增功能会很困难（可能通过添加到 PR 的标签，例如“需要新增功能”）。

Git 仓库的备份

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

识别潜在的新核心开发者

Python 开发团队长期以来一直有选择新核心开发人员的指南。指南的关键部分是，一个人需要贡献多个已接受的补丁，并且这些补丁的质量和大小足以证明他们了解 Python 的开发流程。可以编写一个机器人来跟踪补丁接受率并生成报告，以帮助识别值得考虑成为核心开发人员的贡献者。这项工作甚至不一定需要 GitHub 集成，只要所有 Git 提交中的提交者字段填写正确即可。

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