This post has a background bug that was introduced just over a week ago, ONE THE DAY BEFORE ITS RELEASE. The bug is being able to bypass the lock screen by just holding down your <Enter> key, letting Unity crash, then restarting without locking the desktop. That's a pretty big bug. What's interesting about this bug though, isn't the bug itself, but a bigger problem withing the Ubuntu and Canonical development teams. That is, that the release date is more important than the quality of the release.
I blogged about this six years ago when I was an Ubuntu Member, and my blog was on the Ubuntu Planet (it's weird to think that I've had this blog now for almost 10 years. Heh). I mentioned that I was moving my server away from Ubuntu 8.04 LTS to Debian 5.0. My rationale was clear: Debian is much more interested in making sure that "Debian stable" is actually rock-solid stable. If that means that it takes three years before the next release is ready, then so be it. Stable is stable. Ubuntu could learn a lot from this.
So, what does Debian do so differently than Ubuntu, and how can Ubuntu learn from this? Let's take a look at how packages transition from the "unstable" release to the "testing" release in Debian, and how "testing" becomes "stable".
- After the package has been in unstable for a given length of time, it can qualify for migration to testing. This depends on each package, and the urgency of the migration.
- The package can only enter testing if no new release critical bugs exist. This means, that the package must have fewer release critical bugs than the current package in testing.
- All dependencies needed for the package must be satisfiable in the current testing repository. If not, those packages must be brought in at the time the current package is, and they must meet the same criteria related to time in unstable and the number of release critical bugs.
- The package migrating to testing must not break any other packages currently in testing.
- It must be compiled for all release architectures it claims to support, and all architecture specific packages must be brought in as well, meeting the same criteria as mentioned.
Point #1 gives the package enough time for people in the community to report any immediate or obvious bugs. If nothing is reported, then it's possible that the new package version is an improvement over what is currently in testing, and as such, the package becomes a migration candidate. This doesn't mean the package migrates. Instead, it must now be evaluated in terms of quality, and this is handled by evaluating its release bug count.
Point #2 is all about release bug count. If the release bug count is equal to or higher than what is currently in testing, then the package is not an improvement, and is not going to get migrated into testing. If the release bug count is fewer than what is in testing, then migrating the package from unstable into testing improves the quality of the testing release.
Point #3 makes sure that dependencies are met with the package migration from unstable into testing. All dependencies must meet the criteria of points #1 and #2 to be candidates for migration.
Point #4 ensures that current packages in testing do not break when the new package is migrated. Not only the current package dependencies, but also other packages that might interact with it.
Point #5 brings in CPU architecture support. Debian is a universal operating system, handling many different CPU architectures. Not all CPU architectures have the same packages. But, if the package was previously compiled for a certain architecture, then it must continue to be compiled for that architecture. IE- no orphaned packages. Points 1-4 must be met for every architecture it claims to support.
If points 1-5 are successfully met, then the package can be migrated from unstable into testing, improving the quality of the testing release. You can track the release critical bug status in the current testing release at https://bugs.debian.org/release-critical/. As of this writing, there are currently 384 release critical bugs that will prevent testing from becoming the new stable release (the green line in this graph). When the release critical bugs near zero, then and only then is a new release of Debian ready for general consumption.
I know I've highlighted how the Debian release works, but how about other operating system vendors?
- Windows releases when it's ready.
- Mac OS X releases when it's ready.
- RHEL releases when it's ready.
- CentOS releases when it's ready (following RHEL).
- SLES releases when it's ready.
- Slackware releases when it's ready.
- FreeBSD releases when it's ready.
- NetBSD releases when it's ready.
- Solaris releases when it's ready.
In fact, of all of the operating system vendors I can find, only Ubuntu and their derivatives (Linux Mint, *buntu, etc.) and OpenBSD stick to a rigid schedule of releasing every six months. Other than Ubuntu, none of of those operating system vendors see large scale mission critical server deployment. Debian does. RHEL and CentOS do. Windows certainly does. Even FreeBSD sees enormous success in the datacenter. A large part of that, I would bet, is the fact that stable means stable. "Mission critical" just is not synonymous with Ubuntu servers.
According to https://launchpad.net/ubuntu/trusty/+bugs, as of the time of this writing, almost 2 weeks after 14.04 LTS released, there are:
- 88 New bugs
- 301 Open bugs
- 19 In-progress bugs
- 10 Critical bugs
- 78 High importance bugs
- 4 Incomplete bugs (can expire)
Here's a beauty, reported in December 2013, against 13.10: Reinstallation wipes out all/other partitions. People are losing their Windows partitions. That's lost data. This isn't a laughing matter. And 14.04 STILL released? No way in hell would any other vendor release their OS with a bug of that size. Let's hope it's fixed before 14.10 releases.
Even though I'm critical of Ubuntu's spyware on the desktop, and their CLA and other business practices and development, I would love to see them do things right. Unfortunately, releasing every 6 months, regardless, is not doing things right. It doesn't put a lot of trust into system administrators and into executives to run their production environment.
{ 2 } Comments