de Finibus Bonorum et Malorum



Reclamações recentes

Understanding Debian Releases

The cycle of Debian‘s releases is not an usual one.

Most Linux distributions follow two paths. Some of them follow a strict periodicity, and we see a new version being released according to that periodicity. For example, Ubuntu releases a new version every six months. Other distributions, however, choose their release dates according to other criteria, likely based on release dates of important software, like the kernel, X.Org, Kde and GNOME, for example. One example of such behavior is Red Hat.

Debian, however, is very particular in this matter (as in most others). But, before I get into that, it helps to understand a little more about the versions of Debian.

What are Debian Releases

At any time, there are three releases of Debian:

  • Unstable is the entryway of software into Debian. Any new versions of software or new programs are first included here. This means that Sid (as it’s called) is usually up-to-date with all the software that it offers. It also means that it may contain many bugs and other problems, so usually it’s recommended for Debian maintainers and developers.
  • Testing is slightly behind Sid. Its packages usually arrive after spending a certain number of days in unstable. The number of days depends on the type of package, but overall this means that software that makes it into testing has been minimally tested and may contain bugfixes. Everything that comes into Debian usually ends up here, where is is thoroughly tested – hence its name.
  • Stable is the official release. It contains extensively tested software, and receives no major upgrades. Most of the time only security updates are made to this software, and Debian has a team devoted only to that. So, if security and/or stability is paramount, stable is the recommended release.

Debian release code names are taken from Pixar’s Toy Story movies. Both testing and stable receive new code names when a release happens, but unstable is always called Sid (the kid next door who broke all the toys).

Debian maintainers and developers use unstable to build new packages, then upload it into the repositories where it goes into Sid. Depending on how it performs over time, the package is then “promoted” into testing, where it can reach a higher number of people. It does not move forward into stable, though; that’s an entirely different process.

The Freeze process

During the time of the release cycle, testing accumulates the most recent versions of minimally tested software that comes through unstable, until the Release Team (a group of Debian Developers responsible for making new releases, among other things) declares a Freeze on testing.

The Freeze process is what prepares testing to be release as the new stable. Over its three phases, migration of packages from unstable to testing becomes increasingly more specific. That does not mean necessarily that testing changes little, but that the nature of changes becomes more and more specific.

Transition freeze

The transition is the first phase of the freeze. During this time the rules are more permissive than later on, but no major transitions are allowed; packages no longer are upgraded to another major version, and big changes in programs are no longer accepted, as well as library changes. Apart from that, migration rules remain largely unchanged.

As an example, the Linux Kernel 5.0 – which was released on March 4 – would not have made it into Buster unless it was released before January 12, which was when the Buster transition freeze began.

Soft freeze

During the soft freeze, things begin to get more difficult. Packages can only enter testing after a 10 day delay in unstable, and usually only small fixes are allowed. No new source packages are allowed, which means that no new code comes in. Overall migration begins to go through manual review for some packages.

As an example, GNOME 3.32 – which came out on March 13 – would not have made it even if it had been released days earlier, since moving from 3.30 to 3.32 would have meant a bigger change than is allowed during this phase (DISCLAIMER: this is speculation on my part).

Full freeze

This is the final phase, and it is mainly concerned with squashing all bugs that are considered Release Critical: any bugs that are classified as serious, grave or critical. For details on bug severities, check this.

At this point, the only changes to packages that are allowed are those that fix RC bugs, with fixes to important bugs being optional. Besides that, packages have to pass successfully through Autopkgtests, which means that Debian’s build system are able to automatically build the package for all architectures without errors. Finally, packages are only allowed into testing after being manually reviewed – no more automatic checks.

Upon reaching the full freeze, testing remains there as long as needed. Optimally, a new Stable is only released when the number of RC bugs becomes zero. However, things are never that simple; some bugs are more resilient than others, and a fix might be not possible. At some point when the number of RC bugs is low, developers will assign one of two tags to them: buster-can-defer or buster-will-remove. The first one means that the fix will be postponed to a point release or to the next stable. The other one means that that package cannot live in stable with that bug, so it gets removed from the release (it might get back if said bug gets fixed).

The Release

When this point is reached, a deadline is established and the Release Team plans the release. For example, Stretch was planned for June 17th, 2017. After that, final bug fixes can come in, respecting the deadline.

Archives are signed, final fixes are made, the last bugs are either deferred or packages are removed, and the release is made. In the archives, links like “stable”, “oldstable” and “testing” are remade to point to the proper locations, and a new folder with the code name of the new testing release is created, with a copy of the freshly-made release, and the process begins anew.

Hoorah! A new Debian is born!

Final remarks

This post contains mostly information I gleaned from Debian’s own documentation. This includes, but is not limited to, the freeze policy, the wiki pages on Testing and Releases, and the archives of mailing lists related to the subject (such as debian-announce, debian-devel-announce and debian-release).

Nevertheless, it also involved some guesswork, since it’s not clear how or when some things are decided. Those include, for example, what triggers the freeze, or how the Release Team decides it’s time to call it on those last few bugs (something I began to call “release or bust”). I do not claim to know Debian’s release cycle intimately or in details; I’m just a Debian user/aficionado, so consider this an outside look.

At the time of writing, Buster has been in Freeze for 117 days, and it has been 1 year 11 months since Stretch was released. The “average” time between releases is about two years, so we should be close to a new release. This proximity prompted my initiative of creating a way of tracking it, inaccurate as it may be; I’ll expand on that on my next post.


Comentários

  1. […] my last post I went over how Debian’s release cycle works. In fact, all we can hope for is a planned release date, but even that depends on how things […]

  2. […] my last post I went over how Debian’s release cycle works. In fact, all we can hope for is a planned release date, but even that depends on how things […]

  3. […] A little more than a year ago, I published a series of posts talking about Debian’s release cycle, which was followed by an exercise in how a small python script could be used to track the number of bugs related to it. […]

Leave a Reply

Your email address will not be published. Required fields are marked *