Debian Project: Woody Freeze Plans - Progress Report II
May 07, 2001, 15:26 (1 Talkback[s])
(Other stories by Anthony Towns)
How to Help Your Business Become an AI Early Adopter
From: Anthony Towns <email@example.com>
Subject: Woody Freeze Plans - Progress Report II
Date: 07 May 2001 18:56:45 +1000
Well, congratulations are in order to Santiago Garcia Mantinan
<firstname.lastname@example.org> and the rest of the boot-floppies team: we've at last
had a (relatively) successful install of a woody system! 
As such, I'm hopeful that we'll be able to make a "preview release" of
woody (on CD) in the next few weeks that will allow testers to start
doing installations tests and generally give us a feel for what bugs
we've missed in our routine dist-upgrades.
Given that, I hope to be able to start the freeze in early June. As
announced previously on this list, the freeze will be staggered: policy
will be frozen and debugged first, followed by the base system, followed
by the standard packages and boot-floppies, followed by the rest of
Being optimistic, this means:
* Policy goes into debugging mode on 1st June, and no further
changes may be made after about 20th June.
* Base packages must have all release-critical bugs fixed by
1st July, and no further changes may be made after about 20th July.
* Boot-floppies, standard packages, task packages, and packages
included in tasks or in boot-floppies need all their
release-critical bugs fixed by 1st August, and no further
changes may be made to them after about 20th August.
* The remaining packages (optional, extra) need their
release-critical bugs fixed by 1st September, and no further
changes may be made to them after about 20th September.
* We release early to mid October.
Again this is still fairly optimistic, and not necessarily going to
happen. (Hi Slashdot.)
Where possible, packages with release-critical bugs at the appropriate
deadline will be removed from woody; for packages where this isn't
reasonable (base and some standard packages), the phase will be repeated,
delaying everything by a month.
There are four ports, any of which may want to try for a woody release:
hurd-i386, mips, hppa and ia64. If they do, they need to ensure that
their port has stabilised and is ready for mainstream use, that the
relevant required, important and standard packages have all been ported,
that they have a functioning autobuilder (or two) that can keep up with
unstable (and is keeping up with unstable) and that it's built a fair
chunk of optional and extra, and they need to ensure that they can get
boot-floppies working in the above time frame.
The main areas which will probably cause delays are:
* boot-floppies: we've had precisely one successful install,
and then only due to using CVS versions of this and hacked
versions of that; boot-floppies still have a way to go before
* policy: there are still a handful of policy changes that ought
to be proposed, passed and implemented for woody.
* ports: there are a fair few packages that don't correctly build
on some of our architectures, which need to be investigated
by hand. There are few people handling this, and it can take
copious amounts of time. If any unreleased architectures try for
release but have problems getting boot-floppies done, or getting
their port otherwise releasable, that could cause delays too.
* RC bugs: there are a still a lot of known but unfixed RC bugs,
and, it's pretty safe to say that there's a lot of unknown
RC bugs still to be noticed and diagnosed. Hopefully, we'll be
able to organise for interested users to do test upgrades and
installs of woody sooner rather than later, so we can get to the
point where we know most of our bugs sooner rather than later.
For reference, known RC bugs in the base system at the moment are:
74897: exim (segfault)
85128: console-data / sparc
85629: console-data / arm
88279: hostname / m68k
90789: fdutils (no longer builds)
91763: shellutils (not ready for release yet)
95185: findutils (security issue)
95480: sysklogd (strange problems)
95996: perl (build issues)
96352: binutils / m68k
96358: dpkg (assertion failure)
Anthony Towns <email@example.com>