|The event we have all been waiting for, Woody freeze has began.
Below is the whole announcement by Anthony Towns.
Welcome to the woody freeze.
As previously proposed, the freeze will proceed in four
phases: first policy will be frozen, followed by the base
system, followed by standard installs, and concluding with the
remainder of Debian. The aim of this first part of the freeze
is to finalise our expectations of the release (what we want
packages to look like, what architectures we’re going to
release) and to prepare ourselves for the freezing the base
system by ensuring that the base system is releasable.
Note that this does not involve a freeze on package
development yet: bugfixes, and new features are still welcome,
and will continue being added to woody in the usual way. What
it does mean is that your packages will be frozen in the near
future, so now is probably a good time to limit yourself to
only introducing new features that have already been heavily
tested upstream, and fixing bugs.
In detail, the goals for this phase are:
- Finalise debian-policy: accept any further proposals that
woody packages should concern themselves with; and ensure
-policy is a useful document for people working on quality
Deadline: final version of debian-policy for woody needs to be
uploaded to the archive by July 21st.
- Finalise our target architectures. As well as alpha, arm,
i386, m68k, powerpc and sparc, we have the opportunity to
include ia64 (Intel’s new 64bit Itanium architecture), hppa
(HP’s PA-RISC architecture), mips and mipsel (SGI and
Decstation machines), too. Requirements for inclusion in
woody are fairly simple and have been met, or are close to
being met, by all those architectures. For reference, they
are: a working, relatively stable toolchain, a usable system
(including all of base and standard; and a fair chunk of
optional and extra), and a functional install. (Hurd people,
Deadline: someone from each architecture that wants to release
needs to mail -release with their current status, and a successful
install report by July 24th.
- Determine whether cryptographic software can be moved
from non-US/main to main. Ben Collins (project leader) is
hustling this through the appropriate avenues.
Deadline: legal advice needs to be obtained by July 21st.
- Ensure the base system is releasable on all
architectures: this means making sure we know what packages,
exactly, the base system consists of on all architectures;
and fixing any and all release critical bugs (ie, with
severities critical, grave or serious) in those
Deadline: base packages need to be free of RC bugs by July 21st.
If all goes well, the next phase will begin on the 1st of
August. If all goes incredibly well, we’ll release in November.
Ha ha ha.
The main risk that may affect moving on to the next phase is
the possiblity of finding release critical bugs in the base
system that take significant amounts of time to fix.
As you’ve noticed by a careful analysis of the subject line,
the woody release will be numbered Debian 3.0, in recognition
of the large number of changes made since potato. This is, to
put it mildly, a somewhat controversial decision, but it’s one
I get to make. Personally, I’m pretty happy with the way
woody’s progressing, and I think by the time it’s released
it’ll easily live up to that number — and by that I mean the
“3”, not the “.0”.
On the subject of controversial decisions, one I’m not going
to make today is what to call the release after woody. That one
will be made when woody is released and a new testing
distribution is forked from woody. Besides which, I still
haven’t gotten around to rewatching Toy Story.
While I may not be too concerned one way or another about
the name of the next release, I do have some ideas about how it
might be good to handle the next release. My overriding goal
for this release was to manage to get a short, controllable
freeze; one that we can get over and done with in a few months,
rather than letting it drag on for seven months with no end in
sight, but this came at a cost of letting the development cycle
go on for quite a while: ten and a half months, as it turned
out. For the next cycle (assuming this freeze actually turns
out to be relatively short and controlled), I think it would be
interesting to see if we can do the same thing again, with a
short (2 or 3 month) development cycle, for a 5 to 7 month
Which would mean you mightn’t need to worry too much about
not getting the neat new feature you were planning on working
on into woody, if that’s any consolation.
And on that note, I’m inclined to think Hurd is probably
better off targetting the next freeze, (in, say, six to eight
months from today) rather than woody. In particular, Hurd is at
present both a difficult target to port to (and thus has a
quite limited range of software when compared to the Linux
ports of Debian) and isn’t able to self install.
In short, the freeze, she is begun. Have at it.