How the Debian Release Team Finalizes Stable Releases

This article examines the critical responsibilities of the Debian Release Team during the final phases of launching a new stable distribution. It outlines how the team orchestrates the development freeze, manages release-critical bugs, qualifies supported architectures, and collaborates with specialized sub-teams to guarantee that each Debian stable release meets the operating system's rigorous standards for stability, security, and software freedom.

Managing the Freeze Cycle

The primary mechanism the Debian Release Team uses to stabilize the distribution is the freeze cycle. In the standard development cycle, packages continuously migrate from the "unstable" repository (Sid) to the "testing" repository. To finalize a release, the Release Team introduces progressive freeze milestones:

  • Transition and Toolchain Freeze: Halts major library transitions and compiler updates to prevent system-wide ABI breakages.
  • Soft Freeze: Limits package migrations strictly to bug fixes; new source packages and new binary packages are blocked from entering testing.
  • Hard Freeze: Requires explicit manual review and approval ("unblocks") from the Release Team for any package update entering testing.
  • Full Freeze: Halts all automatic migrations entirely. Only emergency fixes for critical issues are accepted via direct intervention.

By enforcing these stages, the team forces the developer community to focus exclusively on stabilization rather than introducing new features.

Release-Critical (RC) Bug Triage

The Release Team directly monitors the list of Release-Critical (RC) bugs, which are severe defects that break Debian Policy, violate software license guidelines, or cause severe data loss or system crashes.

To bring the RC bug count to zero, the Release Team:

  • Reviews requests from package maintainers to unblock updated packages containing fixes.
  • Sets deadlines for stubborn issues and issues removals: if a non-essential package with an RC bug is not fixed in time, the team removes it from the testing distribution entirely so it does not hold up the release.
  • Coordinates non-maintainer uploads (NMUs) to apply necessary patches when original package maintainers are unavailable.

Architecture Qualification

Debian supports numerous hardware architectures, but not all make it into the official stable release. The Release Team sets objective criteria for an architecture to be designated an official release architecture. Criteria include build-daemon health, reliable toolchain operation, developer interest, and an acceptable success rate for compiling the entire package archive. Architectures that fail to maintain stability during the freeze are dropped from the candidate list for that release cycle.

Cross-Team Coordination

Finalizing Debian Stable requires tight coordination across multiple autonomous groups within the project. The Release Team synchronizes efforts with:

  • The Debian Installer Team: Ensures the core installation system supports the target kernels, partition layouts, and qualified architectures.
  • The Security Team: Prepares security infrastructure and tracks unresolved vulnerabilities to ensure the new release is supported by security updates from day one.
  • The Release Notes and Documentation Team: Verifies that upgrade paths from the previous stable version are thoroughly documented and tested.
  • The CD and Cloud Teams: Validates official installation media images and live/cloud machine images.

Orchestrating the Final Release

Once all RC bugs are resolved and consensus is reached among the core teams, the Release Team triggers the physical release. This multi-hour procedure involves stopping incoming package updates, changing the archive aliases (pointing the "stable" alias to the new release codename and assigning the previous stable release to "oldstable"), signing off on final installation media generation, and coordinating with the Press Team for the public launch announcement.