摘要

本 PEP 提案建立一个由 PSF 提供的新资源 forge.python.org，用于以更易于新贡献者访问和更易于核心开发人员管理的方式维护各种支持代码库（例如 Python 增强提案代码库）。

本 PEP 不 提案对 CPython 本身的核心开发工作流程进行任何更改（有关该方面，请参阅 PEP 462）。

PEP 撤回

本 PEP 已由作者 撤回，取而代之的是 PEP 507 中基于 GitLab 的提案。

如果有其他人愿意接手这个 PEP，请联系 core-workflow 邮件列表

提案

本 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 提供的软件 forge 的关键要求是

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

本提案满足的额外建议要求，但如果出现足够有说服力的替代方案，可以协商

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

对自托管（无需持续付费）的偏好排除了像 GitHub 和 BitBucket 这样的免费软件提供商，以及各种专有的源代码管理产品。

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

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

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

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

Kallithea 是一个完整的 GPLv3 应用程序（源自明确且毫不含糊地获得 GPLv3 许可的 RhodeCode 组件），在 软件自由保护组织 的支持下开发。该组织已 确认 Kallithea 代码库完全且有效地获得了 GPLv3 许可。除了在建立最初的 Kallithea 社区中的作用外，该组织也是 Mercurial 和 Git 项目的合法归属地。SFC 其他成员项目可能为 Python 用户所熟知，包括 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 和我一直致力于 简化 将演示 Kallithea 实例部署到 Red Hat 的开源托管服务 OpenShift Online 的免费层。（请参阅该帖子上的评论，或 快速入门问题跟踪器 以获取 Graham 后续工作的链接）

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

如果这些工作流程提案最终对 Kallithea 运作良好，它们也值得向支持其他 PSF 和 CPython 基础设施服务的上游项目推荐，包括 Roundup、BuildBot 和主 python.org 网站。

个人动机

截至 2015 年 7 月，我现在在 Red Hat 担任软件开发工作流程设计师和流程架构师，专注于 Fedora 中的上游开发人员体验。这种体验中的两个关键部分将为许多 Web 服务开发人员所熟悉：Docker 用于本地容器管理，Vagrant 用于跨平台本地开发 VM 管理。将时间花在将这些技术应用于多个上游上下文中，有助于进一步了解哪些方法有效，以及哪些方法还需要进一步改进才能提供良好的软件开发体验，该体验在 Fedora 上得到良好集成，但也轻松地在其他 Linux 发行版、Windows 和 Mac OS X 上使用。

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

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

技术问题和挑战

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

试点目标和时间表

[待办事项：根据 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 核心开发工作流程的某些方面。

版权

本文档已置于公有领域。