Debian のバグ修正が Ubuntu に比べてなぜそんなに時間がかかるのでしょうか。

DebianとUbuntuはリリースプロセスが非常に異なります。 Ubuntuリリースはスケジュール（設定されたリリース日）に基づいていますが、Debianは「即時使用可能」モデルを使用します。

リリース速度に影響を与えるいくつかの重要な点は次のとおりです。

1. DebianからUbuntuにインポートするほとんどのパッケージは正式にサポートされていません（ユニバースストア）。
2. Ubuntuは2つのアーキテクチャをサポートし、Debianは13をサポートします（一部のバージョンには特定のアーキテクチャに関連する重要なバグがあります）
3. Ubuntuには「重要」エラー重大度がありますが、「リリース重要」エラーの直接的な概念はありません。
4. 4番目のUbuntuリリース（LTS）は本番用にのみ推奨されます。

〜のようにヨルダンリリースサイクルが異なることが指摘されました。 Ubuntuは何があっても毎年4月と10月にリリースされますが、Debianはリリースチームの決定に従って（一部のリリースの重要なバグの数に応じて）準備が整うとリリースしますtesting。stable

別の大きな違いがあります。 CanonicalはUbuntuのコアをサポートするために人々を雇用していますが、Debianには展開作業のために人々に支払うインフラストラクチャはありません。何人かの人々は仕事の一部としてDebianで働いていますが、Debianの誰もDebianの貢献者にリリースに重要なバグ修正を含む特定の作業をするように命令することはできません。だから誰も「この日に修正してください！」と言うことはできません。 （一方、ほとんどのDebian開発者はそのリリースを望んでいると思います。だから...）

この段階でまだ修正する必要があるリリースにとって重要なバグの多くは、再現、修正、および/または確認が困難な複雑なバグです。これは特に資源貢献者の意欲を破ることができる。場合によっては、バグを修正する人にも影響を与えないバグを解決するために数十時間を費やすことを正当化することは困難です。

（誰かが問題を提起する前に、Debian開発者にDebian LTSの操作にかかる費用を支払うことができるインフラストラクチャがありますが、これは新しいバージョンをリリースするのに役立ちません。）

まず、Ubuntuはエラーを「アップストリーム」に渡すことができ、渡す必要があるためです。 2番目の理由は、DebianのブランチがUbuntuよりも具体的だからです。 Debian では、Ubuntu よりもバグを報告するためのより多くのステップがあります。最も重要なのは、Ubuntuが「ダウンストリーム」バージョンであることです。これは、Debianが持っているすべてのバグ修正を得ることができ、DebianがDebianのバグとUbuntuのバグを効果的に修正する他のバグに集中できることを意味します。

たとえば、Ubuntuのfoo.debのバグは「アップストリーム」と表示され、Debianで修正する必要があります。 bar.debのバグはUbuntuとDebianで修正する必要があります。 Ubuntuチームはfoo.debを無視してbar.debに集中できますが、Debianチームはfoo.debとbar.debの両方を処理する必要があります。

別の例はリリースサイクルです。 UbuntuのリリースサイクルはDebianよりはるかに簡単です。たとえば、Debianのパッケージがテストされる前に6〜12ヶ月以上「不安定な」状態にとどまることは驚くべきことではありません。その後、さらに6ヶ月間テストし、「安定」状態に達します。 Debian の場合、これは問題なく Debian stable でミッションクリティカルなサーバーを実行できるため、これは良い方法です。 Ubuntu（LTSバージョンも含む）でミッションクリティカルなサーバーを実行することは不安定で、バグが多いと悪名高いので理想的ではありません。ただし、小規模なサーバーやデスクトップの場合、これらの区別は通常重要ではありません。