版本控制系统

需要做出的第一个决定是主要服务器端存储库的版本控制系统（VCS）。目前，CPython 存储库以及许多支持存储库都使用 Mercurial。在评估 VCS 时，我们必须考虑 VCS 本身的功能以及围绕该 VCS 的社区的网络效应和思想份额。

实际上只有两个真正的选择：Mercurial 和 Git。在这两者之间，技术能力在很大程度上是相当的。因此，本 PEP 将在很大程度上忽略有关 VCS 系统的技术论证，而将重点放在社会方面。

无法获得使用特定 VCS 的项目或人员的确切数字，但我们可以通过查看多个信息来源来推断项目正在使用哪个 VCS。

The Open Hub（以前的 Ohloh）的统计数据显示 [1]，The Open Hub 索引的存储库中有 37% 使用 Git（仅次于 SVN 的 48%），而 Mercurial 仅占 2%（仅高于 Bazaar 的 1%）。这意味着 Git 在 The Open Hub 上的受欢迎程度是 Mercurial 的 18 倍多。

关于不同 VCS 流行度的另一个信息来源是 PyPI 本身。此来源更针对 Python 社区本身，因为它代表了为 Python 开发的项目。不幸的是，PyPI 没有一个标准位置来表示此信息，因此需要手动处理。如果我们将搜索范围限制在 PyPI 上的前 100 个项目（按下载量排序），我们可以看到其中 62% 使用 Git，22% 使用 Mercurial，13% 使用其他。这意味着 Git 在 PyPI 前 100 个项目中的受欢迎程度是 Mercurial 的近 3 倍。

显然，从这些数字来看，Git 是迄今为止最流行的开源项目分布式版本控制系统（DVCS），选择更流行的 VCS 会带来许多积极的好处。

对于新贡献者来说，这增加了他们作为参与其他项目的一部分而已经学会 Git 基本知识的可能性，或者如果他们现在才开始学习 Git，那么他们能够将这些知识应用到其他项目中。此外，更大的社区意味着更多的人编写如何操作的指南、回答问题以及撰写有关 Git 的文章，这使得新用户更容易找到他们试图学习的工具的答案和信息。

另一个好处是，由于社区规模更大，将会有更多围绕它编写的工具。这增加了从 GUI 客户端、辅助脚本、存储库托管等各种选择。

存储库托管

此 PEP 提议允许提交 GitHub Pull Requests，但 GitHub 没有办法提交针对非托管在 GitHub 上的存储库的 Pull Requests。此 PEP 还提议，除了 GitHub Pull Requests 之外，还可以使用 Phabricator 的 Differential 应用程序来提交拟议的更改，并且 Phabricator *确实* 允许提交针对非托管在 Phabricator 上的存储库的更改。

因此，此 PEP 提议将 GitHub 作为存储库的规范位置，并在 Phabricator 中设置一个只读镜像。如果将来不再需要 GitHub，那么存储库托管可以轻松地完全迁移到 Phabricator，并且可以放弃接受 GitHub Pull Requests 的能力。

除了在 Github 上托管存储库之外，还将所有存储库的只读副本镜像到 PSF 基础设施。

代码审查

目前 CPython 使用一个自定义的 Rietveld 分支，该分支已被修改为不运行在 Google App Engine 上，目前只能由一个人维护。此外，它还缺少许多现代代码审查工具中存在的功能。

此 PEP 提议允许使用 Github Pull Requests 和 Phabricator 更改来提交更改和审查代码。它同时建议这两种方式，以便贡献者可以选择最适合他们提交更改的工具，并且审查者可以专注于审查他们最喜欢的工具中的更改。

X 不是用 Python 编写的

当前工具（Mercurial、Rietveld）的一个特点是所有组件的主要语言都是 Python。本 PEP 的观点是我们应该专注于工作的*最佳*工具，而不是碰巧用 Python 编写的*最佳*工具。志愿者的时间是任何开源项目的宝贵资源，我们通过关注工具本身的优点和缺点，而不是作者碰巧用什么语言编写它们，来最好地尊重和利用这些时间。

一个担忧是修改工具以适应我们的能力，但这里的目标之一是*不*修改软件来适应我们，而是适应更标准的工作流程。这种标准化带来了无需修改即可重用工具的好处，从而释放了开发人员的时间来实际开发 Python 本身，并促进了项目之间的知识共享。

但是，如果我们需要修改工具，Git 本身主要用 C 编写，与 CPython 本身一样。它也可以用任何语言编写命令，包括 Python。Phabricator 用 PHP 编写，PHP 在 Web 世界中是一种相当普遍的语言，并且相当容易上手。GitHub 本身主要用 Ruby 编写，但鉴于它不是开源的，因此无法修改它，所以它的实现语言完全没有意义。

GitHub 不是自由/开源的

GitHub 是此提案的重要组成部分，而那些更倾向于意识形态而非实用主义的人可能会仅凭这一点就反对此 PEP。本 PEP 的观点是，虽然使用完全自由/开源的软件是一个吸引人的想法和一个崇高的目标，但通过为贡献者提供维护良好且他们已经熟悉或如果他们学会了就可以应用于其他项目的良好工具来重视贡献者的时间，比将某物是否为自由/开源视为硬性要求更重要。

然而，历史表明，有时仁慈的专有公司可能会停止仁慈。这一点通过以下几种方式来规避：

• 我们不使用 GitHub Issue Tracker，原因不仅是它对 CPython 不够强大，而且还因为对于主要的 CPython 存储库，如果我们将来需要离开 GitHub，将我们的问题迁移到其他地方的能力取决于 GitHub 继续允许 API 访问。
• 我们正在使用 GitHub Pull Request 工作流程，但所有这些更改都保存在 Git 中。因此，GitHub 存储库的镜像可以轻松地包含所有这些 Pull Requests。如果我们 GitHub 突然变成“邪恶”的，我们可能会丢失任何评论，但更改本身仍然会存在。
• 我们正在使用 GitHub 存储库托管功能，但由于这只是 Git，因此从 GitHub 迁移就像将存储库推送到另一个位置一样简单。存储库本身的数据可移植性非常高。
• 我们还利用 Phabricator 为那些不希望使用 GitHub 的人提供替代方案。如果将来我们需要停止使用 GitHub，这也可以作为一个已经就位的备用选项。

依赖 GitHub 除了平台本身的优势之外，还带来了许多额外的好处。由于这是一个商业支持的企业，它有全职员工负责维护其服务。这包括确保它们正常运行、确保它们针对各种安全漏洞进行修补，以及随着时间的推移进一步改进软件和基础设施。

Mercurial 比 Git 好

在技术层面 Mercurial 或 Git 哪个更好是一个高度主观的意见。本 PEP 不说明 Git 或 Mercurial 的机制哪个更好，而是侧重于两种选择可用的网络效应。由于本 PEP 提议切换到 Git，这会排除偏爱 Mercurial 的人，但那些用户可以通过使用 hg-git [2] 扩展程序轻松地继续使用 Mercurial，该扩展程序允许它与服务器端为 Git 的存储库一起工作。

CPython 工作流程太复杂

先前讨论中出现的一种观点是，CPython 的多分支模型对于 Github Pull Requests 来说过于复杂。本 PEP 的观点是，这个说法不准确。

目前，任何特定的更改都需要为 2.7 和 3.x 手动创建一个补丁，这在这方面不会有任何改变。

如果有人为当前稳定分支（目前是 3.4）提交修复，则可以使用 GitHub Pull Request 工作流程在浏览器中创建一个 Pull Request，将当前稳定分支合并到 master 分支（假设没有合并冲突）。如果存在合并冲突，则需要在本地处理。这比当前必须始终在本地进行合并的情况有所改进。

最后，如果有人为当前开发分支提交修复，那么如果也希望将其包含在稳定分支中，则必须手动应用。在新的工作流程中，这也必须在本地进行，但对于小的更改，可以在 GitHub Web 编辑器中轻松完成。

从这个角度来看，我认为*任何*系统都无法隐藏维护多个长期运行分支所涉及的复杂性。工具唯一能做的就是使提交更改尽可能容易。