[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bits from the Release Team (Jessie freeze info)

Hash: SHA256

Freeze date and Freeze Policy for Jessie

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

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 removed
     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
 * 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
   - 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".

Results of porter roll-call

Summary table:
Arch           || DDs || NMs/DMs || Other || Total
- ---------------++-----++---------++-------++------
armel          ||  5  ||       0 ||     2 ||    7
armhf          ||  6  ||       1 ||     2 ||    9
hurd-i386      ||  5  ||       0 ||     3 ||    8
ia64           || *0* ||       0 ||     3 ||    3
kfreebsd-amd64 ||  5  ||       0 ||     2 ||    6
kfreebsd-i386  ||  5  ||       0 ||     2 ||    6
mips           ||  2  ||       0 ||     1 ||    3
mipsel         ||  2  ||       0 ||     1 ||    3
powerpc[1]     || (1) ||       0 ||     2 ||   2.5?
s390x          ||  1  ||       0 ||     1 ||    2
sparc          ||  1  ||       0 ||     0 ||    1

[1] The (1) and .5 is from a "I am not primarily a porter
[...]"-remark, so I wasn't sure how to count it.

Based on the number of porters, we are considering changing the
current requirements of "5 DDs" to better reflect the reality of the
situation.  We will follow up in a future bits on the changes.

That said, we would like to encourage porters behind all ports to
ensure that the toolchain is up to date and working.  We are aware of
at least gcc on mips having its test suite disabled[GCC].  Other ports
may suffer from similar issues and we hope to have those resolved
sooner rather than later.  We are currently waiting for the gcc
maintainers to compile a list of such issues.

The architecture qualification page has been updated to include the
names of the current porters (except for ia64, where there are no DD
porters at all)[ARCH_QUAL].

Proposed Release Goals

The call for release goals has finished and we have received the
following proposals:

 * Native systemd support in every package with sysv scripts
 * Hardening of ELF binaries (carry over from Wheezy)
 * debian/rules to honor CC/CXX flags
 * clang as secondary compiler
 * piuparts clean archive
 * Cross Toolchains in the archive
 * Make the base system cross-buildable
 * SELinux
 * UTF-8

We have yet to process these goals listed above; for now they remain
only proposed release goals for Jessie.  We will be reviewing them and
talking to the advocates about them.  Accepted goals will be announced

Note that the list above does not include some proposed goals that
were already rejected.


Britney now understands "pkg:any" relationships.  Our build services
are also able to process these dependencies.  However, please be aware
of #723586 (and other possible Wheezy->Jessie upgrade problems) before
you add/use any dependencies of this kind.

Niels, on behalf of the Debian Release Team.



(Hover your mouse over the "number" in the "porters" cell to see the
names of porters)

Version: GnuPG v1.4.15 (GNU/Linux)


Reply to: