Bits from the Release Team (Jessie freeze info)

To: debian-devel-announce@lists.debian.org

Subject: Bits from the Release Team (Jessie freeze info)

From: Niels Thykier <niels@thykier.net>

Date: Sun, 13 Oct 2013 17:01:31 +0200 (CEST)

Message-id: <[🔎] 20131013150131.BBDEB2000C2F8@thykier.net>

Mail-followup-to: debian-devel@lists.debian.org

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