摘要

本 PEP 概述了从 Python 的 Roundup 问题追踪器迁移到 GitHub Issues 的理由。有关详细的迁移计划，请参见 PEP 588。

基本原理

CPython 的开发于 2017 年 2 月迁移到 GitHub。PSF 组织内的所有其他项目都托管在 GitHub 上，并使用 GitHub issues。CPython 仍然在 bugs.python.org (bpo) [1] 上使用 Roundup 作为问题追踪器。

为什么不选择 GitLab？

如果我们 2017 年迁移到 GitLab 而不是 GitHub，那么这个 PEP 的标题将是“将 GitLab Issues 用于 CPython”。

为什么不选择其他问题追踪器？

使用另一个问题追踪器将需要另一个学习曲线，因为必须学习和习惯不同的界面。我们还需要学习并弄清楚如何与 GitHub 构建集成。

通过使用 GitHub issues，CPython 源代码目前托管在此处，拉取请求也在此处进行，我们将为贡献者和维护者提供一致的体验，而无需从一个界面跳到另一个界面。

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

GitHub 拥有许多我们喜欢的功能，并且已经可用。我们仍然需要构建额外的集成并更新我们的机器人，但这是我们已经知道如何做的事情。

为了真正改进 Roundup / bpo，它需要首先迁移到 GitHub 并添加 CI 和机器人。据我所知，由于上游 Roundup 仍在 Mercurial 中，因此存在犹豫。更熟悉 Roundup / bpo 的人需要主导这项工作。（我不是志愿者，抱歉）。

我相信创建和维护 GitHub 集成和机器人的工作量远小于使 Roundup 达到速度并继续维护它所需的工作量。

GitHub 的缺点

GitHub 并不是一个完美的问题追踪器。我们需要注意几个问题。

• 对不确定性和供应商锁定的担忧。GitHub 是专有的，存在供应商锁定的风险。然而，由于 CPython 的代码库已经存在于 GitHub 上，这是一个现有问题。这也不是 CPython 独有的问题。作为预防措施，CPython 在 GitHub 上的存储库自 2018 年 6 月以来每天都在备份。[15]
• 机器人维护成本高昂，也占用志愿者时间。我们将维护负担从 Roundup 转移到机器人。至少，到目前为止，我们已经能够相当快地（几天之内，而不是几个月或几年）解决与机器人/GitHub API 相关的任何错误/问题。GitHub API 广泛，不仅被 CPython 的机器人使用，也被更广泛的 Python 社区使用。这使得 GitHub API 比维护 Roundup/bpo 更易于使用。
• 使用 GitHub 可能会增加分类工作量。这最初是在 Zulip 话题中提出的 [16]，也在 2018 年 9 月的核心 Python 冲刺中提出 [17]。已经提出并考虑了几种解决方案，例如创建一个特殊的分类团队 [18]。在 PEP 581 接受后，GitHub 发布了一个新的分类角色，目前处于测试阶段。PSF 一直与 GitHub 保持联系，以使其在 Python 组织中启用。这正在等待 GitHub 的审查 [19]。
• 使用 GitHub 可能会让人们更容易发布破坏性或垃圾评论。确实发生过核心开发者必须审核和锁定 GitHub 上破坏性讨论的事件。值得庆幸的是，GitHub 界面使核心开发者可以轻松审核讨论。此外，事件可以升级到 GitHub。
• 手动编辑 issue 模板可能繁琐且容易出错。然而，对于大多数人来说，在 GitHub 上创建 issue 将比在 bpo 上创建 issue 体验更好。许多字段和文本框的选择可能会让新人感到困惑和望而生畏，而且无法“编辑”消息。在 GitHub 上，issue 创建者可以在提交前预览其内容，并在发布后编辑其错误。
• bpo 使用多个字段来指定一些元数据，这些元数据可能不易转移到 GitHub。在 GitHub 上处理自定义元数据的预期方法是使用标签。将在 PEP 588 中进一步讨论创建哪些标签的细节。

更多问题和讨论

您可以在 Discourse 的 核心工作流 类别下发布问题。

致谢

感谢 Guido van Rossum、Brett Cannon 和 Alyssa Coghlan，他们在 PEP 的早期阶段和研究中提供了咨询。他们的反馈、担忧、意见和想法都非常宝贵。

参考资料

版权

本文档已置于公共领域。