Subject: Potato now stable
From: Anthony Towns (aj@azure.humbug.org.au)
Date: Mon Aug 14 2000 - 23:41:42 CEST
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 [0]),
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 debian-devel@lists.debian.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 debian-devel@lists.debian.org.
* 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 / config@kitenet.net)
* Automated Installation
With debconf integration, hopefully we should be able to
go a little further and support non-interactive installs
with woody.
(debian-devel / config@kitenet.net)
* 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 <ajt@debian.org> (Acting Release Manager), for Richard Braakman <dark@debian.org> (Debian Release Manager)[0] ie, one.
-- To UNSUBSCRIBE, email to debian-devel-announce-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
This archive was generated by hypermail 2b25 : Wed Aug 16 2000 - 11:08:23 CEST