Debian Weekly News - email

From: Anthony Towns <>
Date: Tue, 15 Aug 2000 07:41:42 +1000
Subject: Potato now stable

Hello world,

Well, as some of you might have noticed:

  ajt@auric:/org/$ 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,
	  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

	* 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

	* 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

	* 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 /

	* Automated Installation
		With debconf integration, hopefully we should be able to
		go a little further and support non-interactive installs
		with woody.

		(debian-devel /

	* Apt Frontends
		dselect replacements like console-apt, gnome-apt, and
		aptitude should probably should probably be standard.


	* 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.


	* 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

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 <> (Acting Release Manager), for
Richard Braakman <> (Debian Release Manager)

[0] ie, one.

To receive this newsletter weekly in your mailbox, subscribe to the debian-news mailing list.

Back issues of this newsletter are available.

This issue of Debian Weekly News was edited by Joey Hess.