Hello world, and welcome to a new week, a new month, and a new phase of
woody's development cycle.
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 assurance.
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,
see below)
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 packages.
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 release cycle.
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.
Cheers,
aj
-- Anthony Towns <ajt@debian.org> Debian Release Manager
-- 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 2b30 : Sun Jul 01 2001 - 07:34:30 CEST