How Grave and Serious Bugs Block Debian Testing

In the Debian operating system, bugs classified as "grave" or "serious" are designated as Release-Critical (RC) bugs. When filed against a package version residing in the unstable distribution (Sid), these bugs directly halt the package's automated migration into the testing branch (Testing). Because the testing distribution serves as the staging ground for the next stable Debian release, the migration automation engine strictly prevents any package harboring unresolved RC bugs from advancing.

Release-Critical Bug Classifications

Debian's Bug Tracking System (BTS) utilizes severity levels to categorize issues. The designations "grave" and "serious," alongside "critical," represent Release-Critical severity:

  • Grave: Indicates that the bug makes the package largely or completely unusable, causes serious data loss, or introduces a major security vulnerability affecting users of the package.
  • Serious: Indicates a severe violation of the Debian Policy Manual or makes the package entirely unbuildable on supported architectures.

Any issue meeting either of these criteria signals that the software is unfit for release in a stable operating environment.

The Role of the Testing Migration Tool (Britney)

The transition of packages from Debian Unstable to Testing is governed by an automated script named Britney. Under normal conditions, a package enters Testing after meeting specific criteria, including an aging period (typically 2 to 10 days depending on upload urgency), passing all automated test suites (autopkgtest), and having all dependencies resolved.

Britney checks the BTS status for RC bugs before approving any transition:

  • Zero-Tolerance for New RC Bugs: If an upload in Unstable contains a bug marked grave or serious that is not present in the current Testing version, Britney immediately blocks the package.
  • Comparative RC Count: A package can only transition if it does not introduce new RC bugs into Testing. If the version in Unstable fixes an existing RC bug in Testing without introducing new ones, migration is permitted and actively prioritized.

Removal from Testing

The impact of grave or serious bugs extends beyond preventing entry. If an RC bug is discovered in a package that is already in Testing:

  1. Autoremoval Timer: The BTS flags the package for automatic removal from Testing.
  2. Grace Period: Maintainers are generally given a grace period (often 14 to 30 days, depending on whether the package is a key component) to upload a fix to Unstable and let it migrate.
  3. Cascading Removal: If the issue is not fixed within the allotted window, the package—along with any reverse dependencies that rely on it—is removed from Testing entirely.

Restoring Candidacy

To restore migration eligibility, the RC bug must be resolved. The maintainer must upload a fixed package to Unstable and close the bug via the Debian changelog, resolve it manually in the BTS, or legitimately downgrade the bug's severity if investigation proves it does not violate policy or break the software to an RC degree. Once the bug status updates in the BTS, the package automatically regains its candidacy for migration into Testing.