Hello world, Well, as some of you might have noticed: ajt@auric:/org/ftp.debian.org/ftp/dists$ ls -l Debian2.2r0 stable lrwxrwxrwx 1 troup debadmin 6 Aug 14 13:06 Debian2.2r0 -> stable lrwxrwxrwx 1 troup debadmin 6 Aug 14 13:06 stable -> potato CD images and the archive are being mirrored more or less as I type. So you can expect the prepared announcement to go out soon (it's scheduled for the "official release time" of 00:00 GMT). Some things that won't make the "real" announcement follow. First, some thanks are due to some of the people without whom potato wouldn't have made it through these final stages: * Branden Robinson, Ben Collins, Steve Gore, and Mike Renfro for tracking down and fixing some X problems at the 11th hour. * Daniel Jacobowitz, for somehow getting PowerPC support from shaky to first class, and tracking down and fixing problems right up until the 11th hour and fiftieth minute. * Ben Collins and Steve Gore, for making sure potato's sparc support is as good as possible, and tracking down and fixing problems right up until the 11th hour and fifty-fifth minute. * Martin Schulze, for tidying up some security fixes at very short notice. * Adam Di Carlo and Josip Rodin, for keeping our release notes as up to date as possible. * Phil Hands for getting complete CD sets up and mirrored almost as quick as you can say "oh my god, cdimage.debian.org has crashed again!" * James Troup, who kept the archive in tip-top shape throughout. By omission, this does a fairly impressive injustice to everyone else who helped with development, testing, fixing bugs, documenting problems and work arounds, giving support, and everything else everyone's done in the past months, so, well, thanks everyone! So that means we can start really focussing on the next release: woody. Well, after focussing on partying like it's the year after 1999, perhaps. Once we get to woody, though, there are probably two things that are particularly worthwhile doing. As per usual, we should probably have a few weeks discussing "release goals" for woody to see what sort of direction we want to head (and then going ahead and implementing whatever we feel like anyway). As well, (and here's where you might be able to pick up the fact I've been reading too many management books recently ), I think it's probably a good idea if we go over some of the things that went wrong this time and see what we can to fix them, and which things went right so we know to keep doing it. So, first, here's a rough idea of some of the things I think went wrong and right. (Technical followups to firstname.lastname@example.org) * Tasks are great, but task-* packages suck when some of the packages included have release critical bugs. (Remove the package, the entire task breaks) * boot-floppies, kernels (and modules), and release notes are all a pain to get uploaded and installed. * Working out which bugs are really release-critical and fixing their severity so we know where we're at is overly time consuming. * Getting security updates installed is suboptimal: some don't get built properly; some don't get put in incoming for dinstall to process. * Testing updates to frozen is suboptimal: updates go into incoming, wait there for a while, get added to frozen, we discover they introduce as many release critical bugs as they solve, rinse, repeat. The "wait for a while" part is particularly suboptimal, but without it, it's not really a freeze. * boot-floppies needs huge amounts of time to get into a functional state: from November or so 1999 to June 2000 this time, roughly. * debian-cd scripts seem to be working great: the "minimal rsync" to update the images between test cycle three and the release seem to be working fine, and the separate non-us CD#1 seems like a great idea to me. * The autobuilders cope *really* well with most updates. The security team also seem to have perfected getting updates recompiles really quickly on all architectures when it's necessary too. All very impressive. There's probably lots more good things too, the above is probably hopelessly biassed towards the bad. In addition, here's my understanding of goals already being worked on for woody (and who's working on it, and where to talk about it). Technical discussion should go to email@example.com. * New "testing" distribution This is a (mostly finished) project that will allow us to test out distribution by making it "sludgey" rather than frozen: that is, a new distribution is added between stable and unstable, that is regularly and automatically updated with new packages from unstable when they've had a little testing and now new RC bugs. (Anthony Towns; debian-devel) * Dinstall Rewrite / Package Pools There's a lot of interest in updating dinstall to better cope with our archive and the various new ideas we want to deal with. A new layout of the archive itself, and a new process for packages to enter the archive and become members of some of our distributions are probably involved. (Anthony Towns, Jason Gunthorpe, Richard Braakman, among others; debian-pool) * Debconf Integration Most of the debconf infrastructure is now written, and it's already in production use with potato. It will hopefully be finished, and extended to handle all installation I/O. (Joey Hess; debian-devel / firstname.lastname@example.org) * Automated Installation With debconf integration, hopefully we should be able to go a little further and support non-interactive installs with woody. (debian-devel / email@example.com) * Apt Frontends dselect replacements like console-apt, gnome-apt, and aptitude should probably should probably be standard. (debian-devel) * IPv6 Support A continuing goal is more complete support for IPv6. Hopefully we can get some of the IPv6 patches available from various places mainlined in woody. (debian-ipv6) * Modular Install The boot-floppies are being redesigned, so as to be more modular (and hence not require five disk images when you only need a couple of megabytes for your particular setup) and hopefully more maintainable. (Joey Hess; debian-boot) This is excluding all the usual improvements to individual packages, of course. As a rough guide, and presuming woody is in good shape, we'll consider freezing again in roughly six months, so think mid-February or so. Note that this'll require, among other things, completely operational boot-floppies for all the architectures we'll be releasing. That's about it. Have fun! -- Anthony Towns <firstname.lastname@example.org> (Acting Release Manager), for Richard Braakman <email@example.com> (Debian Release Manager)  ie, one.
Description: PGP signature