Debian logoThe next version (8.0) of Debian GNU/Linux, codenamed Jessie, will be released in the first half of 2015. Debian’s developers have now announced the freeze date and freeze policy for Debian Jessie. An extract of the announcement (entitled “Bits from the Release Team (Jessie freeze info)”) is reproduced below.

We are happy to announce that we will freeze Jessie at 23:59 UTC on the 5th of November 2014. To avoid any confusion around exactly how we will freeze, we have prepared a draft of the Jessie Freeze Policy in advance

FREEZE POLICY

Notable changes to the policy include:

  • Well-defined stages in the freeze policy at certain dates.
    • After 3 months of freeze, we will no longer allow remove packages to re-enter testing
    • We only accept fixes for important bugs in the first month.
    • etc.
  • Proactive automated removals 3 months into the freeze.
    • Note that bug-free packages will be removed if they (build-)depend on a RC-buggy, non-key package.
    • Also note the interval of 7 days between each removal run.
  • Inclusion of “do” and “don’t” guidelines for uploads and unblock bugs.
  • Currently, we are undecided whether to maintain “carte blanche” freeze exceptions at the start of the freeze. For now, exceptions are *not* included in the freeze policy (i.e. do *not* rely on them). This means that changes have to migrate to testing *before* the freeze date if they are to be included in the release.
    • *If* such exceptions are added, they will *not* apply for packages where migration would change the “upstream” version.
    • Native packages are at a disadvantage here, since all uploads of native packages are considered a new “upstream” version.
    • It should go without saying, but “urgency” abuse is not an acceptable way of getting your latest changes into the release.
    • It should also go without saying that embedding a new upstream release in a patch just to get a such “carte blanche” exception is also considered abuse.

    As noted we are dealing with a draft, so there may be changes to the actual freeze policy. Should we change the policy in a substantial way, this will be included in subsequent “bits”.