How Debian Manages Release-Critical Bugs

Debian relies on a strict definition of Release-Critical (RC) bugs and an automated, community-driven enforcement pipeline to maintain its reputation for system stability. By categorizing bugs according to severity and tracking them through the Debian Bug Tracking System (BTS), the project ensures that flawed software cannot migrate into testing or ship with a stable release. This article explores how Debian defines these critical flaws, how automated tools like migration scripts and autoremovals isolate them, and how the Release Team enforces remediation through freeze cycles, Bug Squashing Parties, and package removals.

Defining Release-Critical Bugs

In the Debian project, a bug is designated as Release-Critical if its severity prevents the package from being included in the next Debian stable release. Debian's Bug Tracking System (BTS) classifies bugs into several severity tiers, but only three qualify as RC by default:

  • Critical: Bugs that break unrelated software or the entire system, cause severe data loss, or introduce a major security vulnerability affecting the host.
  • Grave: Bugs that render the specific package unusable or mostly unusable, cause data loss for users of the package, or create a security hole in the package itself.
  • Serious: Bugs that represent a severe violation of the Debian Policy Manual or are deemed critical by the package maintainer or the Debian Release Team.

Additionally, the Release Team can manually apply special tags (such as bullseye-can-defer or distribution-specific release tags) to include or exclude specific bugs from blocking a release.

Tracking and Visibility

Every reported bug is indexed in the BTS, where it is version-tracked against specific Debian distributions: unstable (Sid), testing, and stable.

Because a bug might exist in unstable but not in testing, Debian tracks bug states per package version rather than per distribution. The Debian Release-Critical Bug graph and dedicated dashboard continuously monitor the overall count of unresolved RC bugs affecting the testing branch, providing maintainers with real-time tracking of issues blocking the next stable milestone.

Automated Remediation: Britney and Package Autoremoval

Debian automates much of its quality control through its package migration tool, nicknamed Britney.

  1. Migration Gating: When a developer uploads a package to unstable, Britney evaluates whether it is eligible to migrate to testing. If an RC bug is open against the version in unstable, Britney prevents the package from entering testing.
  2. Automated Removals: If an RC bug affects a package already present in testing, a countdown timer begins (typically 14 to 20 days). If the bug remains unfixed and no package in testing depends on it (no reverse-dependency blockers), Britney automatically removes the package from testing. This prevents individual maintainer inactivity from holding back the release cycle.

The Debian Freeze Process

As the development cycle nears completion, the Debian Release Team implements progressive "freeze" stages to stabilize the testing branch:

  • Transition Freeze: Maintainers are barred from initiating large library transitions that could destabilize groups of interconnected packages.
  • Soft Freeze: New source packages cannot enter testing. Britney's autoremovals continue, and packages can only update to fix bugs.
  • Hard Freeze: Maintainers must obtain explicit approval from the Release Team for any package update entering testing. Only fixes for RC bugs and documentation updates are accepted.
  • Full Freeze: No package migrations occur without manual intervention by the Release Team.

Manual Enforcement and Maintainer Intervention

When automation is not enough, Debian relies on maintainer policies and collective remediation:

  • Non-Maintainer Uploads (NMUs): If an RC bug is neglected by a package's primary maintainer, Debian policy allows other developers to fix the bug and upload a patched package via an NMU, often bypassing typical waiting delays during freeze periods.
  • Bug Squashing Parties (BSPs): Distributed, community-wide coding sessions are organized globally to triage, patch, and verify RC bugs in the final months of a release cycle.
  • Package Drops: If a package cannot be fixed before the target release date and is not an essential system component, the Release Team will manually drop it and its dependent packages from the release candidates.

A new Debian version is only released when the count of release-critical bugs affecting the testing distribution reaches zero, or when any remaining edge cases are explicitly waived by the Release Team.