Linux kernel continuity plan (2026年1月): Linusの後、何が変わるか

多くの人はLinuxカーネルを重力のように扱っています。それは常にそこにあり、すべてが浮き上がるのを防ぎ、それが誤作動した場合に何が起こるか誰も考えたくありません。

Linuxカーネル継続計画は、分散型プロジェクトの最も中心的な部分に対する「もしもの時」をコミュニティがついに書き留めることです。つまり、それを行っている人ができない場合に、誰がメインラインへの変更をプルするかということです。

これ以前は、実際的な答えは「コミュニティが解決するだろう」でしたが、それは通常正しいです。 Linuxカーネル継続計画は、「通常」が重要なインフラストラクチャにとって、もはや安心できる言葉ではなくなったときに書くものです。

Linuxカーネル継続計画：Linuxで製品を出荷するチームにとっての実用的な要点

Linux上で製品を構築している場合、これは個性というよりもリスク管理に関するものです。 Linuxカーネル継続計画最悪のシナリオに関する曖昧さを軽減しますが、運用上の責任が魔法のようになくなるわけではありません。

この計画が認識している技術的な現実を次に示します。カーネル開発は100人以上のメンテナーに分散されており、それぞれが独自のツリーを持っていますが、最上位リポジトリへの最終的なマージは意図的にボトルネックとなっています。そのボトルネックは通常、Linus Torvaldsによって処理されます。

では、どのように対応を変えるべきでしょうか？

「Linuxカーネル継続性計画」を、自身の「翌日」の体制を強化するためのリマインダーとして捉えましょう。

• 特定のカーネルの動作に依存している場合は、CIが失敗したときだけでなく、プロアクティブにアップストリームの変更を追跡してください。

• 大規模にデプロイしている場合は、内部的なカーネルエスカレーションパス（bisectを実行し、候補パッチをテストし、大人としてアップストリームと話ができる人物）があることを確認してください。

• 安定版/LTSに依存している場合は、メインラインの継続性がディストリビューションのパッチスタックを置き換えるわけではないため、安定版メーリングリストのワークフローとバックポートの期待に従ってください。（この計画はメインラインの継続性に関するものであり、ディストリビューションのパッチスタックに関するものではありません。）

これは退屈なアドバイスです。退屈は良いことです。退屈はオペレーティングシステムに求めるものです。

Linuxカーネル継続性計画：なぜ「メインラインマージ」が計画を必要とする部分なのか

「Linuxカーネル継続性計画」は、パイプラインの最後のステップ、つまりメインラインへの変更の取り込みに焦点を当てています。これは、大規模な並列プロセスの上に位置する中央集権的なアクションです。

このドキュメントでは、実際の先例さえ指摘しています。2018年のLinux 4.19リリースサイクル中に、必要に応じて他の人が作業を処理しました。この計画は、コミュニティが一人なしでは無力であると主張しているわけではありません。「これほど高いリスクがある場合に、即興に頼るべきではない」と言っているのです。

Linuxカーネル継続性計画：この文脈における「バスファクター」の意味

多くの報道では、これを「Linusの後継者を探す」という話として捉えています。より正確な捉え方は、「バスファクターを増やす」ということです。

「Linuxカーネル継続性計画」は、トップレベルリポジトリのメンテナーがその仕事（移行の円滑化を含む）を行う意思がない、またはできない場合に明確に存在します。それがバスファクターの問題です。プロジェクトが危機に陥る前に、何人の人がいなくなっても大丈夫でしょうか？

そして、Redditのスレッドでは、そのプロセスが複雑に聞こえるというジョークもありました。それがコメント欄で唯一実用的な「ユーザーフィードバック」であり、それでもなお重要な点です。正式なガバナンスは、必要とされるその日まで、非公式な信頼よりも常に奇妙に見えるものです。

Linuxカーネル継続性計画：実際のメカニズム、明記

「Linuxカーネル継続性計画」で最も重要なのは、それが短く、具体的で、時間制限があることです。後継者を事前に選ぼうとはしません。誰が決定を招集し、決定プロセスをどれだけ早く開始しなければならないかを定義します。

この計画では、Linux Foundationの役割も明確にされています。Linux Foundationは、Technical Advisory Board（TAB）の指導の下、計画をサポートし、実施します。

Linuxカーネル継続性計画：トリガー条件とその理由が限定的なこと

「Linuxカーネル継続性計画」は、円滑な引き継ぎがない場合のためのものです。これは、日常的な退職計画ではなく、「円滑な移行がない」シナリオのためのものです。

それは、ガバナンスが絶え間ない人気投票に変わるのを避けるため、重要です。何かによって強制されない限り、計画は休止状態のままです。

Linuxカーネル継続性計画：オーガナイザーの役割と72時間クロック

Linuxカーネル継続性計画では、$ORGANIZER（通常は直近のメンテナーサミットのオーガナイザー）を定義し、TABチェアをバックアップとします。

トリガーされると、オーガナイザーは72時間以内に直近のメンテナーサミットの招待者と議論を開始し、招待者およびTABとの会議（オンラインまたは対面）を設定します。目的は、参加を最大化することです。

実際には、これは「コンクラーベを今すぐ開始する」ことですが、より少ない役割とより良いWi-Fiを備えています。

Linuxカーネル継続性計画：誰が決めるか、そして何を決めるか

Linuxカーネル継続性計画は、高文脈の会話で既に信頼されている人々、つまりメンテナーサミットの招待者とTABに基づいて意思決定グループを選択します。

過去15か月間にメンテナーサミットが開催されていない場合、TABが招待者セットを決定します。グループは必要に応じて他のメンテナーを招集できます。

彼らは何を決定するのでしょうか？計画は慎重です。会議では、トップレベルのカーネルリポジトリの継続的な管理の選択肢を検討し、プロジェクトとコミュニティの長期的な健全性を最大化する選択を期待します。

これにより、複数の結果の余地が残ります：

• Linus氏の現在の役割を担う新しいプライマリメンテナーを任命すること、

• 複数の人に責任を分散すること、

• またはより正式な委員会モデルへと進化させること。

この計画は特定のガバナンス思想を強制するものではありません。タイムラインを強制します。

Linuxカーネル継続性計画：2週間の締め切りと公開コミュニケーション

Linuxカーネル継続性計画では、2週間以内に代表者がksummitメーリングリストを使用して、次のステップをコミュニティ全体に伝達する必要があります。

ここで2週間という期間は多くの役割を果たします。真剣な議論をするには十分な長さであり、麻痺を避けるには十分短く、下流のエコシステムが数ヶ月の不確実性の中に置かれることを避けるには十分短いのです。

Linuxカーネル継続性計画：メンテナーサミットが選定の基盤である理由

Linuxカーネル継続性計画は、メンテナーサミットに依存しています。なぜなら、そこはすでに高い信頼と高いコンテキストでの調整が行われている場所だからです。複数の報告が、この計画の出現を2025年のメンテナーサミットを巡る議論に関連付けています。

これはガバナンス設計パターンです。既存の組織を正式化できるなら、新しい組織を創設する必要はありません。

Linuxカーネルの継続性計画：現在のLinuxガバナンスについて何を意味するか

Linuxカーネルの継続性計画は、小さな文書ですが、大きな含意があります。Linuxのガバナンスは、創設者がいなくなっても、組織図のようになることなく、存続できるものへと成熟しつつあります。

Tom's Hardwareは、その動機の一部を率直に述べています。コミュニティは「年を取りつつあり」、主要な人々が年を取るにつれて、非公式な継続性に頼ることはより危険になります。

The kernel.orgドキュメントでは、さらに実用的に「プロジェクトは分散されており、最終的なマージは中央集権化されており、トップレベルのメンテナーがその仕事をできない場合は、遅滞なく代替者を見つけなければならない」と述べられています。

Linuxカーネルの継続性計画：形式化がコミュニティの崩壊を意味しない理由

「Linuxカーネルの継続性計画「ついに単一障害点に気づいた」というようなもので、それは必ずしも公平ではありません。

Linuxは以前からフォールバック機能で運用されてきました。ドキュメントには、必要に応じて他の人がマージ作業を行ったことが明示的に参照されています。

変わったのは、エスカレーションパスを文書化する意欲です。それは技術的な修正ではなく、文化的なシフトです。

Linuxカーネルの継続性計画：解決しないこと（そしてそれが問題ない理由）

「Linuxカーネルの継続性計画」が解決しないこと：

• メンテナーの燃え尽き症候群、

• レビュー帯域幅、

• 長期メンテナンスの経済性、

• 物議を醸すサブシステムの政治。

また、選ばれた結果に全員が同意することを保証するものではありません。全員がプロセスについて議論している間にプロジェクトがフリーズしないことを保証します。

継続性ドキュメントの適切なスコープです。

Linuxカーネル継続性計画：人々が実際に検索するFAQ

Linuxカーネル継続性計画FAQ：Linus Torvaldsは引退しますか？

継続性計画自体には、引退が差し迫っているという兆候はありません。カバレッジでは、彼が今すぐカーネルのリードをやめたいという願望を表明していないことが明記されています。

Linuxカーネル継続性計画FAQ：計画はどこに文書化されていますか？

プロセスは、Linuxカーネルドキュメントの「Linuxカーネルプロジェクト継続性」（「コンクラーベ」とも呼ばれる）の下に文書化されています。

Linuxカーネル継続性計画FAQ：プロセスをトリガーするのは誰ですか？

この計画では、通常、最後のメンテナーサミットの主催者が主催者として定義されており、Linux Foundation TABの議長がバックアップとしています。その主催者が72時間以内に議論を開始します。

Linuxカーネル継続性計画FAQ：次のステップを誰が決定しますか？

最近終了したメンテナーサミットの招待者とTABが、コアの意思決定グループを形成します。15ヶ月以内にサミットが開催されていない場合、TABが招待者を決定します。

Linuxカーネル継続性計画FAQ：コミュニティはどのくらいの速さで決定する必要がありますか？

計画は、主催者からの連絡により72時間以内に開始されます。2週間以内に、代表者がksummitメーリングリストでコミュニティ全体に次のステップを伝えます。

Linuxカーネル継続性計画FAQ：これは今日のLinuxパッチのマージ方法を変更しますか？

日常のワークフローは同じままです: サブシステムメンテナーはツリーを管理し、変更は上位に流れ、メインラインのマージは一元化されます。この計画は、トップレベルのメンテナーが職務を遂行できない場合、または移行を促進できない場合にのみ重要になります。

Linuxカーネル継続性計画FAQ：Linux FoundationのTABはなぜここで重要ですか？

TABは、参加者としてプロセスで指名され、最近サミットが開催されていない場合に招待者を決定できる本体であり、Linux Foundationは計画のサポートと実施を委託されています。