Linuxディストリビューションでバグ修正が正確にどのように機能するかを知りたいです。私は、最終的にディストリビューションは、外部開発者が作成したオープンソースソフトウェアで構成され、ディストリビューションマネージャがパッケージ化することを意味します。それでは、各ディストリビューションにはなぜ独自のバグトラッカーがありますか？これらのバグは、そのソフトウェアの原作者に報告するべきではありませんか？
答え1
（私は原作者または元のソフトウェアを上流の作者と上流のソフトウェアと呼びます。なぜなら、それは私がそれらを呼ぶのに慣れているからです。）
エンドユーザーの観点からは、使用しているすべてのソフトウェアについて、さまざまなアップストリームのバグトラッカーにアカウントを登録せずにバグを報告できる場所があれば良いでしょう。
アップストリームの作成者の観点からは、次の理由で展開ユーザーのバグレポートの影響を受けないことをお勧めします。
- ディストリビューションマネージャはバグ自体を導入することができるので（またはディストリビューションパッケージ間のやり取りによってバグが発生する可能性があるため）、これを修正することはアップストリームライターの役割ではありません。
- ディストリビューションには、アップストリームソフトウェアの作成者が気にしない、または処理できない要件がある可能性があります（例えばさまざまなハードウェアアーキテクチャ）。
これは、アップストリームソフトウェアのバグが配信されないという意味ではありません。アップストリームソフトウェアのバグが配信されないことを意味します。ユーザーがリリースバグトラッカーにバグを報告し、そのバグがアップストリームの責任である場合、そのバグはアップストリームバグトラッカーに渡されます。ただし、通常、展開マネージャはこの問題を処理します。複雑なバグの場合、ユーザーは仲介者を避けるために上流に従うように指示される可能性があります。リリースバグトラッカーはこれをうまくサポートし、アップストリームバグトラッカーでバグが変更されると自動的にバグステータスを更新します。
ディストリビューションマネージャの観点から、ディストリビューション自体が達成しようとしているタスク（ライブラリバージョンの変更、新しいツールバー、新しいアーキテクチャ、新しいデプロイツール...）を追跡するには、ディストリビューション固有のバグトラッカーが必要です。
さらに、多くの場合、ディストリビューションは以前のバージョンのパッケージのサポートを提供し、アップストリームの作成者が最新バージョンのソフトウェアでこれらのバグを修正しましたが、これらのバグはまだ存在する可能性があります。この場合、ユーザーが上流の作成者にバグ修正を依頼するのは少し迷惑です。なぜなら、アップストリームの観点からは、バグがすでに修正されているからです。バグが不快な場合は、ディストリビューション管理者が修正をバックポートする必要があります。 （重要パッケージのセキュリティ修正については議論の余地があります。多くのアップストリームでは、以前のバージョン自体に対するセキュリティ修正を提供しています。）
考慮すべきもう一つの要因は、依然として重要なソフトウェアの中にはもはや上流を持たない可能性があるということです。cron例えば、このような状況は長い間持続する可能性がある。ディストリビューションに独自のバグトラッカーがない場合、ユーザーはそのソフトウェアのバグを報告できません。
ほとんどのプロジェクトでは、これらはすべて親しみやすい方法で非常に自然に発生する傾向があります。ディストリビューションマネージャはアップストリーム修正のバグを支援し、逆にディストリビューションマネージャはバグ修正を他のディストリビューションと共有します。