5.5.1. Special case: uploads to the stable and oldstable distributions

Uploading to stable means that the package will be transferred to the proposed-updates-new queue for review by the stable release managers, and if approved will be installed in the stable-proposed-updates directory of the Debian archive. From there, it will be included in stable with the next point release.

Uploads to a supported stable release should target their suite name in the changelog, i.e. buster or stretch. You should normally use reportbug and the release.debian.org pseudo-package to send a source debdiff, rationale and associated bug numbers to the stable release managers, and await a request to upload or further information.

If you are confident that the upload will be accepted without changes, please feel free to upload at the same time as filing the release.debian.org bug. However if you are new to the process, we would recommend getting approval before uploading so you get a chance to see if your expectations align with ours.

Either way, there must be an accompanying bug for tracking, and your upload must comply with these acceptance criteria defined by the the stable release managers. These criteria are designed to help the process be as smooth and frustration-free as possible.

• The bug you want to fix in stable must be fixed in unstable already (and not waiting in NEW or the delayed queue).

• The bug should be of severity “important” or higher.

• Bug meta-data - particularly affected versions - must be up to date.

• Fixes must be minimal and relevant and include a sufficiently detailed changelog entry.

• A source debdiff of the proposed change must be included in your request (not just the raw patches or “a debdiff can be found at $URL”).

• The proposed package must have a correct version number (e.g. ...+deb10u1 for buster or +deb9u1 for stretch) and you should be able to explain what testing it has had.

• The update must be built in an stable environment or chroot (or oldstable if you target that).

• Fixes for security issues should be co-ordinated with the security team, unless they have explicitly stated that they will not issue an DSA for the bug (e.g. via a “no-dsa” marker in the Debian Security Tracker).

It is recommended to use reportbug as it eases the creation of bugs with correct meta-data. The release team makes extensive use of usertags to sort and manage requests and incorrectly tagged reports may take longer to be noticed and processed.

Uploads to the oldstable distributions are possible as long as it hasn’t been archived. The same rules as for stable apply.

In the past, uploads to stable were used to address security problems as well. However, this practice is deprecated, as uploads used for Debian security advisories (DSA) are automatically copied to the appropriate proposed-updates archive when the advisory is released. See Handling security-related bugs for detailed information on handling security problems. If the security team deems the problem to be too benign to be fixed through a DSA, the stable release managers are usually willing to include your fix nonetheless in a regular upload to stable.