弃用官方网站!Python 将所有 Bug 迁移到 GitHub 中


此前,Python 开发组一直在 Python 官方 Bug 网站  https://bugs.python.org/ (缩写为 bpo 或 BPO) 上进行 Bug 提交、跟踪和处理,该网站使用开源工具 Roundup 作为 Bug 跟踪器。

2 月 18 日, Python 核心开发者 Łukasz Langa 在 Python Discourse 论坛上宣布 :Roundup / BPO 上的所有 Bug 数据都将迁移到 GitHub 中,迁移完成后,新的 Bug 在 GitHub Issue 中处理,原 BPO 官方网站将以只读模式存在,以避免链接失效带来的一系列问题 。

CPython 的开发早于 2017 年 2 月就转移到 GitHub Python 仓库中。因此,在 2018 年 Python 语言峰会上,核心开发者 Mariatta Wijaya 提议“放弃 Roundup 和 BPO 网站,切换到 GitHub Issues 用于 Bug 跟踪”,该提议引出了 PEP 581 提案,并于 2019年获得批准。

但由于从 Roundup / BPO 到 GitHub 的大迁移涉及的内容太多,在技术上、程序上或法律上都存在复杂难题,因此直到 2022 年大迁移才正式启动。

根据 Łukasz Langa 的介绍,迁移的时间表如下:

  • 2022 年 2 月 18 日,星期五:开始持续两周的公众反馈收集期。
  • 2022 年 3 月 4 日,星期五:在 Github 的帮助下执行最终的端到端 Bug 数据迁移测试,收集迁移所需的时间和出现的问题。(将使用 10% 的 Bug 进行测试。)

如果测试过程没啥问题,就正式迁移

  • 2022 年 3 月 10 日,星期四:迁移开始,BPO 进入只读模式,来自 BPO 的数据被导出,并放在 Github 上的临时存储库中。(预计要 22 个小时)
  • 2022 年 3 月 11 日,星期五:Github 将临时存储库中的 Bug 转移到 GitHub 的 Python 库 ,正式完成迁移。 

在迁移过程中,有如下需要注意的事项

  • 不允许在 Github 或 BPO 上创建新问题
  • 仓库 PR 不受影响,可以在 Github 上创建新的 PR 并与现有 PR 交互
  • 可以与 Github 上已迁移的 Issue 进行交互,但不鼓励破坏性操作(更改问题标题、编辑评论内容、删除评论、删除标签),因为数据的变化会让迁移是否有成功变得难以审核。

此外,PEP 581 进一步解释了该迁移计划的细节,对一些常见的疑惑也做出了解答:

Roundup / bpo 有啥问题?为啥放弃它?

  • 维护者从未超过 5 个
  • 没有任何 CI 构建,审查和测试压力太大
  • UI 老旧
  • 天天给用户发垃圾邮件,还容易暴露用户邮件地址

为什么不继续优化 Roundup / bpo?

优化成本太高,“创建和维护 GitHub 集成和审查机器人,工作量远低于继续优化并维护 Roundup 。”

为什么选择 GitHub 而不是其他平台?

GitHub 功能齐全,而且受众更广,大部分程序员都知道如何操作,能降低贡献门槛。因此,尽管它也有一大堆问题,但仍是目前最优解。

放弃了 Roundup / BPO 的同时,也意味着 Python 开发的基础设施已经完成了从基于 Python 的开源工具(Mercurial、Roundup)到专有的 GitHub “SAAS” 产品的全面转变(从某种角度来看,这或许也算是开源的一种悲哀?)。但无论如何,该迁移肯定会吸引很多熟悉、并习惯使用 GitHub 的新开发人员来做贡献,对 Python 的发展必然大有脾益。


相關推薦

2024-01-03

老化的buildbot基础设施。 PyPy 是一个兼容性强大的 Python 解释器,几乎是 CPython 2.7 与 3.6 的直接替代品。 此次变更,具体影响开发操作等信息,可以查看官方通告:https://www.pypy.org/posts/2023/12/pypy-moved-to-git-github.html

2022-02-25

除内核功能的常见做法,ReiserFS 有可能在实际删除之前被弃用几个内核版本。 从目前的评论来看,看起来 ReiserFS 可能会在 2022 年被弃用,以便在未来的主线 Linux 内核版本中被移除。Dave Chinner 还建议考虑弃用其他未维护且不

2022-05-24

重建。 手动安装的 Python 模块必须针对 3.10 重新编译。 弃用/删除 PHP 7 包已移至测试,因为它很快将 EOL ,取而代之的是 PHP 8

2022-05-26

使 mmap 处理更安全 #21447:BUG:停止使用 Python 3.11 中已弃用的 PyBytesObject.ob_shash #21448:ENH:引入 numpy.core.setup_common.NPY_CXX_FLAGS #21472:BUG:确保正确引发编译错误 #21473:BUG:修复分段错误 #21474:MAINT:更新文档要求 #21475

2023-02-17

加快 Homebrew 维护的 tap 更新。 自 3.6.0 以来的主要更改和弃用: 使用从 formulae.brew.sh 下载的 JSON 文件进行包安装,而不是本地 homebrew/core 和 homebrew/cask taps。 值得注意的是,官方提醒称:这是自其拆分 Homebrew/brew 和 Home

2022-01-25

 Developer Stories2022 年 2 月 —— 用户将开始看到所有已弃用功能的 banners 和 notices2022 年 2 月 —— 薪资计算器将不再可用2022 年 3 月上旬 —— 用户将能够导出与 Jobs & Developer Story 相关的所有数据2022 年 3 月 31 日 —— 所

2022-07-31

间的升级可能多达数千个软件包)。有时,在发生软件包弃用且工程师必须决定如何推进的情况下,很难提供自动化。 据称,谷歌完成所有 Goobuntu 的升级通常要花费一年的时间,整个过程对于团队来说是一个巨大的压力。而且

2023-01-19

在社交媒体和 GitHub 仓库发出公告,宣布 AFNetworking 正式弃用,停止维护。 官方公告如下: 从 2023 年 1 月 17 日开始,AFNetworking 已被弃用,不会再有新的版本。这个仓库将作为一个归档库永久保留。开发者有几个选择可以继

2023-04-04

有一个新的渲染引擎 Datetimes 现在以一致的格式解析 弃用 弃用了将带有系统本地时区的日期时间字符串解析为 tzlocal 的做法,可通过 tz 关键字或明确调用 tz_localize 来代替(GH50791)。 弃用了 to_datetime() 和 read_csv() 中的

2022-12-12

功能正在进入 alpha 阶段,此外还有 12 项功能已被标记为弃用或删除。 Kubernetes v1.26 的主题是 Electrifying。团队希望通过此版本认识到 Kubernetes 赖以开发和使用的所有这些构建块的重要性,同时提高人们对考虑能源消耗足迹的

2022-06-10

源过滤问题。 不推荐使用的扩展- 了解扩展是否已弃用或应该被替换。 添加了对 VS Code 中已弃用的扩展的支持。一个扩展可以被简单地弃用或弃用以支持另一个扩展,或者当它的功能内置到 VS Code 中时。VS Code 将在 Extension

2023-02-12

新功能和 API。 延伸阅读 SQLAlchemy 2.0.0 正式发布,Python ORM 框架

2022-10-19

): 支持 GitLab ( #39381 ) ref:将批处理 kafka 消费者标记为已弃用(#40044) ref(gitlab): 不需要显示令牌(#40045) 添加所有包容性资源(#40047) feat(图表):添加自动生成的咏叹调标签(#39653) fix(auth): 修复device-failed位置 ( #40011 )

2022-12-24

的 Unicode 块名称列表从 Unicode 14.0.0 更新到 Unicode 15.0.0 弃用在完成任务后保留查找/替换的进度对话框的选项。 在查找结果视图中选择匹配行时,使目标文档成为关键窗口 调整菜单中标题的样式 调整打印对话框中的设置摘