Andreas Barth has posted an update about the etch progress; the arm release is a bit in trouble, but 11 architectures are still lined up for a December release.
We're getting nearer to the release. As you might have noticed, some BSPs
have brought down the number of release critical issues drastically during
the last weeks. We would like to thank all attendees for their hard
Please remember that we all need to work together to get Etch out on time.
For you as maintainer this means that you should discuss *every* major
change with the release team (“major change” includes, e.g., any soname
change or a shlibs bump for a library with many reverse-dependencies).
So let's take a look at what's changed since the last release update, what
you need to know about where we are today, and how we think we're getting
from here to a release of etch in December. Please take care to read the
second section if nothing else, though we also expect you'll want to read the
third section to make appropriate plans for your own packages.
Since our last release update, the RC bug count has gone down substantially.
Some especially long-standing issues, like the heaps of mozilla bugs, have
been solved for etch. At the moment, we have about 240 release critical bugs
relevant for testing, and about 40 of them are already fixed in unstable.
Many of the long-standing bugs are either about license issues, some of which
we hope to address with a General Resolution; or will be fixed with the
removal of mozilla or the addition of X.org 7.1. This means that we are
doing better now, but it is too early to relax. As long as we keep up the
momentum of recent weeks, a December release is still in sight!
The release team has made the decision to not include m68k in the official
release of Etch. As Debian's second port, m68k has been with us for a long
time, so it's sad to see it dropped; nevertheless we believe this was the
right decision to make based on the extent to which m68k is lagging behind
other architectures in supporting the packages that maintainers believe
belong in Debian.
We continue to discuss with the m68k porters what alternatives to being part
of etch can be provided for the m68k user community.
The other architectures are keeping up, with the notable exception of arm.
Some toolchain changes hit arm hard, and have resulted in long taking
builds, buildd timeouts, and other issues. We are quite worried about the
current state of the arm architecture. If these issues are not resolved,
we will be forced to ignore arm more and more for testing migration,
and perhaps even remove it from etch.
On the other hand, amd64 has now caught up with the other architectures,
giving us a total of 11 prospective release architectures for etch.
Finished. The default python in etch is now python 2.4. Yay!
Another thing finished. Good.
SELinux is turned off by default, but can be activated by boot options. If
you are interested in SELinux support for etch, now would be the right time
to test and give feedback to the SELinux package maintainers.
Where We Are
Still open from our release blockers list:
* sorting out docs-in-main vs. the DFSG
Most packages with non-free docs have been split now and only a few
packages are left. Sadly, the remaining packages include glibc,
automake and emacs21. Please try to help out for those.
* sorting out non-free firmware
There is a vigorous discussion on the debian-vote mailing list right now
about how firmware should be handled for etch. We hope this will go to a
vote in the next few weeks. Regardless of the outcome, we encourage
interested developers to help the kernel team with the work of fixing drivers
with non-free firmware to support userspace firmware loading.
* secure apt
What was still open was the key handling for apt keys. We now have an
agreed way to handle keys between the release team and ftp-master. We
will test key handling during the next Sarge point release.
Recently, a branch of the release notes was created  to allow the
updates for the new etch flow in. We also have a new pseudo-package
“release-notes” which should be used to track issues that need to be
If you know of any migration problems from sarge or other things that
should be noted, file a bug *now*. Discussions about the release notes
should happen on email@example.com.
Release critical bug count
Since our last release update, the number of uncoordinated library
transitions has gone down. Please continue coordinating transitions with the
release team up until the release of etch. Please always remember to check
if an upload could hold up the transition of other packages (see  if
you're unsure, or just speak with the release team).
A coordinated transition of dbus has just reached testing. Unfortunately,
since maintainers /don't/ always check whether their packages are affected by
a transition before uploading, and it's impractical for the release team to
send out mails to all maintainers for every transition, some packages had to
be broken in testing to get this library change in — including kde, which is
currently uninstallable on 2 architectures. This should be fixed within the
If you are maintaining a library package with many reverse dependencies,
we would like you to coordinate every SONAME-changing upload with the
release team. We have talked to the ftp-team to be notified if such
uploads are in NEW, but we would prefer if you would talk to us on your
The RC bug tracker shows about 240 RC bugs in etch, with 40 of those fixed
in unstable — quite an improvement over the past couple of months, but
clearly there is still work to be done. Please help us continue to bring
this number down.
Remember, we are in a permanent BSP from now until the etch release: you can
upload 0-day NMUs for release critical bugs open for more than one week.
You *must* still follow all other normal NMU procedures, including notifying
the maintainer via BTS before uploading. And of course, you need to take
care of anything you broke by your NMU. Please upload security bug fixes
with urgency high, and other RC bug fixes with (at least) urgency medium – as
of writing this, we have about ~40 fixes waiting for testing propagation,
which is still too much.
Please see the Developers Reference for more details about NMUing .
The Road Ahead
Toolchain and base freeze
The toolchain has now been frozen for some weeks, since shortly after the
last release update. Only a few major architecture-specific issues remain,
which we are confident the freeze will give us time to settle.
Now it's time for the next stage of the freeze. As of today, base packages
are frozen, along with the following “non-essential” toolchain packages:
* python and python2.4
* autoconf* && automake*
This list may be extended to include other toolchain packages as we notice
them. We will let maintainers know as this happens, but the canonical list
of frozen packages is always available from
If your package is frozen, and contains updates that should make it to Etch,
please contact us at firstname.lastname@example.org. Please note that only
important / low-risk bug fixes should go in, as the goal of freezing is to
reduce the chance something breaks. If there are any questions, please feel
free to contact us as well.
Reviewing our old schedule:
| N-105 = Mon 14 Aug 06:
| d-i RC [directly after base freeze]
We had a d-i release on August 11th, still tagged as beta version.
| RC bug count less than 170
Well. We haven't even reached this now, but the last few days have been
better. On August 14 we had about 300 bugs, so a linear distribution over
time would mean reducing the RC bug count by 110 by the middle of September
(i.e., a week ago).
That would be 190 bugs left by the middle of September, which thanks in large
part to our BSPers actually happened. That doesn't mean we're out of the
woods though, because the bug count has bounced back over the past week as a
result of new RC bugs being found. Fortunately, many of these are
easy-to-solve bugs found by archive testing, which will be great candidates
for the next BSPs.
So from here, getting down to 80 RC bugs for the general freeze on time
means a net reduction of 160 bugs in 1 month. But if every developer and NM
fixes one RC bug each, we should only need one week, right?
Seriously, it's still possible for us to meet this schedule, but it will
require pressing hard and keeping up momentum, especially as all of the easy
bugs get fixed leaving only the hard ones.
Fri 29 Sep – Sun 01 Oct
real-life BSP in Utrecht:
Fri 06 Oct – Sun 08 Oct
N-45 = Wed 18 Oct 06:
general freeze [about 1 month after base freeze]
review architectures last time (only remove broken archs)
final d-i build; chance to change the kernel version
RC bug count less than 80
N = Mon 4 Dec 06:
release [1.5 months for the general freeze]
no RC bugs left!
So the road ahead may seem long, but if we drive really, really fast and
don't stop to go to the bathroom, we just might make it there on time. Won't
you join us as we find out how fast we can take corners without rolling into
– Andi Debian Release Team  http://cvs.debian.org/ddp/manuals.sgml/release-notes/?root=debian-doc&only_with_tag=etch  bjorn.haxx.se/debian/testing.pl?package=foo  http://www.us.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu  http://ftp-master.debian.org/~he/base-freeze-packages  http://lists.debian.org/debian-devel-announce/2006/08/msg00004.html