Debian Weekly News - email
From: Anthony Towns <firstname.lastname@example.org> Date: Sun, 1 Jul 2001 11:04:48 +1000 To: email@example.com Subject: Debian 3.0 (woody) Freeze Begins 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 <firstname.lastname@example.org> Debian Release Manager
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 Joe 'Zonker' Brockmeier, Jean-Christophe Helary and Tollef Fog Heen.