棄用官方網(wǎng)站！Python 將所有 Bug 遷移到 GitHub 中

來源：OSCHINA

原文：https://www.oschina.net/news/184023/python-bugs-move-to-github

此前，Python 開發(fā)組一直在 Python 官方 Bug 網(wǎng)站 https://bugs.python.org（縮寫為 bpo 或 BPO）上進(jìn)行 Bug 提交、跟蹤和處理，該網(wǎng)站使用開源工具 Roundup 作為 Bug 跟蹤器。

2 月 18 日， Python 核心開發(fā)者 ?ukasz Langa 在 Python Discourse 論壇上宣布：Roundup/BPO 上的所有 Bug 數(shù)據(jù)都將遷移到 GitHub 中，遷移完成后，新的 Bug 在 GitHub Issue 中處理， 原 BPO 官方網(wǎng)站將以只讀模式存在，以避免鏈接失效帶來的一系列問題 。

CPython 的開發(fā)早于 2017 年 2 月就轉(zhuǎn)移到 GitHub Python 倉庫中。因此，在 2018 年 Python 語言峰會上，核心開發(fā)者 Mariatta Wijaya 提議“放棄 Roundup 和 BPO 網(wǎng)站，切換到 GitHub Issues 用于 Bug 跟蹤”，該提議引出了 PEP-581 提案，并于 2019年獲得批準(zhǔn)。

但由于從 Roundup/BPO 到 GitHub 的大遷移涉及的內(nèi)容太多，在技術(shù)上、程序上或法律上都存在復(fù)雜難題，因此直到 2022 年大遷移才正式啟動。

• 2022 年 2 月 18 日，星期五：開始持續(xù)兩周的公眾反饋收集期。
• 2022 年 3 月 4 日，星期五：在 Github 的幫助下執(zhí)行最終的端到端 Bug 數(shù)據(jù)遷移測試，收集遷移所需的時間和出現(xiàn)的問題。（將使用 10% 的 Bug 進(jìn)行測試。）

• 2022 年 3 月 10 日，星期四：遷移開始，BPO 進(jìn)入只讀模式，來自 BPO 的數(shù)據(jù)被導(dǎo)出，并放在 Github 上的臨時存儲庫中。（預(yù)計要 22 個小時）

• 2022 年 3 月 11 日，星期五：Github 將臨時存儲庫中的 Bug 轉(zhuǎn)移到 GitHub 的 Python 庫 ，正式完成遷移。

• 不允許在 Github 或 BPO 上創(chuàng)建新問題
• 倉庫 PR 不受影響，可以在 Github 上創(chuàng)建新的 PR 并與現(xiàn)有 PR 交互

• 可以與 Github 上已遷移的 Issue 進(jìn)行交互，但不鼓勵破壞性操作（更改問題標(biāo)題、編輯評論內(nèi)容、刪除評論、刪除標(biāo)簽），因為數(shù)據(jù)的變化會讓遷移是否有成功變得難以審核。

此外，PEP-581 進(jìn)一步解釋了該遷移計劃的細(xì)節(jié)，對一些常見的疑惑也做出了解答：

• 維護者從未超過 5 個
• 沒有任何 CI 構(gòu)建，審查和測試壓力太大
• UI 老舊

• 天天給用戶發(fā)垃圾郵件，還容易暴露用戶郵件地址

（2）為什么不繼續(xù)優(yōu)化 Roundup/bpo？

優(yōu)化成本太高，“創(chuàng)建和維護 GitHub 集成和審查機器人，工作量遠(yuǎn)低于繼續(xù)優(yōu)化并維護 Roundup。”

（3）為什么選擇 GitHub 而不是其他平臺？

GitHub 功能齊全，而且受眾更廣，大部分程序員都知道如何操作，能降低貢獻(xiàn)門檻。因此，盡管它也有一大堆問題，但仍是目前最優(yōu)解。

放棄了 Roundup/BPO 的同時，也意味著 Python 開發(fā)的基礎(chǔ)設(shè)施已經(jīng)完成了從基于 Python 的開源工具（Mercurial、Roundup）到專有的 GitHub “SAAS” 產(chǎn)品的全面轉(zhuǎn)變（從某種角度來看，這或許也算是開源的一種悲哀？）。

但無論如何，該遷移肯定會吸引很多熟悉、并習(xí)慣使用 GitHub 的新開發(fā)人員來做貢獻(xiàn)，對 Python 的發(fā)展必然大有脾益。