Rethinking Ubuntu's Update Policy…Or Not
One of the timeless challenges of open-source development is keeping software as up-to-date as possible while also maximizing stability. With this difficulty in mind, Ubuntu’s developers recently discussed the operating system’s policy on updates. Here’s the story, with some thoughts.
Sebastien Bacher pointed last Wednesday to the dilemma of delivering Gnome updates to end-users in the middle of Ubuntu release cycles. While Ubuntu’s general policy is to save non-critical software updates for the next version of the operating system, this practice is bad for users affected by bugs in existing packages that are serious for them, but not deemed worthy of immediate fixing. The conservative update policy also means Ubuntu users have to wait longer for new application features to become available, and it’s somewhat of a slight to upstream developers, whose hard work doesn’t reach the masses as fast as they might like.
Stability, stability, stability
Bacher asked for feedback on how these problems might be mitigated. While some developers pushed for more aggressive update policies that would lower the bar for deciding which bugs are critical enough to be patched in the middle of a release cycle, a majority argued for erring on the side of stability when delivering patches to users. As release manager Martin Pitt wrote:
For stable updates we have several conflicting goals, in the
1. keep it running
We must avoid introducing regressions through updates at all costs.
2. keep it safe
We obviously need to fix critical issues like security
vulnerabilities and data loss bugs.
3. make it better
Fix major regressions from earlier releases and bugs which impede a lot of users.
Not all bugs are created equal
Rather than pushing more aggressive updates, Pitt argued for streamlining the review process of existing bugs so that approved patches reach users faster. Under current policy, all proposed updates are subject to the same quality-assurance process, regardless of their complexity or importance to the system. This means trivial changes often take longer than they should to reach end users. By factoring the seriousness of a proposed update into the procedure for releasing fixes, developers could cut some of the overhead from Ubuntu updates.
Unfortunately, no consensus seems to have been reached regarding how the review process could actually be streamlined.
One of the factors that drove me to Ubuntu from Fedora a few years ago was the latter’s comparatively aggressive policy on updates. More than once, I found that updating my system resulted in broken wireless or X. This isn’t to say such problems don’t occur in Ubuntu–they occassionally do, if posts on the Ubuntu forums are any indicator–and maybe I was just a particularly unlucky Fedora user. But I’ve yet to suffer a show-stopping regression when installing updates in Ubuntu.
I’m therefore pleased to see the Ubuntu developers continuing to promote stability before all else when it comes to updates. Sure, it’s annoying to have to wait for the next Ubuntu release in order to upgrade to the latest applications, but that’s preferable to having the operating system break frequently due to poorly tested patches being sent downstream. And the type of users who care about having the latest version of OpenOffice or Gnome tend to know how to get it on their own, without waiting for Ubuntu updates.
Let’s hope Ubuntu’s leaders continue to think pragmatically and keep stability in mind. If they do, they just might distinguish themselves long enough from the out-of-touch geeks who dominate open-source development to bring Ubuntu to the masses.