近几年，GitHub 开发者数量逐年上升，仅过去一年 GitHub 的新增用户便有 1600 万人，总用户数更是达到了 7300 万——在开源浪潮席卷全球中，GitHub 无疑成为了许多开发者迈入开源的一个重要途径。Python 开发团队或许正是看中了这一点，才决定将 Python 开发基础设施逐步迁移至 GitHub。目前这项迁移工作已进行近 7 年，但最近卡在了“将 Python 的 Bug 迁移至 GitHub”这一步。

技术&法律，两面受阻

相信大多 Python 程序员应该有所了解：此前，如需进行 Bug 提交、跟踪、修复等操作，一般可前往 Python 官方 Bug 网站(https://bugs.python.org/，可简称为 BPO)，而 BPO 所用的 Bug 跟踪器为开源工具 Roundup，即由 Roundup 存储 Bug 相关数据。

为了顺利将 Python 的 Bug 迁移至 GitHub，上周 Python 核心开发者 Łukasz Langa 在 Python Discourse 论坛上宣布：

Roundup 中的 Bug 数据将全部迁移至 GitHub 的 Python 存储库中，此后用户和核心开发者发现的新 Bug 统一在 GitHub Issue 中处理;同时为避免 BPO 中 URL 失效引发混乱，之后 BPO 将以只读模式继续存在，而当前 BPO 中存在的每个 Bug 都将链接其 Github 地址。

“我们希望这将降低新贡献者的门槛，并提供更流畅的用户体验。”Łukasz Langa 解释道。

理想很丰满，但现实却很难如意。Łukasz Langa 感慨：“不论在技术还是法律层面上，这都不是一件容易的事。”为此，他自一月份起，就一直与同为 Python 开发者的 Ezio Melotti 共同讨论如何推动本次迁移任务。

复杂的迁移过程

Łukasz Langa 将整个 Bug 迁移工作分为测试反馈阶段及正式迁移阶段：

(1)以下为测试反馈阶段时间表：

2022 年 2 月 18 日开始为期两周的公众反馈收集期。在此期间，开发者可前往 https://github.com/psf/gh-migration/issues/ 查看 Bug 迁移、测试执行等详细步骤并报告具体问题，还可前往 https://github.com/psf/gh-migration/issues 查看一些迁移 Bug 的示例。

2022 年 3 月 4 日，在 Github 的帮助下，使用 10% 的 Bug 执行最终端到端测试迁移，以此估算迁移所需时间及过程中可能会出现的问题。

(2)如果反馈收集过程中没有发现任何问题，最终测试也成功实现，就开启正式迁移阶段：

2022 年 3 月 10 日开始迁移。BPO 在欧洲中部时间晚上 9 点(太平洋标准时间下午 12 点)进入只读模式，BPO 中的数据将被导入 Github 上的临时存储库中(此过程预计需要 22 个小时)。

2022 年 3 月 11 日，Github 开始将临时存储库中的 Bug 全部转移至 Python 库中。

据 Łukasz Langa 预计，正式迁移大概需要花费 3-7 天的时间(具体取决于 Github 的负载)，而 Bug 迁移期间，Python 程序员需要注意以下几点：

不可在 Github 或 BPO 上创建新 Bug;

可以在 Github 上创建新 PR 并与现有 PR 交互，这点不会被影响;

可以与 Github 上已迁移的 Bug 进行交互，但尽量不要有破坏性操作(如修改 Bug 标题、编辑评论内容、删除评论、删除标签等)，因为数据更改会使迁移团队无法确定迁移是否完全成功。

Bug 数据迁移完成后，Python 官方会进行相关通知;但如果迁移无法在 7 天内完成，这项工作将中止并重新启用 BPO。

除了以上技术方面的问题，本次迁移任务还牵扯到了部分法律纠纷，主要集中在“Python 软件基金会(PSF)是否可以在不征求用户同意下，将用户生成的内容及其潜在的个人身份信息(PII)从 BPO 移动到 GitHub”。

关于这个问题，指导委员会和 PSF 律师确定，此次迁移不需要用户同意：

“BPO 和 Github 都是面向公众的系统，用户主动将他们的信息(包括 PII)放在 BPO 系统中，BPO 将根据主动同意存储、公开访问等权限，按需分发这些信息。而我们将后端更改为 Github 并不会修改这些权限，迁移过程中也不会显示之前在 BPO 系统中不允许公开访问的任何新用户信息。”

放弃 BPO 的理由

在看过以上迁移流程后，或许会有人疑惑：既然迁移这样麻烦，继续用 BPO 不“香”吗?针对这类问题，Python 官方早在 2018 年创建的 PEP 581 提案中就明确回应了。

该提案中，罗列出了一串 Roundup/BPO 中已知存在的问题：包括核心开发者在内，维护人员不到 5 人;没有可用的 CI(持续集成)，现有维护人员的负担太大(需要审查、测试和应用补丁);隔绝了来自外界开发者的大量贡献;UI 需重新设计;易暴露用户的电子邮箱，还经常发垃圾邮件给用户;注册新账户过程繁琐…

但这一切问题，可能在部分已习惯 BPO 的开发者眼中，“罪”还不至于被放弃的地步，甚至希望 BPO 维护人员可以就这些问题加以改进。不过，Python 官方坚持认为：“GitHub 中有很多我们喜欢的功能，并且我们相信，创建和维护 GitHub 集成及相关工作量，要远低于加速并维护 Roundup 所需的工作量。”

最后，正如上文所提到的迁移流程，按计划自 3 月 10 日起 Bug 迁移将正式开始，届时相关开发者需注意迁移期间可能会带来的影响。