信頼性の高いパッケージに関するバグを報告することは実際にどのように役立ちますか？

まず明確にすると、リリース（バイナリ）パッケージとソースソースパッケージの間に違いがあります。一部ディストロテスト、不安定、安定などでリポジトリを取り外します。開発者また、「stable」、「unstable」、「nightly」などのバージョンを保持します。これらは異なる（しかし、バージョン番号は一致します）。

また、ここで「ソースパッケージ」は配布パッケージを意味しません-src。ディストリビューションとは無関係に配布されるソースソースを意味します。つまり、これは通常直接使用しないパッケージです。ディストリビューションでは、このパッケージをバイナリ（および-src）形式で再パッケージ化します。

たとえば、私はfoobar;現在安定したソースコードパッケージはであり1.2.4、現在不安定なソースコードパッケージはです1.2.5。 （私ではない）Debianはこれを配布用にパッケージ化します。現在安定したリポジトリは1.2.3、現在のテストリポジトリはです1.2.5。私（元の開発者）いいえ Debian パッケージまたはどのソースバージョンがどの repo パッケージにあるかを担当します。私は展開用のバイナリバージョンをコンパイルしたりパッケージ化したりしません。ちょうど元のソースを維持している。

これらのエラーレポートも別々です。私は、元の開発者としてリリースパッケージに報告されたバグを読み、応答することも、応答しないこともあります。そうでない場合は、問題に注意を払う必要があり、配布パッケージは元のソースに関するレポートを送信します。

バグが最新バージョンのパッケージ（ベータ版または不安定版）で修正された場合、次のメジャーバージョンがリリースされる前に安定する可能性がありますか？

修正はバックポートされることはほとんどありません。つまり、安定リリースパッケージが 1.2.3 で 1.2.5 に対する修正があることがわかっている場合、次の安定リリースが 1.2.5 リカバリでない限り、その修正は含まれません。つまり、ディストリビューションが次の安定バージョンに1.2.4をリリースする場合、1.2.5の修正はディストリビューションにバックポートされないため、バグはまだ存在します。

ソースコードに関連するバグ（バイナリパッケージのWRT、時にはそうではないかもしれません）は、元の開発者が新しいバージョンのソースコードを修正し、それをリリースパッケージの対応するバージョンにマージする必要があります。ディストリビューションで独自にパッチを当ててバージョンにサフィックスを追加して表示する場合があるため、いくつかの例外があります (例:) ソースの1.2.4-1後続バージョンに修正がある場合にはそうではないと思います。

実際には、2年または3年の最新バージョンで作業している開発者に役立ちますか？

これはバグを修正するかどうかによって異なります。バージョン管理のポイントは固定されていることです。バージョン1.2.3がリリースされると、何が起こっても変更できません。 1.2.3で問題を修正すると、次のバージョンに修正が表示されます。長年にわたって中断された場合、バージョンはおそらく1.2.6などです。

したがって、最新バージョンのソースコードで修正されたことがわかっている場合は、元の開発者に報告する必要はありません。 しかし、現在のディストリビューションで使用されている安定したバージョンでバグがまだ報告されていない場合（ソースとパッケージについて報告されているバグが異なることに注意してください）、それを報告し、それ以降のバージョンのバグが報告されていることを示す必要があります。源泉。繰り返しますが、配布パッケージやバグレポートを担当する人は元の開発者とは異なることに注意してください。したがって、私が問題を解決したとしても、ディストリビューションの包装業者はそれを知らないか気にしないかもしれません。問題を報告すれば、引き続き情報を得ることができますが、彼らに与える（私ではありません）、あなたは明らかに彼らの注意を引いた。これは彼らが安定したパッケージをアップグレードすることを奨励するかもしれません（他のディストリビューションはそれに異なる基準を使用します）。