Hello world,
So, it's April 30th (for most of the planet, anyway), which probably means
folks are beginning to get mildly curious about whether woody'll actually
be ready for release tomorrow. The answer is a definite "kind-of". Which
is to say, "no".
On the upside, woody itself is ready to be released. The only outstanding
changes that need to be made are the standard security fixes that need
to be made throughout the lifetime of stable anyway.
Unfortunately, that's exactly where we've dropped the ball: the security
team presently don't have the resources to handle security advisories
for woody [0]. While there has been a plan in place for roughly a year
on how to handle this ("rbuilder", for those playing along at home),
it hasn't been successfully rolled out across more than a handful
of the architectures we wish to support, and it further doesn't seem
like trying to rush it now will be particularly effective. As such,
an alternate arrangement, involving some moderately significant changes
to the existing autobuilder system are being made, which should become
active over the next week or so.
Naturally, we will not be making the woody release until we have a viable
mechanism for making timely security updates.
On the technical side of things, the only other significant problem we're
having is that we have so far been unable to produce fully successful
builds of CD images for alpha and sparc. This is being worked on, but may
mean that sparc and alpha CD images will be unavailable at release time.
The other signficant issue that's come up is a poor sense of timing on
behalf of a fair number of people. To take two fairly straightforward
examples: a few days before the expected release is not the time to file
eighty or ninety release-critical bugs about issues that have been being
tracked outside the BTS in a satisfactory manner for months; similarly,
it's far from ideal to have delayed the fix for the nscd bug (which has
been open for over a month and requires a new upload of the glibc package
to fix) until the very last day before release. These aren't isolated
examples: there's been significant amounts of "QA" work (for example,
checking buildability for binary-all packages; checking for packages that
modify conffiles) that has only been started _after_ the time when it's
reasonable to try doing anything about it, and there've been significant
numbers of uploads rushed in at the last minute for problems that could've
been resolved either by the maintainer or by NMU weeks or months ago.
These are two sides of the same coin, really: fixes need to be done
early rather than late so that they can be tested and, if necessarily,
fixed further, and problems need to be found even earlier so that there's
time to fix the problem right. It might be better late than never, but
really the difference isn't all that noticible. Hopefully people will
be able to use the forthcoming suffering as an incentive to get this
done right next time.
So, the final automatic run of the testing scripts was today, and will
be reflected in the next mirror pulse. From this point, we'll have
manually approved security updates to some packages, and very little
else, until release. Requests from the maintainer to remove packages
that are unreleasable may be considered. Requests from the maintainter
for an update to a package will generally be considered a request to
remove the package.
Cheers,
aj (woody release manager)
[0] Issuing an advisory and fixed .debs for the six architectures that
released with Debian 2.2 (potato) already takes, essentially, an
entire night with the current tools; doing likewise for the eleven
architectures that will release with woody will take more time than
the security team are able to commit; doing it with woody's eleven
architectures _and_ potato's six architectures for a few months
so that people have time to evaluate woody before being forced to
upgrade to it is completely out of the question.
--
Anthony Towns <ajt@debian.org>
Attachment:
pgpw5ltfHECg0.pgp
Description: PGP signature