Fedora 45 has now failed two consecutive release gate checks, putting the distribution's next major version out of reach of an October launch and pushing the earliest realistic ship date into November, according to Phoronix.
The first Go/No-Go meeting last week produced a no-go because the release candidate build simply was not ready in time — there was no RC for the committee to evaluate. A second meeting this week returned the same verdict for a different reason: the build existed, but open blocker bugs remained unresolved. Two no-go votes in a row is an unusual outcome for the Fedora release cycle, and it converts what was a narrow scheduling target into a delay measured in weeks rather than days. Phoronix puts the slip at a further week at minimum.
How the Go/No-Go gate works
For readers who do not follow Fedora's release process, the Go/No-Go meeting is a formal checkpoint held shortly before the planned general availability date. The release team, QA, and other contributors assess whether the candidate build is fit to ship. The check can fail in two distinct ways, and Fedora 45 has now demonstrated both.
A build-readiness failure means there is no releasable artifact at all — the process stops before quality assessment begins. A quality-gate failure is the opposite: the artifact exists, but unresolved blocker bugs are severe enough that shipping would knowingly deliver a broken experience. Blockers are tracked publicly, and they must be fixed, re-verified, or explicitly re-evaluated before a subsequent meeting can return a go. Fedora 45's second failure is of this second type, which means the remaining work is verification and fixes rather than basic build production.
The community discussion around a further meeting following the second no-go has been reported in informal channels, but there is no official announcement confirming that a third session has been scheduled; the release engineering team's published communications should be treated as authoritative on timing.
What the slip means for planners
A one-week-plus delay has practical consequences well beyond the Fedora project itself.
Individual upgraders who planned an early-November or late-October upgrade now have a moving target. Anyone who has blocked out time for a fresh install, a workstation migration, or a validation pass should hold off on committing to dates until a go decision is actually recorded — a third gate attempt, if it succeeds, would be followed by the usual mirrors-and-metalink rollout window rather than an immediate download.
CI and image pipelines are the more sensitive case. Teams that rebuild golden images, container base layers, or hardware validation images against each Fedora release will see their planned refresh windows shift. Because blocker-bug fixes can land late, downstream rebuilds scheduled too tightly against an assumed GA date risk either consuming a candidate that changes underneath them or missing their own downstream deadlines entirely. Building images against a pinned snapshot, rather than against "Fedora 45 GA", remains the safer pattern during a slipping cycle.
Mirror operators and CDN cache teams face a lighter impact, but one worth noting: pre-staging content for an October date means re-planned bandwidth allocations and repeated cache invalidation if GA moves again. For any organisation that coordinates year-end change freezes and upgrade windows, the practical takeaway is that Fedora 45 now lands squarely inside the late-year period when many teams prefer to avoid large platform changes — a general observation about scheduling, not a claim about any specific organisation's plans.
A gate working as intended
It would be easy to read two consecutive no-go votes as a process failure. The evidence points the other way. The gate exists precisely to stop a release that is not ready, and in successive weeks it caught two genuinely different readiness problems. A distribution that shipped despite a missing candidate or open blockers would be the more troubling outcome.
Fedora 45's revised date will be confirmed by the release team once a go vote is recorded.
Source: Phoronix
據 Phoronix 報道，Fedora 45 已連續兩次未通過發佈閘門檢查，令這個發行版的下一個主要版本無法於十月推出，最早可行的發佈日期亦推遲至十一月。
上周首次 Go/No-Go 會議的結果為 no-go，原因是 release candidate 組建並未準時完成——委員會根本沒有 RC 可以評估。本周舉行的第二次會議則因另一個原因得出相同結論：組建已存在，但仍有未解決的 blocker bugs。連續兩次 no-go 表決在 Fedora 發佈周期中相當罕見，這把原本只是很緊的排期目標，變成了以週計而非以日計的延誤。Phoronix 估計至少會再延遲一週。
Go/No-Go 閘門的運作方式
對於沒有跟隨 Fedora 發佈流程的讀者，Go/No-Go 會議是計劃中的 general availability 日期前不久舉行的一個正式檢查點。發佈團隊、QA 及其他貢獻者會評估候選組建是否適合推出。這個檢查有兩種不同的失敗方式，而 Fedora 45 目前已把兩種都演示了一遍。
組建就緒失敗（build-readiness failure）意味著根本沒有可發佈的 artefact——流程在品質評估開始之前就已中止。品質閘門失敗（quality-gate failure）則恰恰相反：artefact 存在，但未解決的 blocker bugs 嚴重到若照常推出，就等同明知故犯地向用戶提供有問題的體驗。Blockers 會公開追蹤，而且必須先完成修復、重新驗證，或經明確重新評估，其後的會議才可能得出 go 結論。Fedora 45 第二次失敗屬於後者，這表示餘下的工作是驗證與修復，而非基本的組建生產。
關於第二次 no-go 之後是否會召開另一次會議，社群討論已有非正式渠道的報道，但暫未有官方公告確認第三場會議已安排；有關時間表，應以發佈工程團隊發出的通訊為準。
延誤對規劃者的影響
延遲一週以上所帶來的實際影響，遠不止於 Fedora 專案本身。
原本計劃在十月底或十一月初升級的個別用戶，如今面對的是一個不斷移動的目標。任何已預留時間進行全新安裝、workstation 遷移或驗證流程的人，都不應在 go 決定正式記錄之前鎖定日期——若第三次閘門嘗試成功，之後仍會跟隨一般的 mirror 及 metalink 推出時間表，而非即時提供下載。
CI 及 image pipeline 是更敏感的情況。那些會針對每個 Fedora 版本重建 golden image、container base layer 或硬件驗證 image 的團隊，其計劃中的更新窗口將會移位。由於 blocker bug 的修復可能很遲才落地，下游重建若過於緊貼假定的 GA 日期來排程，風險在於要麼採用了一個在過程中已變動的候選版本，要麼完全錯過自身下游的期限。在發佈日期持續滑動的周期中，針對固定的 snapshot 而非「Fedora 45 GA」來構建 image，仍然是較安全的做法。
Mirror 營運者及 CDN 緩存團隊受到的影響較輕，但值得一提：若為十月的日期預先準備內容，一旦 GA 再度推遲，就需要重新規劃頻寬分配，並反覆進行緩存失效（cache invalidation）。對於任何需要協調年底凍結變更及升級窗口的機構，實際的啟示是 Fedora 45 現在正好落在年尾時段之內——而這正是許多團隊傾向避免大規模平台變更的時期。這是關於排期的一般觀察，並非針對任何特定機構計劃的說法。
閘門正在發揮應有作用
連續兩次 no-go 表決，很容易被解讀為流程失敗。但證據指向相反的方向。這道閘門存在的意義，正是要攔住尚未準備好的發佈，而在連續兩周內，它成功捕捉了兩個確實不同的就緒問題。反過來，若一個發行版在候選版本缺失或 blocker 未解的情況下仍然推出，才是更令人擔憂的結果。
Fedora 45 的修訂日期，將在 go 表決記錄後由發佈團隊確認。
來源：Phoronix