Distributions

Always-releasable Debian

Debian 7.0 ("Wheezy") was released on May 5, at which point preparations started for 8.0 ("Jessie"). But the freeze period in the Wheezy development cycle (during which only release-critical (RC) bugs are meant to be fixed) took longer than average: ten months rather than the usually-expected six. That led to some understandable self-reflection about the development and release process, including a proposal from Lars Wirzenius and Russ Allbery to adopt several changes meant to keep the testing branch in an always-releasable state.

A modest proposal

The benefits of transitioning to a shorter release cycle would affect many groups: users would get updated packages more quickly, the release team would feel less swamped by the stack of RC bugs, and developers would feel less frustrated about the process. The crux of the proposal is to keep the packages in testing as free of RC bugs as possible, akin to maintaining a releasable trunk branch in an individual software project. Wirzenius and Allbery suggest four changes to bring this about:

• Making an attitude shift, so that maintainers of individual packages view making Debian releases as part of their job, not just the job of the release team.
• Keeping RC bugs out of testing.
• Using automatic testing and/or continuous integration to catch problems earlier.
• Limiting the number of packages treated as "core" packages that can hold up a release.

The attitude shift is a nebulous task, naturally; few on the debian-devel mailing list actually think of releases as the concern of the release team alone. But the gist is that individual package maintainers may need to change the way they handle certain changes, such as transitioning a fundamental package like glibc to a new version, which can have far-reaching effects on other packages.

Keeping RC bugs out of testing is a goal that could involve several possible steps. Wirzenius and Allbery note that in the current release model, "right after the release we open the floodgates, and large number of new packages and versions enter testing. The bug count sky-rockets, but we don't care a lot about that until the next freeze gets closer." They suggest removing RC-buggy packages as soon as possible, including dependent packages, devoting more developer-power to fixing RC bugs in those core packages that cannot be removed (e.g., GCC), and having bug-fix-only "mini-freezes" if the RC count rises above a particular threshold.

On the automatic testing front, they suggest setting up a suite of "reference installations" aimed at common Debian deployment scenarios (mail server, LAMP server, desktop machine, etc.) to determine which packages ought to be considered "core" and which ought to be considered optional. The project could then use these reference systems as targets for continuous integration and testing. They note that Debian already has several automatic testing tools (such as lintian, piuparts, adequate, and autopkgtest), but they do not currently guide the progress of a package into testing:

Holger Levsen has already been working on a continuous integration system for Debian at jenkins.debian.net, Wirzenius and Allbery observe, and there quite a few useful test already available in piuparts—it will just take some additional effort to build them into a reliable automatic testing framework.

The great debate

On the whole, most of the people on debian-devel seem supportive of the goal—which is to say they agree that the lengthy Wheezy freeze was less than ideal and that the process can be improved. Almost everyone who replied to Wirzenius and Allbery's email is in favor of increased automated testing and continuous integration. There is less unanimity on the question of limiting the number of packages that constitute the essential core of a release, however, and about how attitude changes may or may not affect the process.

For example, Paul Wise thought that the point about the attitude shift "essentially comes down to 'people don't do enough work and we want them to do more'", which does not account for several factors that impact developers' individual workloads, including available time, knowledge, confidence, and motivation level. In response, Neil Williams replied that the real intent was to solve a somewhat different problem: "people are not getting the work done, let's break down the problems and make working on them easier or the solutions more obvious".

On the other hand, Michael Gilbert felt that there was not a fundamental problem with the methodology used in the Wheezy release cycle, and that it in fact reflected a better bug-squashing effort:

Allbery replied that the project says almost the same thing after every release, and that it needs to "be sure that we're not just trying the same thing over and over again and expecting different results." Ultimately, however, Gilbert's suggestion for handling the increased RC bug count was more automated testing, so regardless of whether the increased RC bug count is intrinsically good or intrinsically bad, handling it better involves the same solution.

Where there is less consensus at present is on the subject of limiting the number of packages regarded as "core" components of a release—and pulling non-core components that introduce RC bugs (although the offending package would be re-admitted to testing once its RC bugs had been fixed). In their original proposal, Wirzenius and Allbery noted that making a core/non-core distinction could have negative side-effects, such as causing buggy packages to miss the release. Perhaps Debian could introduce new packages in subsequent point releases, they said—an idea which always-releasable testing makes possible.

But several felt that the existing process already sifts packages by importance, at least as "importance" is defined in practice. Vincent Bernat said: "If a package is important, an RC bug will get noticed and someone will step to fix the RC bug or ask for a delay. This avoids unnecessary debate on what is important and what is not and people fighting to get their packages in the right list." Helmut Grohne worried that frequently adding and removing packages from testing would destabilize it as much or more than the RC bugs introduced by those packages. Perhaps, he said, simply making the removal notification (which precedes any actual package removal) higher-profile would goad the developer into fixing the bug faster.

It is also not clear who would make the core/non-core determination; such a call could easily be a source of controversy. Wirzenius and Allbery assured everyone in their proposal that the non-core designation is not a black mark, but considering the practical effect it has—namely, that the release will not wait for the package to get fixed—it has the potential to spawn disagreement. Not everyone was sold on the "reference installations" idea, either; Thomas Goirand said that the suggested installation types (e.g., web server, mail server) denote packages that are pretty stable already, and not the sources of problems in Wheezy. "If you want to find out which tests would help, you would have to conduct a better analysis of the problems we had during the freeze, IMO."

Naturally, there are other "postmortem" discussions analyzing the Wheezy release cycle and how it could be improved. Ian Jackson, for example, started a thread of his own around the same time, analyzing (among other things) which RC bugs had proven "hard" to fix and what could be done to alleviate the time required. The always-releasable testing concept is being tracked on the Debian wiki; clearly the goal it sets out is grander in scope than a mere reduction in the length of the pre-release freeze. But regardless of where it eventually heads, it has already raised some ideas that seem likely to get more attention before the release of Jessie. Debian will likely remain a "release when ready" distribution, not following the time-based process popular among other distributions, but automated testing and continuous integration could go a long way to making that "ready" state a more frequent occurrence.

Comments (none posted)

Distribution quotes of the week

-- Ben Hutchings (Thanks to Thorsten Glaser)

-- Geert Uytterhoeven (Thanks to Mattias Mattsson)

-- Steve Kemp

Comments (none posted)

Three Ubuntu releases reach end of life

Three releases of Ubuntu reached their end of life on May 9, 2013, which means they will no longer receive updates of any kind. Users of Ubuntu 8.04 LTS ("Hardy Heron"), Ubuntu 10.04 LTS Desktop ("Lucid Lynx"), and Ubuntu 11.10 ("Oneiric Ocelot") should upgrade.

Comments (9 posted)

A proposal for an always-releasable Debian

Lars Wirzenius and Russ Allbery have posted an essay calling for changes in how the Debian release cycle works; it is mostly aimed at reducing the length of freezes to something close to zero. "The fundamental change is to start keeping our "testing" branch as close to releasable as possible, at all times. For individual projects, this corresponds to keeping the master or trunk branch in version control ready to be released. Practitioners of agile development models, for example, do this quite successfully, by applying continuous integration, automatic testing, and by having a development culture that if there's a severe bug in master, fixing that gets highest priority."

Full Story (comments: 49)

Fedora account system (FAS) potential information disclosure

Fedora project leader Robyn Bergeron has announced an information disclosure bug in the Fedora account system that may have exposed certain types of information (hashed passwords, security questions and encrypted answers, etc.) from unapproved members. It has been present since 2008, but could only be exploited by authenticated users, furthermore:

Full Story (comments: 19)

Fedora Elections

The Fedora election season has started. Seats are open on the Fedora Board, Fedora Engineering Steering Committee (FESCo), and Fedora Ambassadors Steering Committee (FAmSCo). The Fedora 20 Naming Election is also underway.

Full Story (comments: none)

Distribution newsletters

• Debian Project News (May 13)
• DistroWatch Weekly, Issue 507 (May 13)
• Maemo Weekly News (May 13)
• Ubuntu Weekly Newsletter, Issue 316 (May 13)

Comments (none posted)

Raspberry Pi operating systems: 5 reviewed and rated (Techradar)

Those looking for alternative distributions (or even operating systems) for their Raspberry Pi may want to take a peek at Techradar's review of five choices for the diminutive ARM-based computer. The article looks at Raspbian, Risc OS, Plan 9, Android, and Arch; it evaluates and rates each one on a variety of criteria:

Comments (4 posted)

Cinnarch successor Antergos arrives (The H)

The H covers Antergos, the successor to Cinnarch. "In just a month since the last release of Cinnarch, during which the developers decided to drop Cinnamon for GNOME, they have produced a new release that brings a distribution that is more desktop agnostic than ever before. Cinnarch development was halted after the developers were finding it harder to synchronise the Cinnamon development with the rolling nature of Arch Linux."

Comments (none posted)

How Mighty Mint became one of the most popular Linux distros (Techradar)

Techradar takes a look at Linux Mint. "The surprising thing is that Mint was originally just a sideshow to some reviews its creator had written online. Clem Lefebvre explains: "I was writing for LinuxForums.org at the time, and eventually decided to try and host my own website, so I created LinuxMint.com. Version 1.0 (of the distribution) was a quick experiment to see how some of the ideas I wrote about in my reviews could be implemented. I was surprised to see people were more interested in it than in my articles.""

Comments (1 posted)