PEP 581 – 使用 CPython 的 GitHub 问题

抽象

此 PEP 概述了从 Python 问题迁移的基本原理 Roundup 到 Github 问题的跟踪器。详见 PEP 588 迁移计划。

理由

CPython 的开发于 2017 年 2 月转移到 GitHub。所有其他 PSF 组织内的项目托管在 GitHub 上，并且是使用 GitHub 问题。CPython 仍在使用 Roundup 作为问题 bugs.python.org 跟踪器（BPO）。

为什么选择 GitHub？

GitHub 有很多不错的功能，开箱即用。一些这些在 Roundup / BPO 上并不容易获得。

可用于构建集成和自动化的 API。有各种各样的 GitHub Marketplace 中提供的现有集成和应用程序有关工作流的帮助。可以轻松安装和启用新应用程序。此外，我们在构建自己的 GitHub 机器人方面取得了巨大成功，例如伊斯灵顿小姐、贝德维尔和赛尼骑士团。

能够将屏幕截图和调试日志文件嵌入/拖放到 GitHub 中拉取请求和问题。

管理员和核心开发人员可以编辑问题、评论和拉取请求。

能够通过电子邮件回复问题和拉取请求对话。

支持双因素身份验证。

支持降价和表情符号。

预览选项卡，显示评论的呈现方式，然后实际发布。

支持通过反应投票。

支持永久链接，允许轻松引用和复制粘贴源代码。可以在 GitHub 上自动嵌入代码片段通过粘贴永久链接。

核心开发人员、志愿者和 PSF 不必维护发布基础设施/站点，让我们有更多的时间和资源专注于 Python 的开发。

能够在 PR 合并时自动关闭问题。

请注意，此功能也存在于 bpo 中。

降低贡献门槛。拥有超过 2800 万用户，开放源贡献者更有可能已经有一个帐户并且很熟悉使用 GitHub 的界面，可以更轻松地开始贡献。

包含元数据的电子邮件通知，与 Gmail 集成，允许系统地过滤电子邮件。虽然 Roundup 电子邮件包含一些元数据，它们没有那么广泛。

额外的隐私，例如为用户提供隐藏电子邮件地址，同时仍允许与用户通信通过@-mentions。

Roundup / bpo 的问题

少于 5 人维持 bpo。他们中的一些人是核心开发人员。

上游 Roundup 代码位于 Mercurial 中。没有任何可用的 CI，它给少数现有的维护者带来了沉重的负担查看、测试和应用补丁。虽然有一个非官方的镜子在 GitHub 的 Roundup 中，Mercurial 补丁仍然是贡献的主要方式到它。

关于将 bpo 的源代码移动到 GitHub 。如果 bpo 的源代码确实移动到 GitHub，它将变得难以从上游更新补丁。但只要它在Mercurial中，很难维护和加入新的贡献。

在目前的状态下，该项目不具备接受大量来自还不熟悉代码的人的贡献基础。

用户界面需要更新和重新设计。这将需要UX / UI研究使其与当前的 Web 标准（包括可访问性）保持同步。

用户的电子邮件地址已公开。

注意：向注册和登录用户公开电子邮件地址是一个决定在设置 BPO 实例时拍摄。此行为最近已修改在 PEP 581 接受后。

REST API 目前在 BPO 中不可用。Roundup 中有一个悬而未决的问题用于添加 REST API 。在提出 PEP 581 时，收到了票据自2016年以来没有活动。REST API 已于 2019 年 2 月集成到 Roundup 中，但是，它尚未集成到 BPO 中。

它会发送许多不必要的电子邮件和通知。一个例子是爱管闲事的电子邮件，每当有人将自己添加为“爱管闲事”时，就会发送电子邮件通知。自 2012 年以来，上游 Roundup 中已经就此提出了一个问题，包括牵引力小。虽然可以配置它，但配置它的请求未被解决/忽略。

创建帐户一直很麻烦。有报道称有人在创建帐户或登录时遇到问题。一些不结票的例子： “用户名中的逗号导致 nosy 列表中的错误”， “发生错误 ..， “它没有向我发送确认电子邮件......”.

为什么不是 GitLab？

如果我们在 2017 年迁移到 GitLab 而不是 GitHub，这个 PEP 将是标题为“将 GitLab 问题用于 CPython”。

为什么不是另一个问题跟踪器？

使用另一个问题跟踪器将需要另一个学习曲线，因为拥有学习并习惯不同的界面。我们还需要学习和了解如何构建与 GitHub 的集成。

通过使用 GitHub 问题，CPython 源代码当前所在的位置托管，在发生拉取请求的地方，我们将提供为贡献者和维护者提供一致的体验，而不是必须从一个界面跳到另一个界面。

为什么不专注于改进 Roundup / bpo？

GitHub 有许多我们喜欢的功能，这些功能已经可用。我们仍然需要构建额外的集成并更新我们的机器人，但这是一些东西我们已经知道该怎么做了。

为了真正改进 Roundup/bpo，它需要首先迁移到 GitHub 并添加 CI 和机器人。据我了解，有犹豫，因为上游 Roundup 仍在 Mercurial 中。更熟悉 Roundup / bpo 需求的人支持这一努力。（我不是志愿者，对不起）。

我相信创建和维护 GitHub 集成和机器人的努力比起让 Roundup 跟上速度然后继续维护它。

GitHub 的缺点

GitHub 不是完美的问题跟踪器。我们需要注意的几个问题：

对不确定性和供应商锁定的恐惧。GitHub 是专有的，有供应商锁定的风险。但是，这是一个存在的问题，因为 CPython 的代码库已经在 GitHub 上。这也不是CPython独有的问题。作为预防措施，CPython 在 GitHub 上的存储库有自 2018 年 6 月以来，每天都有备份。

机器人维护需要花钱，也会占用志愿者的时间。我们会将维护负担从农达转移到机器人。至少，到目前为止，我们已经能够解决与机器人/GitHub 相关的任何错误/问题 API 相当快，只需几天，而不是几个月或几年。GitHub上 API 非常广泛，不仅被 CPython 的机器人使用，而且被更广泛的机器人使用 Python 社区。与 Roundup/BPO的维护。

使用 GitHub 可能会增加分类工作。这是首先提出的作为 Zulip 主题，并且在 Core Python 冲刺期间也被提出 2018年9月 .已经提出并考虑了一些解决方案，例如创建一个特殊的分类小组。在 PEP 581 被接受后，GitHub 发布了新的分类角色，目前处于测试阶段。PSF 已与 GitHub 保持联系为 Python 组织启用此功能。这正在等待 GitHub 的审查。

使用 GitHub 可以使人们更容易发布破坏性或垃圾评论。诚然，也曾发生过核心开发人员必须进行审核的事件并将破坏性讨论锁定在 GitHub 上。值得庆幸的是，GitHub 界面使核心开发人员很容易主持讨论。此外，事件可以上报到 GitHub。

手动编辑问题模板可能很麻烦且容易出错。然而对于大多数人来说，在 GitHub 上创建问题将是一种更好的体验而不是在 BPO 上创建问题。可供选择的众多字段和文本框可能会让新人感到困惑和恐吓，这是不可能的以“编辑”消息。在 GitHub 上，问题创建者可以预览他们提交的内容，并在发布后编辑他们的错误。

BPO 使用许多字段来指定多个元数据，但这些字段可能不会可轻松转移到 GitHub。处理自定义元数据的预期方式在 GitHub 上是通过使用标签。要创建哪些标签的详细信息将是在 PEP 588 中进一步讨论。