Mozilla 已正式將 Firefox 的原始碼倉庫從 Mercurial 遷移至 GitHub，標誌著瀏覽器開發基礎設施的重大轉變。這一轉變是 2023 年 11 月 Mozilla 首次宣佈計劃從長期使用的基於 Mercurial 的工作流遷移到 Git 的最終成果。
Firefox 程式碼庫現在可以在 github.com/mozilla-firefox/firefox 找到，但需要注意的是，這一變化主要影響程式碼倉庫本身。Mozilla 將繼續使用 Bugzilla 進行問題跟蹤，Phabricator 進行程式碼審查，以及他們的 Taskcluster 系統進行持續整合。
為何轉向 Git 和 GitHub？
Mozilla 決定遷移到 Git 和 GitHub 解決了幾個長期存在的挑戰。多年來，貢獻者在使用 Mozilla 的 Mercurial 倉庫時面臨著顯著的障礙。Mercurial 克隆過程出了名的緩慢，通常需要數小時才能完成，而 Git 替代方案只需幾分鐘就能完成。這種效能差異為新貢獻者創造了一個顯著的入門障礙。
「我幾年前嘗試過做貢獻。Mercurial 克隆需要好幾個小時。他們當時已經有一個非官方的 git 倉庫，只需 15 分鐘就能克隆完成。」
此外，Mozilla 在大規模維護其版本控制基礎設施時面臨著越來越多的挑戰。VCS 伺服器需要處理來自全球各地的貢獻者，同時保持高可用性和安全性。效能問題尤其嚴重，貢獻者有時需要等待數十分鐘才能獲得鎖定，以便推送到像 try（用於透過 CI 執行補丁）這樣的倉庫。
對貢獻者有何改變？
對於貢獻者來說，最直接的好處是能夠使用標準的 Git 工作流，而無需像以前那樣使用 git-cinnabar 等擴充套件來處理 Mozilla 的倉庫。這降低了已經熟悉 Git 的開發者的入門門檻，而這些開發者代表了當今開發社群的絕大多數。
倉庫結構也已更新，以符合標準的 Git 約定。原來的 mozilla-central 分支已對映為 main，而 autoland（提交首先登陸並在導致測試失敗時回退的地方）仍作為單獨的分支存在。當持續整合測試成功透過時，autoland 分支大約每天合併到 main 分支兩次。
倉庫結構的主要變更
- 原"mozilla-central"分支 → 現在的"main"分支
- 保留"autoland"分支（程式碼提交首先登陸此分支）
- 當持續整合通過後，Autoland 每天約合併兩次到 main 分支
- 停用拉取請求（自動關閉）
- 問題追蹤仍保留在 Bugzilla
- 程式碼審查仍保留在 Phabricator
- CI/CD 仍保留在 Mozilla 的 Taskcluster
什麼沒有改變？
儘管遷移到了 GitHub，Mozilla 並沒有採用 GitHub 的全套功能。透過一個 GitHub action，拉取請求實際上被停用了，該 action 會自動關閉拉取請求，並附上一條訊息引導貢獻者使用 Mozilla 已建立的貢獻渠道。問題仍然保留在 Bugzilla 上，程式碼審查繼續透過 Phabricator 進行。
這種方法允許 Mozilla 受益於 GitHub 強大的程式碼託管功能，同時保持其已建立的開發工作流和工具。保持這些系統分離的決定可能反映了 Mozilla 開發過程的規模和瀏覽器開發的特殊要求。
Firefox 倉庫詳情
- 新位置：github.com/mozilla-firefox/firefox
- 星標數：1.6k
- 分支數：93
- 貢獻者：6,073+
- 主要程式語言構成：
- JavaScript：28.1%
- HTML：22.0%
- C++：10.5%
- Python：2.9%
- Kotlin：2.5%
- 其他：5.5%
社群反應
社群反應大體上是積極的，許多開發者歡迎減少貢獻障礙的做法。然而，一些人對開源專案在 GitHub（一個由 Microsoft 擁有的平臺）上的集中化表示擔憂。還有人質疑為什麼 Mozilla 建立了一個新的組織（mozilla-firefox），而不是使用他們現有的 GitHub 存在（github.com/mozilla）。
Mozilla 選擇 GitHub 而非自託管的替代方案如 Forgejo 或 Codeberg，引發了關於便利性和控制權之間權衡的一些討論。雖然自託管將提供更大的自主權，但 GitHub 為潛在貢獻者提供了無與倫比的可見性和熟悉度。
遷移到 GitHub 代表了一個務實的決定，旨在減少貢獻障礙，同時維持 Mozilla 已建立的開發流程。隨著 Firefox 在瀏覽器市場繼續面臨挑戰，簡化貢獻過程可能有助於重振社群參與並確保專案的長期可持續性。