PEP 588 – GitHub 发布迁移计划

抽象

此 PEP 描述了从 Python 问题迁移的详细计划 Roundup 到 Github 问题的跟踪器。参见 PEP 581 的基本原理和 背景。PEP 588 还描述了 迁移。

迁移计划

在这里，我们概述了我们需要做出的任务、步骤和核心决策 以便将错误跟踪迁移到 GitHub，对 CPython 开发人员的工作效率。

聘请专业的项目经理

有专业的项目经理来处理迁移，类似于如何 仓库项目得到管理，将有助于确保该项目的成功。

在 GitHub 上创建 playground CPython 问题跟踪器

我们应该在 GitHub 上创建一个 playground 问题跟踪器，我们可以在其中进行实验 并测试新的工作流。

备份 GitHub 数据

这项工作已经开始，并正在作为一个问题进行跟踪 核心工作流 。我们正在使用 GitHub 的迁移 API 来 每天下载 CPython 的 GitHub 数据。档案将 放入 S3 存储桶中。

感谢 Ee Durbin 为此所做的工作。

更新 CLA 主机

目前，CLA 托管在 bpo 中。它需要更新，以便 签署 CLA 不需要 BPO 帐户，它应该托管在外部 BPO的。

目前的共轭亚油酸工艺本身并不理想。目前，贡献者 devguide、peps 和 core-workflow 需要对 CLA 进行签名，并且需要 bpo 帐户。这些项目不需要 bpo 帐户。

我们一直在努力开始使用我们自己的 CLA 实例 助手，而不是当前的 CLA 流程。

这项工作目前停滞不前，因为 cla-assistant 尚不支持代表组织签署的 CLA。

在 GitHub 上创建“Python 分类”团队

bpo 上的 bug 分类器对核心 Python 工作流程很有价值，我们 肯定需要更多帮助来对 GitHub 上的问题进行分类。

在 Discourse 上有人提议我们在 GitHub 上创建一个“bug 分类”团队来帮助关闭 问题，通知相关方，以及应用标签 到问题和拉取请求。

GitHub 上的新会审角色目前处于测试阶段，Python 组织 已被授予此角色的访问权限，我们可以开始利用它。

“Python Triage”团队已创建。对 已将会审角色添加到 Devguide。

该项目的进展可以是 在“添加分类器”项目板中跟踪。

创建用于问题分类的标签

在 BPO 中，我们目前对每个问题都有以下字段：

类型：。behaviorcrashcompile errorresource usagesecurityperformanceenhancement

组件：。。。2to3Argument ClinicasyncioBuildCross-buildctypes

优先权：release blockerdeferred blockercriticalhighnormallow

我们将创建相应的标签：

此外，我们还将创建一个标签。needs triage

要创建的最终“标签”可以在以后决定 是时候开始切换到 GitHub 问题了。

包含所有可能的标签和颜色模式的测试存储库已被 由 Carol Willing 创建。

创建问题模板

我们将创建一个问题模板并添加以下标题：

这个想法是允许问题创建者帮助我们对问题进行分类。 上述值已预先填充在模板中。问题创建者将删除 不适用于其问题的文本。

基于上述标题，bedevere-bot 可以应用必要的 标签添加到问题中。如果问题创建者未提供上述内容 标头，机器人将应用标签。在这一点上， 这将需要核心开发人员正确地标记问题。needs triage

我们还可以利用 GitHub 的多问题模板 功能，以及自动设置问题受托人和 使用问题模板标记。

bedevere 更新

Bedevere-bot 需要更新以识别所描述的问题标头 上面并贴上适当的标签。

Bedevere-bot 还可以将标签复制到对应于 问题。

更新开发指南

开发指南应更新有关使用 GitHub 的新工作流的信息 问题。它可以作为一个单独的分支来完成，并且应该在 迁移，而不是之后。

在 bpo 中添加一个按钮，将问题迁移到 GitHub

这将需要更新 bpo。但我相信需要付出的努力 这比彻底检修要少得多。

我们将在 bpo 中创建一个按钮，该按钮将复制问题描述 并将评论关联到 GitHub 问题中。

我们需要添加一个新状态：“moved”，带有 GitHub 问题的 url。

我们不应该将所有未解决的问题都转移到 GitHub。只有当有人 有兴趣继续工作或讨论该问题， 该问题应“移动”到 GitHub。

迁移的问题

当问题标记为“已移动”时，此问题应处于只读模式。BPO系列 应禁止该问题的编辑。

将 bpo 设置为只读

这应该是最后一步。一旦我们开始使用 GitHub 问题，请制作 bpo 只读，而不是关闭它。 不接受新的注册。不允许创建评论或问题。

bpo 和 GitHub 中的问题之间的映射

通常，当我们引用 bpo 中的问题时，我们使用 bpo-XYZ，但使用 Github，我们将有一个 具有此格式的新参考 .https://github.com/python/cpython/issue/XYZ

因为我们会将问题从 bpo 迁移到 GitHub，所以我们需要一个新的 bpo 上的字段，用于参考 GitHub 上的问题，以及同样的事情 Github 用于 bpo 的“最终”引用。

对于 GitHub，我们需要添加 . 对于 bpo，添加一个新字段 。origin: https://bugs.python.org/issueXYZmoved to: https://github.com/python/cpython/issue/XYZ

与专家打交道

bpo 中的当前功能是自动爱管闲事的人 作为某个领域的专家。几位 Python 核心开发人员表示， 他们宁愿不必订阅 GitHub 上的所有内容，而只收到通知 解决与他们感兴趣和专业领域相关的问题。

为了帮助解决这种情况，我们可以开发一个可以通知人们的机器人 每当使用标签对问题进行分类时。例如，当一个问题 标记为 ，可以通知 Windows 专家。 通知可以采用电子邮件通知的形式，也可以采用 GitHub 上的 @-mention 形式。area-windows

未决问题

不应要求 GitHub 帐户

将 CPython 代码库从 Mercurial 迁移到 GitHub 时是 正在讨论，有人提出我们仍然需要 允许在 BPO 上上传补丁，并且 GitHub 帐户应 不是为 Python 做出贡献的必要条件。

如果 bpo 是只读的，我们需要想出一个不同的解决方案来 允许用户在没有 GitHub 帐户时做出贡献。

与此相关，自 2017 年迁移到 GitHub 以来，我记得一个 案例 其中有一个贡献者，他向 Mercurial 并拒绝创建 GitHub 帐户。正因为如此，我们的 机器人无法检测他们是否已签署 CLA。另一个 有人自愿将他们的补丁上传到 GitHub。但事实确实如此 仍然要求两个人都签署CLA。

这种特殊情况很复杂。它占据了五个核心 开发人员调查和手动检查 CLA 的时间，导致 混乱。

修剪掉“组件”列表

当前的“组件”列表是否仍然有意义和相关性？ 列表可以缩短吗？

优先级列表

当前的“优先级”列表有用吗？Alyssa Coghlan指出，也许只有而且是有用的。release blockerdeferred blocker

版权

本文档已置于公有领域。

The End