摘要

本 PEP 提出了一系列改进措施，旨在使 bugs.python.org 更便于贡献者和核心开发人员使用。本 PEP 还讨论了为什么应该优先选择留在 Roundup，而不是像 PEP 581 中提出的那样切换到 GitHub Issues。

决议

2020-06-25: 随着 PEP 581 的接受，迁移到 GitHub 进行问题跟踪正在进行，本 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 UI 可能看起来过时，但它很方便且灵活。

  例如，在问题页面上，每个字段（例如标题、类型、版本、状态、链接的文件和 PR 等）都有相应的 UI 元素（输入框、下拉菜单、表格等），这些元素易于设置，也提供了一种方便的方式来一览问题信息。字段的数量、其值以及它们使用的 UI 元素也是完全可定制的。GitHub 只提供标签。

  问题列表页面以紧凑易读的表格形式呈现问题，不同字段有单独的列。相比之下，Roundup 在一个屏幕中列出了 50 个问题，而 GitHub 需要两个屏幕才能显示 25 个问题。

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

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

• Nosy 列表自动完成。 Nosy 列表具有自动完成功能，可以建议维护人员和专家。当 专家索引 发生变化时，建议会自动更新。
• 依赖项和替代问题。 Roundup 允许指定依赖项，在关闭当前问题之前必须解决这些依赖项，还可以指定一个替代问题来轻松标记重复的问题（例如，bpo-12078）。依赖项列表还可以用于创建引用多个子问题的元问题（例如，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 列表中删除我”按钮。 在问题页面上添加一个按钮，用于从 Nosy 列表中删除自己。

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

• 移动友好主题。 bugs.python.org 的当前主题看起来过时，并且与移动浏览器不兼容。

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

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

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

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

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

• 将 PR 链接添加到 BPO 邮件。 当前，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 上没有的功能。其中一些功能目前受支持

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

    在某些情况下，需要编写机器人来解决 GitHub 功能的不足，而不是进行扩展。 此 Webhook 是专门为解决 GitHub 的电子邮件集成问题而编写的。

    更新我们的机器人以跟上 GitHub API 的更改也需要维护成本。 GitHub 最近发生的此事件 耗时两天才修复。

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

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

• “上游 Roundup 代码在 Mercurial 中。没有可用的 CI，这给为数不多的现有维护人员带来了沉重的审查、测试和应用补丁的负担。”
  • 虽然 Roundup 默认使用 Mercurial，但有一个 可在 GitHub 上获取的 git 克隆。Roundup 还在 Travis CI 和 Codecov 上提供 CI。
• “没有可用的 REST API。在 Roundup 中有一个关于添加 REST API 的开放问题。最后一次活动是在 2016 年。”
  • REST API 已集成，现在可在 Roundup 中使用。
• “用户电子邮件地址被公开。没有选项可以掩盖它。”
  • 在我们的实例设置时，将地址公开给已注册和登录的用户是一个决策。

    现在已更改此设置，使普通用户也无法看到电子邮件地址（开发人员和协调员仍然可以看到）。用户列表页面中的“电子邮件地址”列也被删除了。

• “它会发送许多不必要的电子邮件和通知，而且很难配置，甚至不可能配置。”
  • 这可以配置。
• “创建帐户一直很麻烦。有报告称人们在创建帐户或登录时遇到问题。”
  • 主要问题是确认邮件被标记为垃圾邮件。已经采取措施来解决这个问题。

迁移注意事项

本节描述迁移中可能没有得到PEP 581和PEP 588解决的问题。

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

• **供应商锁定。**GitHub 是专有的，存在供应商锁定的风险。他们的商业模式可能会改变，他们也可能完全关闭。例如，一些项目在微软收购后决定迁移出 GitHub。

  如果/当存储库不再在 GitHub 上可用时，我们将被迫再次迁移，并且所有指向问题的链接都将不再起作用。

• **所需的 bpo 更新。**bpo 需要更新，以便添加一个按钮，一旦按下该按钮，就会在 GitHub 上创建一个新问题，复制所有消息、附件，并为现有字段创建/添加标签。还需调整权限，以便在问题迁移后将单个问题设为只读，并防止用户创建新帐户。可能需要设置重定向（见下文）。
• **两个跟踪器。**如果问题按需迁移，问题将在两个跟踪器之间分割。引用和搜索问题将需要更多努力。
• **有损转换。**GitHub 唯一添加自定义元数据的机制是通过标签。bpo 使用许多字段来指定多个不同的元数据。保留所有字段和值将导致过多的标签。如果只保留一些字段和值，其他字段和值将丢失（除非存在将其保留在其他地方的方法）。
• **问题 ID 保留。**GitHub 不提供设置和保留迁移问题 ID 的方法。一些项目设法通过联系 GitHub 员工和集体迁移问题来保留 ID。但是，这已不再可能，因为 PR 和问题共享同一个命名空间，并且 PR 已经使用现有的 bpo 问题 ID。
• **内部问题链接保留。**现有问题可能包含指向消息和字段中其他问题的引用（例如依赖关系或替代者）。由于问题 ID 将在迁移过程中发生变化，因此需要更新这些引用。如果按需迁移问题，所有指向已迁移问题的现有内部引用（在 bpo 和 GitHub 问题上）都必须更新。

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

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

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

• **引用保留和更新。**除了问题引用之外，bpo 将许多其他引用转换为链接，包括消息和 PR ID、变更集号、传统 SVN 修订号、存储库中文件的路径、跟踪记录中的文件（检测正确的分支）以及指向 devguide 页面和部分的链接。

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

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

• **Roundup 和 bpo 维护。**除了上述对 bpo 的更改以及开发迁移到 GitHub 问题的工具外，我们仍然需要继续运行和维护 Roundup，既用于我们的 bpo 实例（只读），也用于 Jython 和 Roundup 跟踪器（读写）。

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

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

  已经出现了人们在 PR 上发布评论，需要版主将其标记为离题或破坏性，完全删除它们，甚至锁定对话的情况（例如，此 PR）。

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

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

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

版权

本文档已归入公有领域。