摘要

本 PEP 提议建立一个新的由 PSF 提供的资源 forge.python.org，作为维护各种支持性仓库（例如 Python 增强提案的仓库）的位置，以便新贡献者更易访问，并使核心开发者更易管理。

本 PEP 不提议对 CPython 自身的核心开发工作流程进行任何更改（请参阅PEP 462）。

PEP 撤回

本 PEP 已被作者撤回，以支持PEP 507中基于 GitLab 的提案。

如果其他人愿意接替本 PEP 的倡导工作，请联系核心工作流程邮件列表。

提案

本 PEP 提议将一个自托管的 Kallithea 代码仓库管理系统实例部署为“forge.python.org”。

然后，可以根据具体情况，将各个仓库（例如开发者指南或 PEP 仓库）从现有的 hg.python.org 基础设施迁移到新的 forge.python.org 基础设施。每次迁移都需要决定是在 hg.python.org 上保留一个只读镜像，还是直接整体迁移到新位置。

除了支持 hg.python.org 上的只读镜像外，forge.python.org 还将旨在支持在 GitHub 和 BitBucket 等流行的专有托管站点上托管镜像。目标是允许熟悉这些站点的用户使用他们偏好的工作流程提交和讨论拉取请求，而 forge.python.org 会自动将这些贡献带到主仓库。

鉴于商业支持的“开源项目免费”仓库托管服务的可用性和受欢迎程度，这不会是一个用于任意 Python 项目的通用托管站点。最初的重点将专门放在 CPython 和当前托管在 hg.python.org 上的其他仓库。将来，这可能会扩展到整合目前外部托管的其他 PSF 管理的仓库，以获得基于拉取请求的工作流程，例如 python.org Django 应用程序的仓库。与最初的迁移一样，任何此类未来的迁移都将根据具体情况考虑，并考虑到每个仓库主要用户的偏好。

基本原理

目前，hg.python.org 不仅托管核心 CPython 仓库，还托管 CPython 开发者指南和 Python 增强提案等其他仓库，以及各种用于核心开发者实验的“沙盒”仓库。

虽然 GitHub 和 BitBucket 等代码托管站点流行的简单“拉取请求”式工作流程不足以满足 CPython 各个版本的并行维护和开发所需的复杂分支模型，但它非常适合围绕 CPython 的几个辅助项目，我们不希望将其转移到专有托管站点。

为 PSF 提供的软件锻造提出的关键要求是

• 必须支持简单的“拉取请求”式工作流程
• 必须支持在线编辑以进行简单更改
• 必须由活跃的开发组织（社区或商业）提供支持
• 必须支持在 PSF 基础设施上自托管主仓库，无需持续费用

本提案满足但可能可协商的其他推荐要求，如果提供了足够有说服力的替代方案

• 应该是一个用 Python 编写的完全开源应用程序
• 应该支持 Mercurial（与现有工具保持一致）
• 应该支持 Git（为喜欢它的用户提供该选项）
• 应该允许 Git 和 Mercurial 客户端的用户透明地协作处理同一仓库
• 应该允许 GitHub 和 BitBucket 的用户使用这些工具提供的标准拉取请求工作流程提交建议的更改
• 应该开放定制，以满足 CPython 核心开发的需求，包括为PEP 462中提议的迁移到核心评审员模型提供潜在的未来路径。

倾向于无需持续费用的自托管排除了像 GitHub 和 BitBucket 这样的“免费”提供商，以及各种专有源代码管理产品。

对 Mercurial 支持的偏好不仅排除了 GitHub，还排除了 GitLab 和 Gitorious 等仅支持 Git 的解决方案。

对在线编辑支持的硬性要求排除了 Apache Allura/HgForge 组合。

对完全开源解决方案的偏好排除了 RhodeCode。

在提案作者考虑的各种选项中，剩下Kallithea SCM作为 forge.python.org 服务的基础。

Kallithea 是一个完整的 GPLv3 应用程序（源自 RhodeCode 中明确无误地以 GPLv3 许可的组件），正在Software Freedom Conservancy的主持下开发。Conservancy 已确认 Kallithea 代码库完全合法地以 GPLv3 许可。除了在建立初始 Kallithea 社区方面的作用外，Conservancy 还是 Mercurial 和 Git 项目的法律归属地。Python 用户可能熟悉的其他 SFC 成员项目包括 Twisted、Gevent、BuildBot 和 PyPy。

预期效益

将 Kallithea 部署为 forge.python.org 的主要好处是，开发人员指南和 PEP 仓库等支持性仓库可以潜在地通过拉取请求和在线编辑进行管理。这将比当前的工作流程简单得多，当前的工作流程要求 PEP 编辑器和其他核心开发人员充当中间人来应用其他用户建议的更新。

更丰富的管理功能也将使授予用户对特定仓库的访问权限以进行协作目的变得更加容易，而无需授予他们对整个安装的通用访问权限。这有助于降低进入门槛，因为信任可以更容易地增量授予和获得，而不是在授予核心开发人员访问权限时做出非此即彼的决定。

持续工程考量

即使采用当前的工作流程，CPython 本身仍然是世界上最大的开源项目之一（在 OpenHub 跟踪的项目中，规模处于前 2%）。不幸的是，我们在鼓励对构成 CPython 工作流程基础设施的项目做出贡献方面效率显著降低，包括确保我们的安装跟踪上游，以及在可行的情况下，将我们自己的定制贡献回原始项目。

因此，本提案的一个核心组成部分是积极与上游 Kallithea 社区合作，降低使用 Kallithea SCM 的门槛，并与 PSF 基础设施团队合作，确保 forge.python.org 服务与 PSF 的基础设施自动化无缝集成。

这种方法旨在提供一些关键好处

• 使我们这些为维护此服务做出贡献的人尽可能在可用时间内保持高效率
• 为选择参与此服务维护的志愿者提供有吸引力的专业发展机会
• 通过使其尽可能易于采用、部署和管理，使 Kallithea 项目本身对其他潜在用户更具吸引力
• 由于上述好处，吸引了足够的贡献者，无论是在上游 Kallithea 社区还是在 CPython 基础设施社区，从而使 forge.python.org 服务能够有效地发展以满足不断变化的开发人员期望。

已采取一些初步措施来解决这些持续工程问题

• Tymoteusz Jankowski 一直在与 Donald Stufft 合作，研究使用 PSF 基于 Salt 的基础设施自动化部署 Kallithea 所涉及的工作。
• Graham Dumpleton 和我一直在努力简化在 Red Hat 开源托管服务 OpenShift Online 的免费层部署 Kallithea 演示实例。（请参阅该帖子的评论，或快速入门问题跟踪器以获取 Graham 后续工作的链接）

下一个主要步骤是制定一个本地开发工作流程，允许 Windows、Mac OS X 和 Linux 上的贡献者在本地运行 Kallithea 测试，而不会干扰其自身系统的运行。目前计划的方法是专注于 Vagrant，它是一个流行的自动化虚拟机管理系统，专门针对运行本地虚拟机进行测试的开发人员。OpenShift Origin 的基于 Vagrant 的开发指南提供了一个此类工作流程的扩展示例。还值得注意的是，Vagrant 是处理主 python.org 网站本地构建的选项之一。

如果这些工作流程提案最终对 Kallithea 运行良好，那么也可能值得提议由支持其他 PSF 和 CPython 基础设施服务的上游项目使用，包括 Roundup、BuildBot 和主 python.org 网站。

个人动机

截至 2015 年 7 月，我目前在 Red Hat 担任软件开发工作流程设计师和流程架构师，专注于 Fedora 中的上游开发者体验。其中两个关键体验对于许多网络服务开发人员来说会很熟悉：用于本地容器管理的 Docker，以及用于跨平台本地开发 VM 管理的 Vagrant。花时间在多个上游环境中应用这些技术有助于提供额外的见解，了解哪些方法效果良好，哪些方法仍需进一步改进，以提供良好的软件开发体验，使其在 Fedora 上良好集成，同时也能在其他 Linux 发行版、Windows 和 Mac OS X 上轻松获得。

尤其是在代码评审工作流程方面，我职业生涯中使用的主要代码评审工作流程管理工具是 Gerrit（用于具有细粒度访问控制的多步骤代码评审）、GitHub 和 BitBucket（用于基本的拉取请求工作流程）以及 Rietveld（用于 CPython 的可选预提交评审）。

Kallithea 作为基础项目很有趣，因为它目前是一个结合了仓库托管和代码评审管理功能的平台，但它没有通过提供在线合并来直接集成两者。这为将 GitHub/BitBucket 拉取请求模型的低门槛优势与 Gerrit 的指导和任务交接优势相结合，从而与上游 Kallithea 开发人员合作定义 Kallithea 的在线代码合并模型提供了机会。

技术问题与挑战

将新服务引入 CPython 基础设施带来了许多有趣的技术问题和挑战。本节涵盖了其中几个最重要的。

试点目标和时间表

[TODO：更新本节以适应 Brett 修订后的时间表，该时间表旨在在 10 月 31 日之前上线一个 CPython 演示仓库，以更好地了解 CPython 本身迁移到新系统后未来的功能，而不仅仅是支持性仓库]

本提案是 Brett Cannon 目前对 CPython 开发工作流程各个方面的改进提案进行评估的一部分。该时间表中的关键日期是

• 2月1日：草案提案发布（Kallithea，此 PEP）
• 4月8日：Python 语言峰会讨论最终提案
• 5月1日：Brett 决定接受哪个提案
• 9月13日：Python 3.5 发布，采用 Python 3.6 的新工作流程

如果本提案被选中进行进一步开发，建议从以下试点部署开始实施：

• 在 kallithea-pilot.python.org 上运行的参考实现，至少包含开发者指南和 PEP 仓库。这将是一个“一次性”实例，允许核心开发人员和其他贡献者自由实验，而无需担心仓库历史的长期后果。
• GitHub 和 BitBucket 上 Kallithea 托管仓库的只读实时镜像。与试点服务本身一样，这些将是临时仓库，在试点期结束后将被丢弃。
• 关于如何使用这些镜像对 Kallithea 托管的 Mercurial 仓库创建拉取请求的清晰文档（对于试点，这可能不包括使用这些托管服务的原生拉取请求工作流程）。
• 自动将代码评审评论和提交消息中的问题引用链接到 bugs.python.org 上的相应问题。
• PEP 1的草案更新，解释基于 Kallithea 的 PEP 编辑和提交工作流程。

以下项目将是生产迁移所必需的，但似乎没有明显的方法可以在试点中试用更新的实现。

• 调整 PEP 发布流程和开发者指南发布流程，使其基于已迁移的 Mercurial 仓库。

以下项目是整体工作流程改进过程的目标，但对于 9 月份新服务的首次采用（如果此提案被选中且提议的试点部署成功）而言，被认为是“理想但非必需”的。

• 允许使用 python-social-auth 对 PSF 托管的 Kallithea 实例进行身份验证。
• 允许使用 GitHub 和 BitBucket 拉取请求工作流程向主 Kallithea 仓库提交拉取请求。
• 允许轻松触发基于 Kallithea 托管仓库和拉取请求的强制 BuildBot 运行（在PEP 462实施之前，这旨在用于沙盒仓库而非主 CPython 仓库）。

CPython 核心开发的未来影响

CPython 主开发仓库的工作流程要求远比本 PEP 中讨论的仓库复杂。这些问题在PEP 462中有更详细的介绍。

鉴于 Guido 建议用一个更积极维护的代码审查系统取代 Rietveld，我目前的计划是重写该 PEP，以 Kallithea 作为提议的连接层，并通过增强的 Kallithea 拉取请求最终取代目前直接将补丁文件上传到问题跟踪器的做法。

我还开始与 Pierre Yves-David 合作开发一个自定义 Mercurial 扩展，该扩展可自动化 CPython 核心开发工作流程的某些方面。

版权

本文档已置于公共领域。