Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Niels Thykier <niels <at> thykier.net>
Subject: Bits from the Release Team (Jessie freeze info)
Newsgroups: gmane.linux.debian.devel.announce
Date: Sunday 13th October 2013 15:01:31 UTC (over 3 years ago)
-----BEGIN PGP SIGNED MESSAGE-----
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
[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 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
   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".

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
later.

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

Misc./Other
===========

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.

[FREEZE_POLICY]
http://release.debian.org/jessie/freeze_policy.html

[GCC]
http://packages.qa.debian.org/g/gcc-4.8/news/20130904T225114Z.html

[ARCH_QUAL]
http://release.debian.org/jessie/arch_qualify.html
(Hover your mouse over the "number" in the "porters" cell to see the
names of porters)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)

iQIcBAEBCAAGBQJSWrWtAAoJEAVLu599gGRCPqEP/1ndUoCa6VqyziK1fCRHf+2D
KFM3/7q6FP7ap2eS6g7XnDSrtVdD3xnDChY/ddqnqZwmkn4ek2cUbg2ORIbLRTah
2rocHOYONwBIrWgVr2SoKIzHxLx/ZBgGHAct5zGwBeI83h3MLFtOht0DXKnMtGrc
XOcggEWT7w54y/Eb3fvJM75CFvOcaMEEkl1+aaKRquzOEIvy8JY2KDQdm1pCx7Ku
C1Y4BJTEbQRAWHFj2NUehCAVWCxUtMfoshwpKMPYa8DCndi6yJPGjr7YmHHMIOsk
H+3N6HgiCQfU9waEV+ETfkdqVc4kcUrmZRVSxTpvgWrXHu+/byJiabxmyvLDavkZ
hBgHR5lw+q90Zi91MN3kUCKIyvLmemJ+rYBCoKIyZvIVk/jcFGwUQt6Kz8K1SA1i
ZgMa5X0MQ21cNtPNl7DZwL26Ox+zqYd2eKgxX52RCnx6ia/LJSSPuIMkQPCNOvi+
EHAi/klhZLEr0WvLrWcSaY08Z0th2hW2kASwMLYWY6n6iHMD6ppqAqhtB+bWqNu5
RtxTbBI73xl5Tgddmj95QdXbk3wGQOw9NGHMOezZ3cZA7HDB6wKW04GdCsesW1cz
OH20weHnpBfea58AAo0sv84fz1n5+2rGX66PFsasbG8KQohI2BgAVFLkkd79ceRS
tifu5ereNM99yw7ssENW
=OU/V
-----END PGP SIGNATURE-----
 
CD: 3ms