Comment 40 for bug 1813441

You're failing to understand the concept of "show-stopper" bug, also known as "ship-stopper".
The severity of such a bug is so big, that the whole release a product must be postponed, until the bug is fixed. Bugs of this kind are ones that substantially compromise the usability of a product. For example, a bug in a browser's rendering engine that doesn't allow a single major website (social networks, search engines etc.) to render correctly. Millions of people won't use that browser because of that. Another example? A GCC bug that doesn't allow the Linux kernel to compile or, even worse, compiles but generates incorrect instructions and the kernel doesn't boot. Even if that C compiler had a TON of new and cool features and it was 200% faster than its predecessor, would you allow it to be released knowing the you cannot compile Linux? I wouldn't, never.

Most of the time, we make trade-offs, both in software development and in release management as well. For example? We've fixed 100 bugs at the price of introducing 5 new ones. That's fine, generally. BUT, some bugs are critical and cannot even be put in the equation. I don't need the whole "decision tree" for that. Such bugs, have priority above everything else combined. The 10,000 new features of KDE 4 were worthless, compared to the fact that it was not stable and crashed the whole time. I wanted so much to use it at the time, because it was so cool and visually pleasing. But, at the end I gave up because of its instability and switched to GNOME.
A car is *worthless* if its breaking system doesn't work. A compromise can be made when the breaking system is relatively worse than the one in the previous model, but it's still working, it's still doing an acceptable job.

So, how to decide which bugs are show-stoppers? Well, there are user experience people, product managers, VPs etc, but ultimately, such a decision is SUBJECTIVE. I have no "mathematical proof" that this was a show-stopper bug, neither do you that this wasn't. I expressed my opinion, trying to make the Ubuntu leadership to reconsider such decision making. Maybe I failed, maybe I didn't. But if nobody makes criticism, it's almost impossible for the leadership to get a feedback and improve its decision-making. At the end, given users' feedback, I hope Ubuntu leaders will ask themselves: "was that the right call to make?". Maybe, just maybe, the next time they'll be more conservative when releasing an LTS.