Policies Overview

Debian’s release process follows a set of policies that help keep the distribution stable and releases on time. This chapter gives a short overview of the main rules.

Release-Critical (RC) Bugs

A release-critical (RC) bug is any bug with a severity of critical, grave, or serious. Any package with an RC bug won’t be included in the next stable release. If the bug isn’t fixed, the package is either removed from testing or it blocks the release until it’s fixed (Debian Handbook). You can see a current list of RC bugs on this page.

Transitions

A transition <https://release.debian.org/transitions/> is a planned update that requires many other packages to be rebuilt, like when a core library changes. Maintainers must get a transition slot from the Release Team before they upload the new version. Usual workflow is described in the Release Team transition guidelines. Once the transition freeze starts, no new transitions are allowed.

Architecture and Archive Criteria

Getting a new hardware architecture or operating system port into Debian’s official archive follows strict rules (Archive criteria).

Existing architectures

  • If an architecture is not part of two releases in a row, it is removed from the official archive.

  • To get it back in, the porters must prove it is viable and get explicit approval from the Release, Security, and Debian Admin teams.

New architectures

  • Must be built entirely from unmodified Debian sources (no outside patches).

  • A basic set of packages (build-essential, toolchain) must be ready, with at least one build daemon and one porter machine online.

  • At least two machines must be set up with the Debian System Administrators (one for building, one for porting).

  • The porter team must be made up of Debian Developers and provide signed initial builds.

Qualification questions

The Release and FTP teams will ask for detailed answers about:

  • Is the hardware available to the public?

  • Is there a developer and user community (at least 3 active porters, real users)?

  • Is the kernel and toolchain supported (with a stable ABI)?

  • What is the status of the buildd network and archive coverage?

  • Is there an installation procedure and documentation?

  • Is there example hardware developers can use for testing?

Operating system ports

(OSes like Hurd or kFreeBSD, which use a non-Linux kernel) must also answer questions about API compatibility, licensing, other existing distributions, and long-term sustainability. Porters should document their answers on the ArchiveQualification wiki.

The goal of these rules is to make sure every supported architecture or OS meets the same high standards as the existing Debian ports.

The Release and FTP teams regularly review the status of each architecture. You can see the current qualification status on this page.

Freeze Stages

The release process uses phased freezes to get testing ready for release. Each stage makes the rules for uploads stricter, from limiting big changes (soft freeze) to requiring manual approval for everything (full freeze). Details are covered in the dedicated Freeze chapter of this document and in official Release Team documentation.

Unblocks

During a freeze, most uploads need approval. Maintainers request an unblock by filing a bug against the release.debian.org pseudo-package. The request must explain why the change is needed and include a debdiff (Unblock requests). The Release Team usually only accepts small, targeted fixes for RC bugs or critical documentation updates.

Further Reading