Ubuntu Technical Board member Scott James Remnant has outlined a theoretical proposal for transitioning the popular Linux distribution to a rolling release model in which new stable versions would be issued every month. He has published his thoughts on the matter in a blog entry to encourage discussion.
Ubuntu currently adheres to a time-based release model with a six-month development cycle. A new version is released in April and October of every year. Ubuntu releases have an 18-month support lifespan, except for the biennial "long-term support" (LTS) releases which are updated on the desktop for three years and on the server for five years.
The time-based release model was adopted early in Ubuntu's history in order to provide predictability for users and OEMs. It was also partly a response to the release lag that has historically plagued the Debian project. Although tight conformance with a well-defined schedule has its advantages, it also has some significant downsides.
Ubuntu's uncompromising commitment to releasing on time and the pressure to deliver all of the planned features in each release have created a mentality where virtually nothing is treated as a blocker. When technical issues come up late in the development cycle, they are sometimes ignored and addressed with point updates after the release.
Another problem with Ubuntu's release management strategy is that incomplete software tends to get shoehorned into LTS releases in order to avoid having to provide long-term support for older and more stable software that is scheduled for deprecation. One of the most illustrative examples is the 8.04 LTS release, which included a marginally-functional version of PulseAudio and a Firefox beta.
As I wrote in 2008 when I highlighted the problems with Ubuntu founder Mark Shuttleworth's synchronized release cycle plan, an undisciplined time-based release model can damage user confidence by turning releases into an arbitrary line in the chronological sand.
Remnant addresses some similar issues in his blog entry. He points out that Ubuntu's culture of targeting individual features to specific releases works against the best practices of successful time-based release management. The problem is exacerbated, he explains, by Canonical's tendency to tie employee pay and bonuses to whether they deliver assigned functionality in time for feature freeze.
"What happens if you're replacing something that works with something completely new? Can't you just target a later release, and work continually until the feature freeze of that release?" he wrote. "It turns out that you can't. There is an incredible emphasis on the Ubuntu planning process of targeting features for particular releases. This is the exact thing you’re not supposed to do with a time-based release schedule."
The consequence is the broken feature treadmill: stable functionality gets removed and replaced with half-finished components that are expected to see completion in the next release. This is especially problematic because it creates a negative perception of major new features that are very promising, but get thrust upon users before they are ready. This phenomenon can worsen the resistance to change among the general user population. Users will start with a skeptical view of any major new feature because they have learned to expect the replacement of working parts with stuff that's half-baked.
The problem is real, but there aren't any easy or obvious solutions. Maintaining the advantageous predictability of the release schedule while delivering stability and competitive feature improvements poses a difficult balancing act. Remnant's proposal suggests that transitioning to a monthly release process could ameliorate some of the problems with the six-month cycle.
The model described by his proposal is similar to that used by Chrome and Firefox. There would be separate alpha, beta, and release channels provided through the distribution's package management system. The alpha channel would be for developers, the beta channel would be for user testing, and the release channel would be the stable distribution.
All new changes will have to undergo code review and automated testing before being rolled out in the alpha channel. Improvements will then trickle down through the beta and release channels as they mature. The packages that are ready for the release channel would be rolled in together once a month.
The testing requirements would set a high enough barrier for entry to the alpha channel to ensure that an alpha environment is always basically usable. Active development will be conducted outside of those channels—developers can use personal package archives (PPA) to deploy to testers features that are under heavy development and aren't ready for the alpha channel.
Remnant used to work at Canonical as Ubuntu's development manager, but left earlier this year to join Google. His background gives him a very deep perspective into Ubuntu's development processes. As such, he is able to provide a relatively detailed explanation of the underlying mechanics he envisions for a monthly Ubuntu release process.
An important part of Remnant's proposal is that the LTS releases would still continue on the current two-year schedule. The availability of the LTS releases will ensure that there is still a stable target for maintainable enterprise deployment, certification of commercial software stacks, and OEM adoption.
The proposal offers a unique approach to addressing the problems with the six-month cycle, but it doesn't seem like a good fit for Ubuntu's broader goals and target audience. It poses a lot of serious challenges—especially for third-party software developers. The whole point of a Linux distribution is to have a consistent set of known-good components that are tested extensively together. A rolling release distribution like Arch or Gentoo is cool for a certain class of technical enthusiast who wants to run along the bleeding edge, but it's broken by design from the quality assurance standpoint.
When you have a complex dependency chain in which some components are moving forward faster than others, some pieces are inevitably going to break. Even if Canonical and the core Ubuntu development community do the work to ensure that the contents of the main repository are still functioning properly together from one month to the next, it may not be possible for the massive community-maintained Universe repository to keep up. When you have six months to get everything into alignment, you have a lot less potential for breakage.
Another issue with the monthly Ubuntu release proposal is that you get a less consistent base with a month-to-month version spread between users. This makes it really difficult for software outside of the ecosystem to remain compatible. If there are users running three or four different stable monthly releases (plus alpha and beta channels), will third-party developers have to test and deliver separate sets of packages in their PPAs for each version?
I think that transitioning to a rolling release model would force a lot of major third-party application developers to limit their support to the LTS releases. Independent application developers would take a less active role in packaging and testing their software for Ubuntu, leaving that as an exercise for the distro community.
To put the issue into perspective, consider the problems that have emerged in the Firefox add-on community following Mozilla's adoption of shorter development cycles. The difficulty of tracking a moving target has led to a situation where a lot of add-ons just aren't updated. Imagine those same problems at the scale of the entire Ubuntu application ecosystem. It's not really a pretty picture.
There may be solutions to address some of these issues with the rolling release model and make it more practical for Ubuntu, but it seems like an even bigger challenge than the current quality problems. It could be useful to have a rolling release track offered alongside the stable time-based releases for users who value the benefits of a more Arch-like experience, but it's just not a good release model for regular end users.
Given the fact that a basic lack of discipline is a major factor in the problems Ubuntu faces with the six-month cycle, it's debatable whether moving to a monthly cycle would even truly address the deficiencies of Ubuntu's current release management strategy. There may be more effective ways to address the issue of features landing prematurely without having to resort to such a radical overhaul of the development process. Remnant's proposal is intriguing, but it seems unlikely that it will gain enough traction among Ubuntu developers to see adoption.
Listing image by Flickr: God DRAGON
reader comments
79