摘要

本 PEP 提议了一系列改进措施，以提高 bugs.python.org 对贡献者和核心开发者的可用性。本 PEP 还讨论了为何应优先保留 Roundup 而非迁移至 GitHub Issues，正如 PEP 581 所提出的那样。

决议

2020-06-25：随着 PEP 581 的通过，向 GitHub 迁移 issues 的工作正在进行中。本 PEP 被标记为已撤回的资料性 PEP。

动机

2019 年 5 月 14 日，PEP 581 在没有太多公开讨论和没有明确共识的情况下被接受。该 PEP 包含事实错误，并未解决迁移到 GitHub Issues 可能带来的某些问题。

鉴于迁移的范围、所需的工作量以及在过渡阶段对工作流程的负面影响，应重新评估此决定。

Roundup 相较于 GitHub Issues 的优势

本节讨论了为何应优先选择 Roundup 而非 GitHub Issues，以及 Roundup 上的一些 GitHub Issues 所不具备的功能。

• Roundup 是现状。 Roundup 多年来一直是 CPython 工作流程的组成部分。它是一个稳定的产品，经过测试和定制，以适应我们不断变化的工作流程需求。

  可以逐步改进它，避免切换到不同系统不可避免地给工作流程带来的中断。

• 开源且由 Python 驱动。 Roundup 是一个开源项目，并用 Python 编写。通过使用和支持它，我们也支持了 Python 生态系统。多年来，为 bpo 开发的许多功能也已被移植到 Roundup 上游。
• 完全可定制。 Roundup 可以（也已经被）完全定制以满足我们的需求。
• 更精细的访问控制。 Roundup 允许为每个单独的属性创建具有不同权限（例如，创建、查看、编辑等）的不同角色，并且用户可以拥有多个角色。
• 灵活的用户界面。 尽管 Roundup 的用户界面可能看起来过时，但它方便且灵活。

  例如，在 issue 页面上，每个字段（例如，标题、类型、版本、状态、链接文件和 PR 等）都有适当的用户界面元素（输入框、下拉列表、表格等），易于设置，并且还能一目了然地提供 issue 的信息。字段的数量、它们的值以及它们使用的 UI 元素也完全可定制。GitHub 只提供标签。

  Issue 列表页面以紧凑易读的表格形式展示 issue，为不同字段设有单独的列。相比之下，Roundup 在一个屏幕上显示 50 个 issue，而 GitHub 需要两个屏幕才能显示 25 个 issue。

• 高级搜索。 Roundup 提供了一种准确的方式，可以使用任何组合的 issue 字段进行搜索和过滤。还可以自定义结果数量、表格中显示的字段以及排序和分组（最多两级）。

  bpo 还提供预定义摘要（例如，“由您创建”、“分配给您”等），并允许创建自定义搜索查询，可以方便地从侧边栏访问。

• Nosy 列表自动补全。 Nosy 列表具有自动补全功能，可建议维护者和专家。当专家索引发生变化时，建议会自动更新。
• 依赖项和后继项。 Roundup 允许指定必须在当前 issue 关闭之前解决的依赖项，以及一个后继 issue 来轻松标记重复项（例如，bpo-12078）。依赖项列表还可以用于创建引用多个其他子 issue 的元 issue（例如，bpo-26865）。

改进 Roundup

本节列出了 PEP 581 中提到的一些问题以及其他期望的功能，并讨论了如何通过改进 Roundup 和/或我们的实例来实现它们。

• REST API 支持。 REST API 将使与其他服务的集成以及新工具和应用程序的开发更加容易。

  上游 Roundup 现在支持 REST API。更新跟踪器将使 REST API 可用。

• GitHub 登录支持。 这将允许用户登录 bugs.python.org (bpo)，而无需创建新帐户。它还将解决确认电子邮件被标记为垃圾邮件的问题，并提供双因素身份验证。

  添加此功能的补丁已可用，并且在撰写本文时正在集成。

• Markdown 支持和消息预览和编辑。 此功能将允许在消息中使用 Markdown，并能够在提交前预览消息并在之后进行编辑。

  这可以做到，但需要一些工作。已在roundup-devel 邮件列表上提出了可能的解决方案。

• “从 Nosy 列表移除我”按钮。 在 issue 页面上添加一个按钮，将自己从 nosy 列表中移除。

  此功能将在 GSoC 2019 期间添加。

• 移动友好主题。 bugs.python.org 的当前主题看起来过时，并且在移动浏览器上效果不佳。

  将添加一个移动友好的主题，它更现代化但仍然熟悉。

• 将回复框移至最后一条消息附近。 回复框位于页面顶部，而最后一条消息位于底部。

  可以将回复框移到最后一条消息之后，或复制一份。

• 实时更新。 当其他用户提交对 issue 的更改时，这些更改应实时显示。

  这可以通过使用 REST API 来实现。

• 在 BPO 邮件中添加 PR 链接。 目前 bpo 邮件不包含指向相应 PR 的链接。

  有一个补丁可以更改 bpo 邮件的内容

  components: +Tkinter
  versions: +Python 3.4
  pull_requests: +42
  

  到

  components: +Tkinter
  versions: +Python 3.4
  pull_request: https://github.com/python/cpython/pull/341
  

• Python 3 支持。 使用 Python 3 将使维护更容易。

  上游 Roundup 现在支持 Python 3。更新跟踪器将允许我们切换到 Python 3。实例也需要更新。

• 使用上游 Roundup。 我们目前使用的是 Roundup 的一个分支，其中包含一些修改，最显著的是 GitHub 集成。如果将此集成移植到上游，我们可以开始使用上游 Roundup，而无需维护我们的分支。

PEP 581 问题

本节针对 PEP 581 中发现的一些错误和不准确之处进行讨论。

PEP 581 的“为何选择 GitHub？”部分列出了目前 GitHub Issues 上提供而在 Roundup 上不提供的功能。其中一些功能目前已支持

• “能够通过电子邮件回复 issue 和 pull request 对话。”
  • 通过电子邮件回复一直是 Roundup 的核心功能之一。还可以创建新 issue 或关闭现有 issue，设置或修改字段，以及添加附件。
• “包含元数据的电子邮件通知，与 Gmail 集成，允许系统化地过滤电子邮件。”
  • Roundup 发送的电子邮件包含可用于过滤的元数据。
• “额外的隐私，例如为用户提供隐藏电子邮件地址的选项，同时仍然允许通过 @提及与用户进行通信。”
  • 对于未注册的用户，电子邮件地址默认是隐藏的。注册用户可以看到其他用户的地址，因为我们配置了跟踪器以显示它们。如果需要，可以轻松更改。即使用户的地址被隐藏，仍然可以通过用户名将其添加到 nosy 列表中。
• “当 PR 被合并时自动关闭 issue 的能力。”
  • Roundup 的 GitHub 集成会自动关闭包含“fixes issue <id>”提交的 issue。（也支持其他拼写，如“closes”或“bug”）。请参阅此消息了解此功能的最新示例。
• “支持永久链接，方便引用和复制粘贴源代码。”
  • Roundup 为 issue、消息、附件等提供永久链接。此外，Roundup 还允许轻松重写消息中损坏的 URL（例如，如果代码托管发生变化）。
• “核心开发人员、志愿者和 PSF 不必维护 issue 基础设施/站点，这使我们有更多时间和资源来专注于 Python 的开发。”
  • 虽然这在一定程度上是正确的，但编写和维护机器人也需要额外的资源。

    在某些情况下，需要机器人来规避 GitHub 的功能缺陷，而不是扩展功能。 此 webhook就是专门为规避 GitHub 的电子邮件集成而编写的。

    更新我们的机器人以跟上 GitHub API 的变化也需要维护成本。 GitHub 引起的这一近期事件花了两天时间才修复。

    此外，我们仍然需要维护 Roundup 以供 bpo（即使它只读）以及我们当前托管/维护的其他跟踪器（Jython 和 Roundup）。

PEP 581 的“Roundup / bpo 的问题”部分列出了一些已修复的问题

• “上游 Roundup 代码使用 Mercurial。由于没有可用的 CI，这给少数现有维护者带来了繁重的审查、测试和应用补丁的负担。”
  • 虽然 Roundup 默认使用 Mercurial，但在 GitHub 上有一个 git 克隆。Roundup 也在 Travis CI 和 Codecov 上提供了 CI。
• “没有可用的 REST API。Roundup 中有一个关于添加 REST API 的未关闭 issue。上次活动是 2016 年。”
  • REST API 已集成，现在可在 Roundup 中使用。
• “用户的电子邮件地址暴露。没有隐藏的选项。”
  • 向注册和登录用户公开地址是在设置我们的实例时做出的决定。

    现在已更改为对普通用户也隐藏电子邮件地址（开发者和协调员仍然可以看到它们）。用户列表页面中的“电子邮件地址”列也被移除。

• “它发送了大量不必要的电子邮件和通知，并且难以（如果不是不可能）配置。”
  • 这可以配置。
• “创建帐户一直很麻烦。有报告称人们在创建帐户或登录时遇到问题。”
  • 主要问题是确认电子邮件被标记为垃圾邮件。已采取措施解决此问题。

迁移注意事项

本节描述了迁移中可能未被 PEP 581 和 PEP 588 解决的问题。

PEP 588 建议添加一个按钮，仅在有人想继续处理 issue 时才将其迁移到 GitHub。这种方法有几个问题，但无论采用何种方法，都还有其他问题需要解决

• 供应商锁定。 GitHub 是专有的，存在供应商锁定的风险。他们的商业模式可能会发生变化，他们可能会完全关闭。例如，在微软收购之后，许多项目决定离开 GitHub。

  如果/当存储库不再可在 GitHub 上访问时，我们将被迫再次迁移，所有指向 issue 的链接将不再有效。

• 必需的 bpo 更新。 bpo 需要更新才能添加一个按钮，该按钮一旦按下，将在 GitHub 上创建一个新 issue，复制所有消息、附件，并为现有字段创建/添加标签。权限也将需要调整，以便在 issue 迁移后将其设为只读，并阻止用户创建新帐户。可能需要设置重定向（见下文）。
• 两个跟踪器。 如果按需迁移 issue，issue 将会分散在两个跟踪器之间。引用和搜索 issue 将需要付出更大的努力。
• 有损转换。 GitHub 添加自定义元数据的唯一机制是通过标签。bpo 使用许多字段来指定不同的元数据。保留所有字段和值将导致过多的标签。如果只保留部分字段和值，其他字段和值将丢失（除非有其他方法可以保留它们）。
• Issue ID 保存。 GitHub 不提供设置和保留已迁移 issue ID 的方法。一些项目通过联系 GitHub 工作人员并批量迁移 issue设法保留了 ID。然而，这已不再可能，因为 PR 和 issue 共享相同的命名空间，并且 PR 已在使用现有的 bpo issue ID。
• 内部 issue 链接保存。 现有的 issue 可能包含对消息和字段中其他 issue 的引用（例如，依赖项或后继项）。由于 issue ID 在迁移过程中会发生变化，因此需要对其进行更新。如果按需迁移 issue，则必须更新所有现有的内部引用（在 bpo 和 GitHub issues 中）。

  为每个已迁移的 issue 在 bpo 上设置重定向可能会缓解此问题，然而 – 如果已迁移消息中的引用未更新 – 这将导致混淆（例如，如果 bpo issue #1234 变成 GitHub issue #4321，则对已迁移消息中#1234的引用可能会链接到 bpo #1234，而 bpo 可以重定向到 GitHub issue #4321，但是对#1234的新引用将链接到 GitHub PR #1234，而不是 GitHub issue #4321）。手动指定bpo-或gh-前缀容易出错。

• 外部 issue 链接保存。 许多网站、邮件等都链接到 bpo issue。如果 bpo 关闭，这些链接将中断。如果我们不想破坏链接，我们将不得不让 bpo 保持运行并设置一个重定向系统来链接到相应的 GitHub issue。

  此外，如果 GitHub 关闭，我们将无法设置重定向并保留指向 GitHub issue 的外部链接。

• 引用保存和更新。 除了 issue 引用之外，bpo 还将许多其他引用转换为链接，包括消息和 PR ID、changeset 号、旧版 SVN 修订号、仓库中的文件路径、traceback 中的文件（检测正确的分支），以及指向 devguide 页面和部分的链接。

  由于 Roundup 在请求消息时将引用转换为链接，因此可以更新目标并生成正确的链接。此需求已经出现过几次，例如：文件和 HG changeset 从hg.python.org移动到 GitHub，devguide 从docs.python.org/devguide移动到devguide.python.org。

  由于 GitHub 上的消息是静态的，因此链接需要在迁移过程中生成并硬编码，否则它们将丢失。为了更新它们，需要编写一个工具来查找所有引用并重新生成链接。

• Roundup 和 bpo 维护。 除了上述对 bpo 的更改和为迁移到 GitHub Issues 所需工具的开发之外，我们仍然需要运行和维护 Roundup，无论是用于我们的 bpo 实例（只读）还是用于 Jython 和 Roundup 跟踪器（读写）。

  即使最终我们将所有 bpo issue 迁移到 GitHub 并停止维护 Jython 和 Roundup，bpo 也需要维护并重定向到相应的 GitHub issue。

• 机器人维护。 由于无法直接自定义 GitHub，因此还需要编写、维护和托管机器人。即使最终我们停止维护 Roundup，维护负担也会从 Roundup 转移到机器人。托管每个不同的机器人也有金钱成本。
• 使用 issue 模板。 手动编辑 issue 模板以“删除不适用于[该] issue 的文本”既麻烦又容易出错。
• 信噪比。 切换到 GitHub Issues 可能会增加无效报告的数量并增加分类工作量。这个问题在过去在Zulip 主题中被提出。

  已经发生过一些情况，例如有人在 PR 上发表评论，需要版主将其标记为跑题或破坏性评论，将其完全删除，甚至锁定对话（例如，此 PR。

• 每周跟踪器报告和统计数据。 Roundup 每周向 python-dev 发送报告，其中包含摘要，包括新 issue、最近没有回复的 issue、最近等待审查的 issue、讨论最多的 issue、已关闭的 issue，以及打开/关闭/总 issue 数量的变化（例如，请参阅此摘要）。该报告提供了一种简便的方式来跟踪跟踪器的活动，并确保需要关注的 issue 得到注意到。

  每周报告收集的数据也用于生成统计数据和图表，可用于获得新的见解。

• 与 bpo 相关的 ML。 目前有两个邮件列表，bpo 会在其中发布新的跟踪器 issue 和所有消息：new-bugs-announce 和 python-bugs-list。需要开发一个新的系统来保留此功能。这些 ML 提供了跟踪跟踪器活动的额外方式。

版权

本文档已置于公共领域。