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

Release sprint results - team changes, auto-rm and arch status



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

In this new and exciting update from your Debian Release Team...

 * Team Membership
 * Auto-removal of non-leaf packages
 * Release Goals
 * Architecture Status
   * ia64 in danger
   * sparc/ppc/mips/kfreebsd at risk
   * s390 dropped from testing
 * Default Urgency
 * Sprint

Team Membership
===============

We are pleased to welcome Ivo De Decker (ivodd) as a release
assistant. Dann Frazier is leaving his position as stable kernel
liaison and Marc 'HE' Brockschmidt, Luk Claes and Steve Langasek are
stepping down from their positions as release wizards.

Niels Thykier will join Adam as release manager for Jessie, replacing
Neil McGovern who is also stepping down from the team.

We are very grateful for all the contributions from Marc, Luk, Steve,
Dann and Neil in the past and wish them all the best.

Auto-removal of non-leaf packages
=================================

We are extending the auto-removal of non-key packages [AUTOREMOVALS]
to allow the removal of more buggy packages from Jessie.

Starting today, all non-key packages with RC bugs in Jessie for more
than 15 days will be considered for auto-removal, even if they have
reverse dependencies. This also means that the removal of these
packages will cause the removal of all their reverse dependencies.

Packages without reverse dependencies will be removed after the bug
has 15 days of inactivity. For packages with reverse dependencies the
package will be removed together with all reverse dependencies after
30 days of inactivity.

Packages with buggy dependencies can be removed from the auto-removal
list by fixing the RC bugs in their dependencies, or by removing the
dependency on buggy packages.

We would like to repeat that we obviously prefer to have fixes for the
outstanding RC bugs, and that (auto)removing packages and their
reverse dependencies is only used as a last resort.

Key packages [KEY-PACKAGES] will continue to not be considered for
auto-removals (but might be manually considered for removal).

If packages get auto-removed from testing, they can get back in when
they are no longer RC buggy and they do not depend on buggy packages,
using the same rules that apply to other packages.

As before, the list of auto-removal candidates is available from
http://udd.debian.org/cgi-bin/autoremovals.cgi

For automatic processing, use
http://udd.debian.org/cgi-bin/autoremovals.yaml.cgi

[AUTOREMOVALS]
http://lists.debian.org/debian-devel-announce/2013/09/msg00006.html

[KEY-PACKAGES] http://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Release Goals
=============

We discussed release goals in some depth at the recent sprint.

The general consensus was that, whilst release goals have been useful
in the past to introduce archive-wide changes, we should review
whether this remains the case and whether the release team is really
the right place to determine them. We intend to consult with the
project on this point in due course.

Of particular note is that we will not comment on the systemd release
goal until the technical committee has agreed upon a resolution to
this topic (#727708).

Architecture Status
===================

ia64 causes us concern for the following reasons:

 * binutils issues (#718047, #720404), resulting in build failures blocking transitions

 * many packages link to libunwind on ia64, which causes issues if
   used at boot time (as the library is in /usr) and means nearly 3000
   packages need to be rebuilt when the SONAME changes. The ingrained
   nature also leads to libunwind8 currently depending on libunwind7
   (which is no longer built)

 * d-i in a virtualised environment on top of HP-UX is broken
   (see https://lists.debian.org/debian-boot/2013/11/msg00017.html)
   

We have stopped considering ia64 as a blocker for testing
migration. This means that the out-of-date and uninstallability
criteria on ia64 will not hold up transitions from unstable to testing
for packages. It is expected that unless drastic improvement occurs,
ia64 will be removed from testing on Friday 24th January 2014.

The architectures sparc, mips and mipsel also cause concern:

 * [sparc] cannot run stable kernels.  Kernels in sid have issues too with some machines.
 * [sparc] gcc randomly crashes, SMP not working
 * [sparc] only one porter
 * [mips, mipsel] buildds/porterboxes run on hardware which is very old or has known defects:
   - mips octeon is unstable
   - mipsel loongson have CPU bugs
   - swarm is a decade old

kFreeBSD was a technology preview, and has not generated enough user
interest to bring in sufficient install base to continue in this
state.

We will review this situation after 28th January 2014.
Architectures still causing us concern at that point will join
ia64 in no longer being considered for britney migrations and may
be dropped from testing after a further period.

s390 and Hurd will not be release architectures for Jessie. s390 was
replaced by s390x in Wheezy and this completes that transition.  As
for Hurd; we do not believe it is ready.  Particularly, we believe
that it does not surpass kFreeBSD in user interest or install base.

Note that s390x and powerpc could also do with more porters, but at
this time we are not giving an official warning for them.

Updated requirements for release architectures
==============================================

We have decided that we will only consider architectures as release
candidates if they use auto-signing for all suites on all buildds
(except for newly-bootstrapped architectures in sid).

It has also come to our attention that a few buildds do not use
throw-away chroots. This sometimes results in unclean builds and we
have therefore decided to only consider architectures which use
throw-away chroots for all suites on all buildds as candidate release
architectures.

Finally, the gcc maintainers intend to remove gcc-4.6 and gcc-4.7 from
Jessie, so architectures using either version as their default
compiler cannot be considered as release architectures.

We have added these new requirements to our release architecture
policy[ARCH-POL] and the architecture qualification table[ARCH-QUAL].

[ARCH-POL] http://release.debian.org/jessie/arch_policy.html

[ARCH-QUAL] http://release.debian.org/jessie/arch_qualify.html

NB: The concerns-rm is still missing the auto-signing data.

Default Urgency
===============

We believe that it should be acceptable for most uploads to unstable
to be uploaded with medium urgency, to reduce the delay for testing
migrations.

Therefore, we have requested [#730343] that the dch tool defaults to
medium urgency. It should be clear that uploaders can (and should)
override the urgency to low for changes they know are disruptive.

For packages not in testing, the migration delay of 10 days will not
be changed.

[#730343] http://bugs.debian.org/730343


Sprint
======

Many of the things above were worked at the sprint in Paris.  The
Release Team would like to thank IRILL for hosting us.  Also thanks to
our beloved DPL without whom (and his occasional reminders/nagging)
the sprint would probably never have been.


Niels, on behalf of the Debian Release Team.

PS:

    Remember, remember
    the fifth of November

That is when we freeze Jessie!

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

iQIcBAEBCAAGBQJSl6FsAAoJEAVLu599gGRC3xIP/0YU9sXJh6zcftv0kfn5ifdz
ivyvUQ6w0udFhhnny+TO+SKaU/g4YZpdg46bamBhXlKeoOaTLXK7AbEklQcG+A1Q
mSa9lngTNZjgSweinFjx53aIPwJ3+BLLmQ0TzMSx62hhIN8WfGiyO1V/C3IaatPw
Ty7KMWs2UM80Fw8v8ajvb1heN6cEoaoZ6zCDPrM+kJ5FrHiyQIYopdC1RCFh/AwO
xQE+5Zz7R25munga2WYwQo/il5z+OOkdj49Y5JhERQLefOkSzqfsk4jaxxqQ7uDH
9KtmekMNwYdL1ppOkjCcKi7d1OsgcGoZ/rP9l6eDTWWwOaLlwMV7+HR2ZHZkMuy4
2r7aIRygJnSVBxHQ2docIAqJUeL+S/EcIZoxqrt8a/3i3l5bI6zXwmY6QLMI8+X6
FS0DWEXa3SQUvFWNP0Mfxf4a34YnJgfUhajpq7BN9dRYHANMXnglLbwogkp9BtIy
Y6QaqR8IJR/AtwWBHaCHxly8a65RlVA3RImQG468+SbjZ6NQVuZsUVeCO59tBgy+
OCstYl5BBw8/rEuyclG9EjnMXxaARAgK5/VPQ2bF3MQwHY3K7RGkjkcF4HSSeBOq
pU6Glgk+0ZGjPs0RtBy3qXmYoad0mp/EN/PSYSi4iMRMWe48+Oa/ULwTODChvKrk
pmrM6CsEU9mZtLXFTkxa
=BvpN
-----END PGP SIGNATURE-----


Reply to: