新しいUbuntuリリースがリリースされると、バグの数は減りますか？
buntuリリースごとのバグの数（... 10.04、10.10、11.04、...）を数えることができれば、それは減少する線でしょうか？
そうでない場合は、なぜですか？以前の問題を修正するのは、新しいリリースの全体ではありませんか？完璧なUbuntu LTSを夢見ることはできませんか？
いいえ。新しいリリースには新しいソフトウェアとソフトウェアの新しいバージョンが含まれるため、それらにはまったく新しいバグがあります。
新しいハードウェアは、新しいドライバー、新しいソフトウェア、したがって新しいバグももたらします。
以前の問題を修正するのは、新しいリリースの全体ではありませんか？
また、ソフトウェアを削除し、フットプリントの小さい他のソフトウェアに切り替えることでバグを修正することもできます（バグが少ないため、コードが少ないほどバグが少なくなる傾向があります）。
例として：GnomeからUnityに切り替えました。したがって、古いリリースにはUnityに関するバグはなく、新しいバージョンには多くのバグがあり、Gnomeを使用したUbuntu派生物がまだあります。そのため、これらのUnityバグにより、バグ数が増加しました。
error-tracker ？ errors.ubuntu.com および...
例として、Ubuntu 18.04までは、おそらくバグの量が2倍になるでしょう。 「古い」Unity7だけでなく、対処する「新しい」Unity 8も用意します。独自のスタイルの問題（別名、バグ）を持つ完全に新しいデスクトップエクスペリエンス。
興味深いリンクリストに追加するには： bugs launchpad には、タグ付きのバグのリストがあります。また、リリース固有のバグも含まれます（ほとんどのバグはおそらくリリース固有ではありません）：
57 zesty
2346 yakkety
3043 xenial
2382 wily
4415 vivid
37 utopic
2724 trusty
1 saucy
1995 precise
これを見ると、量はリリース間で大きく異なります。 YakketyはXenialやVividと比べてかなり良い結果を出しています。
Ubuntuのリリースごとのバグの数（... 10.04、10.10、11.04、...）を数えることができれば、それは減少する行でしょうか？
これは減少する傾向がありますが、これはソフトウェア開発です。それでは、ソフトウェア開発について少し話しましょう。
ソフトウェア開発は科学ではありません！それは芸術です！
誰かがソフトウェアを書くとき、彼らは推測をしています。彼らは物事を試しています。彼らは普通にコーディングしていますが、それは（残念ながら）誰も予想も見えなかったバグを作成する傾向があります。コードの一部にバグがないことを保証する方法はまったくありません。ソフトウェア開発者は人間です
「エラーは人間です」人間は完璧ではありません。彼らは間違いを犯します。彼らは変数を変更することを忘れています。彼らは、Ubuntuをクラッシュさせる奇妙なトリガーを認識できません。この場合、ソフトウェア開発は生死ではありません
Ubuntuには、自身を更新する機能が備わっています。 「これは二度と変えられないので、これは100％バグがなく、テストする必要がある」という考え方は同じではありません。間違いは後で修正できるため、間違いを犯してもかまいません。これは意図的にバグを無視する言い訳ではありませんが、奇妙なEdgeケースをカバーしていないためにテストが行われるため、物事がずれる可能性があります。それ以外の場合、Edgeのケースは非常にエッジであるため、すべての歴史の中で2人がそのバグを引き起こす可能性があります。
以前の問題を修正するのは、新しいリリースの全体ではありませんか？
新しいリリースには、新しい機能とバグ修正が含まれています。残念ながら、新しい機能は新しいバグも意味します。
完璧なUbuntu LTSを夢見ることはできませんか？
私たちは夢を見ることができますが、それだけです。それは人間が書いたコードです。それは完璧ではなく、決して完璧ではありません。プログラム、特にUbuntuほど複雑なものはありませんeverは完璧です。
Error Tracker でこの効果を視覚的に確認することもできます。リリースごとに、さまざまなパッチやバグ修正によって管理可能なレベルに戻るまで、バグやさまざまな急増によって引き起こされるエラーの数。
TL; DR：申し訳ありませんが、バグはソフトウェア開発の一部です。
各ubuntuがそのコンポーネントソフトウェアの同じバージョンにとどまっている場合、バグの量に下向きの軌跡をたどることができますが、ubuntuを構成するさまざまなパッケージに機能を追加するために変更が加えられるため、すべての変更で新しいバグが到着します。
すべてのバグが解決できるわけではありません。綿密な調査の下でより多くのバグに分割され、いくつかはより少ないバグに分割されます。
もう1つの要因は、ユーザーベースが拡大していることです。これは、バグを発見する可能性が増えること（使用時間が長くなること）を意味します。
さらに別の要因は、ubuntuは絶えず変化する非常に多様なプラットフォームで実行されることです。いくつかのバグは、ubuntuのせいではないハードウェアの癖に完全に関連しています。
プロフェッショナルなソフトウェアQA iとして、バグのないソフトウェアは存在しないと言うことができます。できることは、あるコードでやりたいことがバグを引き起こさないことを証明することです。ゼロバグ（非自明なプロジェクト）は、多くの理由で哲学的に不可能です。最も強力なことは、時間と空間内で完全性が不可能であるということです。もう1つの理由は、バグと機能の違いが見る人の目にあることです。バグと呼ぶものは開発者にとって機能であり、その逆も同様です。
これは、ubuntuディストリビューションが低品質であるとは限らないということではなく、ほとんどの商用OSが夢見ることのできる方法で、新機能と安定性の妥協点に現実的に近づいています。 rinzwindが投稿したグラフは、これらすべての主要な課題にもかかわらず、報告されたバグの大部分が処理され、通常は解決されるという点で印象的です。
報告されたバグの数は、以下に基づいています：
- コードの行数が多いほど、バグが発生する可能性が高くなります。 Ubuntuは、15万行（バージョン1）から1700万行（バージョン4.5.4）に成長したLinuxカーネルに基づいています。
- ユーザーの増加=潜在的なハードウェア/ソフトウェアの組み合わせが増え、バグが発生する
- より多くのユーザー=バグを報告する可能性が高くなります。バグが20％しか報告されておらず、5人のユーザーがバグに遭遇した場合、バグが報告されないことがあります。 50人のユーザーが（ユーザーベースが大きいために）遭遇した場合、報告されます。
- 新しいハードウェア=さらなるバグ。 Intel Bay Trailプロセッサ、nVidiaカード、Radeonカードにはあらゆる種類のバグがあります。これは、4k TV、USB 3.1、および今後の新しいハードウェア開発でのみ増加します。
- ハードウェアが増えると、競合が発生する可能性が高くなります。新しいデバイスごとに、独自のデバイスドライバー/カーネルモジュールを使用できます。より多くのモジュール= 2つの互いに衝突してバグを作成する可能性が高くなります。
- ソフトウェアが増えると、競合の可能性が高まります。ユーザーベースが拡大するにつれて、ユーザー向けに開発されるソフトウェアの量も増えます。 Apache Open OfficeはLibre Open Officeと競合する可能性があり、ストレージスペースが低価格で非常に豊富であるため、両方をインストールすることを選択する場合があります。ファンの速度を制御するために現在5つのプログラムが使用可能であり、ユーザーが複数のプログラムをインストールし、互いに競合してシステムのマイクロフリーズが10秒ごとに発生する場合があります。
バグの数が増加するにつれて、バグを修正するユーザーの数およびソリューション/回答を他のユーザーと共有するユーザーの数が増えることに注意してください。
また、場合によってはバグの数は増えませんでしたが、バグに遭遇する人の数は増えました。また、前述のように、バグを報告する人の数が増えています。