What happens when we freeze
We have some criteria for what changes we are going to accept. These are listed below. These criteria will become more rigid as the freeze progresses.
We will continue to do auto-removals during the entire freeze. Please see below for more details.
The release managers may make exceptions to these guidelines as they see fit. Such exceptions are not precedents and you should not assume that your package has a similar exception. Please talk to us if you need guidance.
Please talk to us early and do not leave issues to the last minute. We are happy to advise in case you need the release team's help to fix RC bugs (e.g. to remove an old package)
Changes which can be considered
- targeted fixes for release critical bugs (i.e., bugs of severity critical, grave, and serious) in all packages;
- fixes for severity: important bugs in packages of priority: optional or extra, only when this can be done via unstable;
- translation updates and documentation fixes that are included with fixes for the above criteria;
Note that when considering a request for an unblock, the changes
between the (proposed) new version of the package in
the version currently in
testing are taken in to account. If there
is already a delta between the package in
the relevant changes are all of those between
testing and the new
package, not just the incremental changes from the previous
upload. This is also the case for changes that were already in
unstable at the time of the freeze, but didn't migrate at that
Applying for an unblock
- Prepare a source
debdiffbetween the version in
unstableand check it carefully
reportbugto report an unblock bug against the
release.debian.orgmeta-package. Attach the source diff. Include a detailed justification of the changes and references to bug numbers.
- Depending on the queue, there may be some delay before you receive further instructions.
If you are unable to bring your fix through unstable, for example
because there are unrelated changes already uploaded there, the
release team can grant you permission to use the
testing-proposed-updates mechanism. Prepare an upload targeting
testing-proposed-updates but do not upload it, and then contact
us through an unblock bug.
A targeted fix is one with only the minimum necessary changes to resolve a bug. The freeze process is designed to make as few changes as possible to the forthcoming release. Uploading unrelated changes is likely to result in a request for you to revert them if you want an unblock.
Some examples of changes that are undesirable during a freeze:
- dropping a -dbg package in favour of -dbgsym
- adding a new systemd unit in place of an init script
Removing packages from testing during the freeze
Throughout the freeze, we will continue to remove non-key packages with RC bugs in testing and their reverse dependencies automatically. As usual, the auto-removal system will send a notice before this happens. Please note that it is not enough for the bug to be fixed in unstable. The fix (in unstable or testing-proposed-updates) must be done in such a way that the fixed package can be unblocked and allowed to migrate to testing, based on the rules listed above. You must contact us to ensure the fix is unblocked - do not rely on the release team to notice on their own.
Manual removal may still happen without warning before the standard auto-removal periods have passed, when the package is blocking other fixes.
After 5th January 2017, removed packages will not be permitted to re-enter testing.