The Linux 7.4 merge window shut on 1 November carrying a record 18,591 non-merge changesets — and, according to LWN's coverage of the window's second half, a mix weighted heavily toward bug fixes, which appear to be crowding out new feature work.
The scale of the total is easier to gauge against the previous cycle: the full 7.3 development stretch delivered 18,765 changesets, a record in its own right. In other words, 7.4 nearly matched an entire cycle's output inside a single merge window, falling short by just 174 changesets. Of the 7.4 figure, 11,838 landed after LWN's report on the window's first half — roughly two-thirds of the total, concentrated in the closing stretch.
Fixes, not features
That fix-heavy tilt is the most interpretive signal in the numbers, and the data supports more than one reading. The charitable account is procedural: integration only exposes breakage once trees merge, so fixes naturally pile up as the window runs down. The less comfortable possibility is that contributors are becoming more cautious — preferring to stabilise what exists rather than push ambitious new code through review.
The caution is warranted by the metric itself. Changeset counts are coarse. One sweeping mechanical refactor can pad a subsystem's tally without matching engineering effort, while a heavily scrutinised feature may land as a single commit. The fixes-to-features ratio is a trend worth tracking across several cycles, not a standalone judgement on 7.4's technical ambition.
Changes across filesystem work and security subsystems were among the areas followed through the window. With merging complete, Linus Torvalds now turns to stabilisation, and Linux 7.4 is expected to enter release candidate 1.
Why it matters for downstream planning
For enterprises running Ubuntu LTS, RHEL or SUSE Linux Enterprise, merge-window content is the leading indicator for what their distributions will absorb in the coming months. Filesystem and security changes merged now typically surface in downstream kernels one or two release cycles later, and fixes generally travel faster than features — which matters for patch-priority decisions. Organisations planning upgrade paths or hardening reviews should track how 7.4's security and filesystem work maps to the kernels their vendors actually ship, rather than to mainline itself.
Verifying the figures
LWN's article sits behind a paywall, so readers who want to confirm the numbers independently should check Linus Torvalds's merge announcement on the Linux Kernel Mailing List and the git logs for the 7.4 merge window. Those primary sources carry the changeset counts and the merge-window timeline in full, and are the reference points this article's figures should be checked against.
Linux 7.4 合併視窗已於11月1日關閉，合共收錄破紀錄的18,591個非合併 changeset——根據 LWN 對視窗後半段的報道，當中組合嚴重傾向修復錯誤，新功能開發似乎正被排擠。
單看總數難以判斷規模，與上一個開發周期比較便一目了然：完整的 7.3 開發周期共錄得18,765個 changeset，本身已是破紀錄數字。換言之，7.4 僅在單一合併視窗內，產出已幾乎追平整個周期的成果，只差174個 changeset。在 7.4 的數字中，有11,838個是在 LWN 報道視窗前半段之後才進入——約佔總數三分之二，集中於收尾階段。
修復錯誤，而非新增功能
上述以修復為主的傾向，是數據中最具解讀意味的信號，而相關數據同時支持不止一種詮釋。從較為正面的角度看，這屬程序問題：整合工作只有在各程式碼樹合併後才會暴露問題，因此隨著視窗接近尾聲，修復自然堆積。較令人不安的可能性，則是貢獻者變得更加審慎——寧可穩定現有程式碼，也不願推動野心勃勃的新程式碼通過審核。
這種審慎有其指標上的依據。changeset 數量屬粗略指標。一次大範圍的機械式重構，可在工程投入不相稱的情況下推高某個子系統的計數，而一個經過嚴格審視的功能，可能只以單一 commit 形式進入。修復與新功能的比率，是值得跨多個周期追蹤的趨勢，不應作為評判 7.4 技術野心的單一依據。
檔案系統（filesystem）及安全子系統（security subsystem）的改動，是整個合併視窗期間外界持續關注的範圍之一。合併完成後，Linus Torvalds 現將工作轉向穩定化，Linux 7.4 預料即將進入 release candidate 1。
為何與下游規劃息息相關
對於採用 Ubuntu LTS、RHEL 或 SUSE Linux Enterprise 的企業而言，合併視窗的內容是其發行版未來數月將吸收哪些改動的領先指標。此時合併的檔案系統及安全改動，通常會在一至兩個 release cycle 之後於下游核心浮現，而修復一般比新功能傳播得更快——這對制訂 patch 優先次序至關重要。計劃升級路徑或強化（hardening）檢討的機構，應追蹤 7.4 的安全及檔案系統工作如何對應其供應商實際出貨的核心版本，而非只看 mainline 本身。
核實數據
LWN 的文章設有付費牆，讀者如想獨立核實上述數字，應查閱 Linus Torvalds 在 Linux Kernel Mailing List 上的合併公告，以及 7.4 合併視窗的 git logs。這些一手來源完整載有 changeset 數量及合併視窗的時間線，是核對本文數據的參考基準。