Freeze Policy for Jessie

let's release!

What happens when we freeze

We will freeze at 23:59 UTC on the 5th of November 2014, and we will run one automated migration at that time. After that, you will need an unblock for your package. Unlike the Wheezy freeze, we are not planning to give "carte blanche" unblocks to packages in unstable. So ensure your package is in testing before that last run.

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.

Changes which can be considered

There are some packages we know we won't approve. So as not to have everyone contact us at once about such packages, here are the guidelines for changes that will be accepting into testing during the freeze:

  1. targeted fixes for release critical bugs (i.e., bugs of severity critical, grave, and serious) in all packages (applies during the entire freeze (ok for TPU));
  2. fixes for severity: important bugs in packages of priority: optional or extra, only when this can be done via unstable (until the 5th of December 2014);
  3. translation updates and documentation fixes that are included with fixes for the above criteria (until the 5th of January 2015);
  4. translation updates and documentation fixes, via TPU when included with other TPU-applicable fixes. (until the 5th of January 2015)
  5. pre-approved fixes (until the 5th of January 2015);

Note that when considering a request for an unblock, the changes between the (proposed) new version of the package in unstable and the version currently in testing are taken in to account - i.e. if there is already a non-migrated version of the package in unstable, the relevant changes are all of those between testing and the new package, not just the incremental changes from the previous unstable 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 point.

For uploads to testing-proposed-updates, only changes in category "i" and "iii" are permitted and only while these categories are applicable (see the list above for the deadline). Please remember that in this case all the changes must be applicable for a TPU upload. That is, you are not allowed to do TPU uploads containing changes of category "ii", even if done together with a category "i" change.

How to get an unblock

How to get your package unblocked.

  1. What to include in the new package (relative to the version in testing):

    • Changes directly related to RC bug fixes
      • Only make changes that are necessary to fix the bug
      • Ask the release team if in doubt
    • Changes to the changelog:
      • Document all changes verbosely
      • Add references to bug reports for all relevant changes

  2. A non-exhaustive list of what not to include (When in doubt, leave it out):

    • change source format (bad)
    • change patch systems (bad)
    • change debhelper compat version (bad)
    • package new upstream releases (bad)
      • rare exceptions can occur to this rule, e.g. for pre-approved changes.
    The above listed do not-items are sufficient for a flat out rejection of your changes.
  3. File an unblock bug against the "release.debian.org" pseudo package. As a non-exhaustive list, do:
    • use reportbug to file the bug
    • explain why you want this change included. Bug numbers are a must.
    • include the changelog entry/entries in the request
    • include a debdiff between the testing version of the package and the version you uploaded (or is about to upload)
    • filter out auto-generated files from the debdiff you send to us (please document the options given to filterdiff in the request)
    • use interdiff when amending your debdiff(s) or/and assist with reviewing "changes to patches" (as needed)

If the version in unstable has significant changes that cannot be reversed or stuck behind other packages that are not acceptable, please contact the release team (i.e. file a bug) for doing your upload to testing-proposed-updates. However, please remember that stricter rules apply to testing-proposed-updates (see here for the rules.)

Removing packages from testing during the freeze

During the freeze, we will continue to automatically remove non-key packages with RC bugs in testing and their reverse dependencies. 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.

YES, this means that your package will be removed if it (Pre-)Depends or Build-Depends on an RC buggy non-key package. And, YES, this removal occurs even if your package has no RC bugs. In other words, please ensure that your packages and their (non-key package) dependencies are RC bug free. If you can remove the (Build-)Depends on an RC buggy package in a non-invasive way, you can ask for pre-approval to make this change to avoid auto-removal of your package.

Please note that in some situations, even key packages may be manually removed from testing if there is no other option to get rid of RC bugs. Also, manual removal can happen before the standard auto-removal periods have passed, when the package is blocking other fixes.

If your package was removed from testing due to an RC bug, then we may consider letting it re-enter testing if:

  1. you fix its RC bugs and file an unblock for your fixed package within a week of its removal.
  2. the request is submitted before the 5th of February 2015

After the 5th of February 2015, we will not allow packages to re-enter testing if they are removed.

If your package is in danger of being (auto-)removed, and you have a solution to avoid this, please contact us before the package is removed.

Further discussion

As always, it is the release team's goal to get as much good software into Jessie as possible. However, a freeze does not mean that your package is ensured a spot in the release. Please continue to stay on top of release-critical bugs in packages that you maintain; RC bugs in your packages will still be grounds for removal from testing. Please also try and fix packages you depend on with RC bugs. We'd like to avoid removing lots of packages with dependencies if possible, and your help can be valuable.

Please also note that since many updates (hopefully, the vast majority) will still be going in through unstable, major changes in unstable right now can disrupt efforts to get RC bugs fixed. We do ask that you be aware of the effects your changes can have -- especially if you maintain a library or a key package. Please continue to keep disruptive changes out of unstable and continue making use of experimental for changes that are not suitable for jessie. Note that you can stage NEW uploads in experimental to avoid disruption in unstable.

Also, in case you need the release team's help to fix RC bugs (e.g. to remove an old package), please feel free to contact us.

For packages which missed the freeze only for reasons outside of the control of the maintainers, we might be generous, but you need to contact us on your own, and you need to contact us soon.