Wheezy Freeze Policy

let's release!

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. fixes for release critical bugs (i.e., bugs of severity critical, grave, and serious) in all packages;
  2. changes for release goals, if they are not invasive;
  3. fixes for severity: important bugs in packages of priority: optional or extra, only when this can be done via unstable;
  4. translation updates and documentation fixes that are included with fixes for the above criteria.
  5. translation updates and documentation fixes;
  6. pre-approved fixes;
  7. as above, important changes that the maintainer feels are needed before release.

Note that when considering a request for an unblock or freeze exception, 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.

Rules to get your changes into Wheezy

Further discussion

As always, it is the release team's goal to get as much good software into Wheezy 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 optional or extra packages that remain unfixed after a week will still be grounds for removal from testing. Please also try and encourage 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 don't ask you not to make changes in unstable, but we do ask that you be aware of the effects your changes can have -- especially if you maintain a library. Please continue to keep disruptive changes out of unstable and continue making use of experimental where appropriate. 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.