The Fedora Project has entered the execution phase of its long-anticipated migration from Pagure.io, its self-hosted code forge, to Forgejo — but the transition is far from finished. At the Flock 2026 contributor conference, a Birds-of-a-Feather session titled "Forging Fedora's Future with Forgejo" (abbreviated FFFwF) laid out the current state of the effort and surfaced a key sticking point: a significant number of contributors and teams still have active workflows running on the legacy platform.
According to Fedora Magazine, which reported on the session, the discussion centred on practical migration status rather than future aspirations. As a scoping exercise, participants were asked who still had active content on Pagure.io — a show-of-hands moment that underscored how the community is now treating the move as an operational priority with real-world dependencies still to resolve.
Why Forgejo?
The decision to replace Pagure with Forgejo reflects broader trends across the open-source ecosystem. Pagure, while functional and purpose-built for Fedora's needs, remains a relatively niche forge with a limited upstream development community. Forgejo, by contrast, is an actively maintained, community-driven fork of Gitea that supports the ForgeFed federation protocol — a standard that enables interoperability between independent code forges.
For Fedora, this matters on multiple levels. Federation means that contributions, issues, and pull requests can theoretically flow between Forgejo instances and other compatible platforms without requiring users to maintain accounts on each one. This aligns with Fedora's philosophy of open collaboration and positions the project alongside other major open-source communities that have adopted or are evaluating Forgejo.
The upstream development pace of Forgejo is another draw. With regular releases, active security patching, and a growing contributor base, Forgejo offers a level of long-term sustainability that Pagure's smaller maintainer pool struggles to match.
The Migration Challenge
Despite the strategic rationale, the practical migration involves significant coordination. Fedora's infrastructure spans thousands of repositories, automated CI pipelines, packaging workflows, and contributor toolchains — all of which have deep integrations with Pagure's APIs and interfaces. Moving these to a new platform is not a simple data export; it requires reworking automation, updating documentation, and ensuring that no critical workflow is left behind during the cutover.
The Flock 2026 session highlighted that some teams and contributors remain actively dependent on Pagure.io. Until those dependencies are resolved or migrated, the project cannot fully retire the legacy platform. This dual-operation period introduces maintenance overhead for the Fedora Infrastructure team, which must keep both forges running in parallel.
Broader Implications for Open-Source Infrastructure
Fedora's migration is part of a wider movement in the open-source world toward standardized, federated development tooling. As major projects re-evaluate their infrastructure choices, Forgejo has emerged as a leading candidate for communities that want an open-source-first forge without ceding control to commercial platforms.
The transition also signals a maturation of the Forgejo ecosystem. A flagship Linux distribution choosing Forgejo as its primary development platform serves as a significant vote of confidence, and the lessons learned from Fedora's migration — both the successes and the friction points — will likely inform similar efforts elsewhere.
For open-source contributors watching this transition, the key takeaway is that infrastructure migrations at scale are inherently messy, even within communities with strong technical capabilities. Fedora's transparent, phased approach — acknowledging remaining dependencies publicly rather than imposing an abrupt deadline — offers a model for how large projects can manage such transitions without alienating their contributor base.
The next concrete milestone the community is watching for is a firm timeline for Pagure.io's eventual sunset, along with an inventory of remaining blockers. As of the Flock 2026 discussion, those details were still being worked out — but the direction of travel is clear.
Fedora 專案已進入其期待已久的遷移執行階段，正從其自託管的程式碼託管平台 Pagure.io 遷移至 Forgejo——但這一過渡遠未完成。在 Flock 2026 貢獻者大會上，一場名為「以 Forgejo 鑄造 Fedora 未來」（簡稱 FFFwF）的同好會（Birds-of-a-Feather）會議，闡述了此項工作的現狀，並浮現了一個關鍵癥結：仍有為數不少的貢獻者和團隊在舊有平台上運行著活躍的工作流程。
據報導此會議的 Fedora Magazine 稱，討論集中在實際的遷移狀態，而非未來願景。作為一次範圍界定練習，與會者被問到誰在 Pagure.io 上仍有活躍內容——這一舉手確認的環節突顯了社群如今正將此遷移視為一項具有現實世界依賴性待解決的營運優先事項。
為何選擇 Forgejo？
決定以 Forgejo 取代 Pagure 反映了開源生態系統中更廣泛的趨勢。Pagure 雖然功能完備且專為 Fedora 的需求而建，但仍是一個相對小眾的託管平台，其上游開發社群規模有限。相比之下，Forgejo 是一個積極維護、由社群驅動的 Gitea 分支，支援 ForgeFed 聯邦協議——這是一項能實現獨立程式碼託管平台間互操作性的標準。
對 Fedora 而言，這在多個層面上都至關重要。聯邦化意味著貢獻、issue 和 pull request 理論上可以在 Forgejo 實例與其他相容平台之間流動，而無需用戶在每個平台都維護帳戶。這與 Fedora 開放協作的理念相符，並將該專案定位於其他已採用或正在評估 Forgejo 的主要開源社群之列。
Forgejo 上游的開發節奏也是另一吸引點。憑藉定期的版本發布、積極的安全補丁以及不斷增長的貢獻者基礎，Forgejo 提供了 Pagure 較小的維護者群體難以企及的長期可持續性水平。
遷移挑戰
儘管有其戰略理由，實際的遷移涉及大量的協調工作。Fedora 的基礎設施涵蓋數千個儲存庫、自動化 CI pipeline、打包工作流程和貢獻者工具鏈——所有這些都與 Pagure 的 API 和介面深度整合。將這些遷移到新平台並非簡單的資料匯出；它需要重新設計自動化流程、更新文件，並確保在切換期間沒有關鍵工作流程被遺漏。
Flock 2026 的會議強調，一些團隊和貢獻者仍然積極依賴 Pagure.io。在這些依賴性得到解決或遷移之前，該專案無法完全淘汰舊有平台。這段並行運營期給 Fedora 基礎設施團隊帶來了維護開銷，他們必須同時維護兩個託管平台的運行。
對開源基礎設施的更廣泛影響
Fedora 的遷移是開源世界向標準化、聯邦化開發工具更廣泛運動的一部分。隨著主要專案重新評估其基礎設施選擇，Forgejo 已成為那些希望獲得開源優先託管平台、同時又不願將控制權讓渡給商業平台的社群的領先候選方案。
這一過渡也標誌著 Forgejo 生態系統的成熟。一個旗艦級 Linux 發行版選擇 Forgejo 作為其主要開發平台，這本身就是一個重要的信任票。而從 Fedora 遷移中學到的經驗教訓——無論是成功之處還是摩擦點——很可能會為其他地方的類似工作提供借鑒。
對於關注此過渡的開源貢獻者而言，關鍵要點在於：大規模的基礎設施遷移本質上是混亂的，即使是在技術能力強的社群中也是如此。Fedora 透明、分階段的推進方式——公開承認剩餘的依賴性，而非強加一個倉促的截止日期——為大型專案如何管理此類過渡而不疏遠其貢獻者基礎提供了一個範本。
社群正在關注的下一個具體里程碑，是為 Pagure.io 最終退役確定一個明確的時間表，以及一份剩餘阻礙因素的清單。截至 Flock 2026 的討論，這些細節仍在商議中——但前進的方向是明確的。