要約

  • 個々の修正を安定版へ取り込む審査と、古い系列を長く保守する判断は別々に行われる。
  • Kernel.orgは長期サポートの期間を、下流の需要と保守担当者の余力に結び付けている。予定終了日はベンダーの契約上の保証ではない。

古いカーネルでも、機器によっては公開から何年も使い続けられる。ただし、どんな修正でも安定版へ入るわけではなく、製品の販売期間だけ保守されるとも限らない。Linuxの保守には二つの関門がある。この違いを混同すると、便利な版名を存在しない約束として受け取ることになる。

第一の関門はパッチごとの審査だ。安定版の規則では、修正または同等の修正がすでにメインラインに存在し、明らかに正しくテスト済みであること、コンテキスト込みで100行を超えないこと、提出手順に従うこと、実際の利用者の問題を直すかデバイスIDを追加することが求められる。例として、クラッシュ、停止、データ破損、現実のセキュリティ問題、ハードウェア固有の不具合、ビルドエラーが挙げられている。悪用方法を示さない理論上の懸念や、利用者に利益のない変更は対象外だ。こうした制約は、すでに使われている系列に新たな不具合を持ち込むリスクを抑え、レビューしやすくする。安定版の規則には条件と提出方法が記載されている。

条件を満たしてもレビューは続く。受理された候補はキューに入り、開発者や該当サブシステムの保守担当者が確認し、リリース候補版でテストする。懸念が出ればパッチはキューから外れる。メインラインが先という条件は修正の来歴を定めるもので、すべての古い系列に自動適用する保証ではない。対象系列で意味のある形で適用できるかを確かめ、そこでのレビューを通過する必要がある。

第二の関門は系列自体の寿命だ。Kernel.orgは長期サポート系列を、古いコードツリーに重要なバグ修正を提供する仕組みと説明している。更新頻度は、通常の安定版系列より低い。次の長期系列を選ぶ際には、大きな機能変更、商用ディストリビューションの必要、デバイスメーカーの需要、保守担当者の仕事量と可用性などが考慮される。新しい系列にはまず予定終了日が置かれ、業界からの関心が長期保守を支えれば延長されることがある。Kernel.org自身が、その予定は固定ではないと説明している。今回参照したページには2026年2月25日の日付が表示されていたため、政策の説明には使えるが、掲載された版一覧を2026年10月の現況として扱うことはできない。Kernel.orgのリリース情報が選定要因と予定日の扱いを説明している。

この仕組みにおけるGreg Kroah-Hartmanの役割は重要だが、彼一人が制度全体を動かしているわけではない。Linux Foundationのプロフィールによれば、GregはFellowであり、Linux安定版ブランチと複数のサブシステムを保守している。カーネル開発プロセスの文書は、安定チームのメンバーとしてGregとSasha Levinを挙げ、関連する保守担当者やレビュアーの参加も説明している。Gregは2018年のインタビューで、安定版リリースが始まった2005年に自ら引き受けた開発者の一人だったと振り返った。同時に維持する系列が増え、その仕事を稼働中の機器をより安全に保つことと結び付けている。これは本人の回想であり、現在の系列数でも、長期系列を一人で選んでいる証拠でもない。Linux Foundationのプロフィール、カーネル開発プロセス、Gregへのインタビューは、役割とその範囲を示している。

運用者にとって、この区別はサポートラベルから何を読み取れるかを変える。Kernel.orgの長期系列は、コミュニティが維持するコードラインだ。ディストリビューションはそれを土台にしても、独自変更を加えても、別のカーネルを独自の日程で保守してもよい。Kernel.orgはディストリビューション版を使う人に各ディストリビューションの窓口を案内し、カーネル開発者がそのビルドを支援しない場合があると説明する。したがって運用者は、導入済みイメージの正確なカーネルを誰が保守し、セキュリティ修正や回帰をどの手順で扱い、ベンダーの約束が製品の稼働期間を覆うかを確認する必要がある。LTSというラベルだけでは、こうした契約上の問いに答えられない。Kernel.orgのFAQとリリース情報は、サポートの範囲を区別している。

版番号の裏にある経済の仕組みは単純だが、見えにくい。系列を一つ長く残せば、修正を評価し、バックポートを確認し、リリースをテストし、回帰が起きた際に対応する人が必要になる。公開資料は工数や費用を数値化していない。一方で、下流の必要性と保守担当者の可用性が、どの系列に長い注意を向けるかに影響すると説明している。業界の需要は労力を支える理由になり得るが、作業そのものの代わりにはならない。

Heng LuのNote 64は、分析のための一つの問いを示す。調整文書は将来の状態を記述できても、それだけで現実に運用される状態を生み出すわけではない。この記事はLinuxが同ノートの原則に従って設計されたと主張していない。この視点を限定的に使うと、「長期」や予定日が自動執行される保証ではなく、参加者が維持し続ける取り決めだと分かる。Note 64は分析上の参照であり、カーネル方針の証拠ではない。

分析

二つの関門は異なる層のリスクを分ける。パッチ規則は既存系列に入る変更を絞り、長期系列の選択はコミュニティが維持し続ける古い系列の数を絞る。条件を厳しくしても何年分もの人員は増えず、業界の需要が強くても未審査のバックポートは安全にならない。修正の妥当性と系列を維持する余力の両方が続くときにだけ、実質的なサポートが成立する。

その期間は、変化し得る参加者の組み合わせに左右される。機器メーカーはすでに出荷した装置のために古いカーネルを必要とし、ディストリビューションはリリースの土台を求め、保守担当者にはレビューとテストの時間が必要になる。公開資料は負担の分担や各参加者の交渉力を示していない。ただし、サポート期間が版番号の古さだけではなく、需要と利用可能な労力に応じて決まることは示している。

参考資料