Debian sarge release update

Hello world,


Let's take a break from talking about etch plans to talk about sarge
again, shall we?


Debian Installer RC3, kernels
-----------------------------

The RC3 release of the debian-installer has been published.  As Joey
Hess mentions in his announcement[0], this has been the best-tested
Debian Installer release candidate to date and it continues to hold up
under scrutiny, and the release team will be proud to use it as the
installer for sarge.  Thanks to the Debian-Installer team for their
great work.

However, various pending kernel (security) updates have shown us that
the current way of changing debian-installer for a new kernel ABI is
quite painful.  We are about to decide how we will do future kernel
updates in sarge.


The fate of 80386 is in your hands
----------------------------------

Currently, the 80386 sub-architecture for i386 is unmaintained.
Although sarge will include kernels capable of emulating certain 486+
instructions needed by current userspace libraries, this emulation
includes known root security holes; therefore, we cannot offer any
assurances that 80386 is supported in the tradition of Debian stable
releases.

This is a last call for volunteers: if 80386 is to be supported for
sarge, we need someone with knowledge of this architecture to step
forward to provide a secure solution (in kernel or in userspace), test
upgrade paths, and handle various other tasks necessary to get the
subarch in shape for sarge.  If no one steps forward, we will be forced
to drop official support for 80386 in sarge.

If 80386 will not be officially supported for sarge, we will also not
provide an upgrade path for existing 80386 users of woody.


ARM buildd lossage
------------------

As many of you have noticed (and asked about), the ARM autobuilders are
not keeping up with package uploads to unstable right now, because
several of them are currently off-line due to various hardware failures
and software/network configuration difficulties.  By the time you read
this, at least one fast ARM buildd is back on-line and started to catch
up; more buildds are to come.  Even so, given that the build queue for
arm is currently 500 packages deep, it will take some time to catch up
again.  We're working on this issue as quickly as possible, though, so
please, no hardware offers right now!

In the meantime, if you have a release-critical bugfix for sarge that is
being held out of testing *only* by a missing arm build, please contact
the release team so that we can arrange to push the package in if
appropriate.


testing-proposed-updates, testing-security
------------------------------------------

Getting testing-security up has steady progress.  OpenSSH 3.9 was
successfully compiled with woody's toolchain, and the connection reusing
feature from 3.9 is now being used by some buildds to find any remaining
issues.  As soon as this has been thouroughly tested, there should only
be the routine maintenance matter of setting up the wanna-build
databases for these queues and configuring/updating the testing chroots
on the buildds.


Freeze ahead
------------

With these changes done, we are now on the home stretch for the sarge
release.  We are now only waiting on the arm buildds to recover and
catch up to a reasonable extent, and on one last glibc upload -- and
then sarge is FREEZING.  This is, therefore, the last call for uploads
for sarge: if you have any final important changes to your packages
which you think need to make it into sarge, upload them now or never.

On a related note, we are now down to 90 open RC bugs in sarge -- and
many thanks to everyone who has worked so tirelessly to beat these bugs
into submission.  This means that if you have a release critical bug
open on one of your packages that's more than a week old, and you
haven't heard from anyone offering you patches, suggestions, or NMUs,
*assume your package has been removed from testing*.  If you want to
make sure it ships with sarge, a good time to upload it would be, um...
last month.  If you hurry, your package might still make it onto the
ark (the ark of arches?) before the frozen floods come slushing... ok,
this analogy is sunk.  Anyway, if you haven't fixed the RC bugs in your
packages yet, you should do so immediately.


Major changes in etch
---------------------

If you intend to make major changes (like a C++ ABI bump) during the
development of etch, please speak with the release team as soon as
possible, describing the changes you're planning and why.  This way, we
can help you to make your transitions as smooth as possible, ensuring
that packages go quickly into testing/etch, don't hold up other packages
or the release in general, and don't take us by surprise.  We would
appreciate it if you could send these emails before the end of April
to debian-release@lists.debian.org.


Upload targets
--------------

Those changes that are still needed for sarge should continue to be
uploaded according to the following guidelines:

  - If your package is frozen, but the version in unstable contains only
    changes suitable for testing, upload to unstable only and contact
    debian-release@lists.debian.org if changes need to be pushed through
    to testing.

  - If your package is frozen and the version in unstable includes
    changes that should NOT be part of sarge, contact
    debian-release@lists.debian.org with details about the changes you
    plan to upload (diff -u preferred).  If the release team approves of
    these changes, upload to testing-proposed-updates.  Changes should
    be limited to translation updates and fixes for important or RC
    bugs. 

  - If you need to do a bug fix directly in sarge, you will need to
    upload to testing-proposed-updates as well, with the same
    requirements as for frozen packages.

  - All other package updates should be uploaded to unstable only.
    Please use urgency=high for uploads that fix RC bugs for sarge
    unless you believe there is a significant chance of breakage in the
    new package.

If you want to increase the urgency of an already uploaded package,
please speak with the release team; this can be sorted out without the
need for another upload.


Keeping track of RC bugs in testing
-----------------------------------

Since BTS version tracking is a post-sarge feature, we depend on your
help to keep track of RC bugs that have been fixed in unstable but not
testing.  Over the past few months, we've been tracking these bugs
mainly through the use of reopened, sarge-tagged bug reports.  You can
continue to use this method to let the release team know about
release-critical issues, but we would encourage you to use
http://www.wolffelaar.nl/~sarge/ to send us comments on the
importance of particular updates waiting in testing.  This applies not
just to release-critical issues (which should be marked as "critical" on
that page), but also to important ones (and "minor" ones, if you feel
inclined).  For usage information about this site, please see the
previous announcement concerning it[1].


Cheers,
-- 
Andi Barth
Debian Release Team

[0] http://lists.debian.org/debian-boot/2005/03/msg00764.html
[1] http://lists.debian.org/debian-devel-announce/2004/09/msg...