PEP 581 – 使用 GitHub Issues 作为 CPython 的问题追踪系统
- 作者:
- Mariatta <mariatta at python.org>
- BDFL 代表:
- Barry Warsaw <barry at python.org>
- 讨论列表:
- Discourse 帖子
- 状态:
- 最终
- 类型:
- 流程
- 创建日期:
- 2018 年 6 月 20 日
- 更新历史:
- 2019 年 3 月 7 日
- 决议:
- Python-Dev 邮件
摘要
本 PEP 概述了从 Python 基于 Roundup 的问题追踪系统迁移到 GitHub Issues 的基本原理。有关详细的迁移计划，请参阅 PEP 588。
基本原理
CPython 的开发于 2017 年 2 月迁移到 GitHub。PSF 组织内的所有其他项目都托管在 GitHub 上，并使用 GitHub Issues。CPython 仍在 bugs.python.org (bpo) 上使用 Roundup 作为问题追踪系统 [1]。
为什么选择 GitHub？
GitHub 拥有许多开箱即用的优秀特性。其中一些特性在 Roundup / bpo 上并不容易获得。
- 可用于构建集成和自动化的 API。GitHub Marketplace 提供各种现有的集成和应用程序来帮助工作流程。新的应用程序可以轻松安装和启用。此外，我们在构建自己的 GitHub 机器人方面取得了巨大成功，例如 miss-islington [2]、bedevere [3] 和 the-knights-who-say-ni [4]。
- 能够将屏幕截图和调试日志文件嵌入/拖放到 GitHub 的拉取请求和问题中。
- 管理员和核心开发者可以编辑问题、评论和拉取请求。
- 能够通过电子邮件回复问题和拉取请求的对话。
- 支持双因素身份验证。
- 支持 Markdown 和 Emoji。
- 预览选项卡，在实际发布之前显示评论的渲染效果。
- 支持通过反应进行投票。
- 支持永久链接 [5]，方便引用和复制粘贴源代码。通过粘贴永久链接，可以在 GitHub 上自动嵌入代码片段。
- 核心开发者、志愿者和 PSF 不必维护问题基础设施/站点，这使我们有更多时间和资源专注于 Python 的开发。
- 能够在 PR 合并后自动关闭问题 [6]。
- 请注意，bpo 中也存在此功能。
- 降低贡献门槛。拥有超过 2800 万用户的 GitHub，开源贡献者更有可能已经拥有帐户并熟悉 GitHub 的界面，从而更容易开始贡献。
- 包含元数据的电子邮件通知 [7]，与 Gmail 集成，允许系统地过滤电子邮件。虽然 Roundup 电子邮件包含一些元数据，但并不像 GitHub 那样全面。
- 额外的隐私，例如为用户提供隐藏电子邮件地址的选择，同时仍然允许通过 @提及与用户进行通信。
Roundup / bpo 的问题
- 维护 bpo 的人数少于 5 人。其中一些人是核心开发者。
- 上游 Roundup 代码位于 Mercurial 中。由于没有任何 CI 可用，这给少数现有维护者带来了沉重的负担，包括审查、测试和应用补丁。虽然 GitHub 上有一个非官方的 Roundup 镜像 [8]，但 Mercurial 补丁仍然是贡献的主要方式。
关于将 bpo 的源代码迁移到 GitHub 的讨论正在进行 [9]。如果 bpo 的源代码迁移到 GitHub，则更新上游补丁将变得困难。但只要它还在 Mercurial 中，就难以维护和吸引新的贡献者。
- 在当前状态下，该项目无法接收来自不熟悉代码库的人员的大量贡献。
- 用户界面需要更新和重新设计。它需要进行 UX/UI 研究，以使其与当前的 Web 标准（包括可访问性）保持一致。
- 用户的电子邮件地址被泄露。
- 注意：将电子邮件地址公开给注册和登录的用户是 bpo 实例设置时做出的决定。在 PEP 581 获批后，此行为最近已修改。
- bpo 目前没有 REST API。Roundup 中有一个添加 REST API 的未解决问题 [10]。在提出 PEP 581 时，该工单自 2016 年以来一直没有活动。REST API 已于 2019 年 2 月集成到 Roundup 中，但尚未集成到 bpo 中。
- 它发送了许多不必要的电子邮件和通知。例如，nosy 邮件，每当有人将自己添加为“nosy”时，就会发送电子邮件通知。自 2012 年以来，上游 Roundup 中就有一个关于此问题的工单，但进展缓慢 [11]。虽然可以配置，但配置请求未得到处理/被忽略。
- 创建帐户一直很麻烦。有报告称人们难以创建帐户或登录。一些未解决工单的示例：“用户名中的逗号导致 nosy 列表出错” [12]、“发生错误...” [13]、“它没有向我发送确认邮件...” [14]。
为什么不选择 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 来说也不是一个独特的问题。作为预防措施，自 2018 年 6 月以来，CPython 在 GitHub 上的存储库每天都会备份。 [15]
- 机器人的维护需要成本，也需要志愿者时间。我们将把维护负担从 Roundup 转移到机器人身上。至少，到目前为止，我们能够在几天内快速解决与机器人/GitHub API 相关的任何错误/问题，而不是几个月或几年。GitHub API 非常广泛，不仅被 CPython 的机器人使用，也被更广泛的 Python 社区使用。与维护 Roundup/bpo 相比，它使 GitHub API 更易于使用。
- 使用 GitHub 可能会增加分类工作量。这首先在 Zulip 主题中提出 [16]，并在 2018 年 9 月的核心 Python 冲刺期间也提出 [17]。已经提出并考虑了一些解决方案，例如创建专门的分类团队 [18]。在 PEP 581 获批后，GitHub 发布了一个新的分类角色，目前处于测试阶段。PSF 已经与 GitHub 联系，以启用 Python 组织的此功能。这正在等待 GitHub 的审查 [19]。
- 使用 GitHub 可能会让人们更容易发布破坏性或垃圾评论。确实发生过核心开发者必须在 GitHub 上审核和锁定破坏性讨论的事件。值得庆幸的是，GitHub 界面使核心开发者可以轻松地审核讨论。此外，事件可以升级到 GitHub。
- 手动编辑问题模板可能很麻烦且容易出错。但是，对于大多数人来说，在 GitHub 上创建问题比在 bpo 上创建问题体验要好得多。众多字段和文本框的选择可能会让新手感到困惑和畏惧，并且无法“编辑”消息。在 GitHub 上，问题创建者可以预览其提交内容，并在发布后编辑错误。
- bpo 使用许多字段来指定多个元数据，这些元数据可能不容易迁移到 GitHub。在 GitHub 上处理自定义元数据的预期方法是使用标签。将在 PEP 588 中进一步讨论要创建哪些标签的详细信息。
进一步的问题和讨论
您可以在 Discourse 上的 核心工作流程 类别下发布问题。
致谢
感谢 Guido van Rossum、Brett Cannon 和 Alyssa Coghlan，他们在本 PEP 的早期阶段和研究中提供了咨询。他们的反馈、担忧、意见和想法非常宝贵。
参考文献
版权
本文档已进入公有领域。
来源：https://github.com/python/peps/blob/main/peps/pep-0581.rst