It's not the catchiest subject line, but it'll do. Short summary: It's about time we froze. Go help Adam with boot-floppies. The long story is something like this: I was originally hoping to get woody out by Wednesday, if for no other reason than for the beautiful double entendres it'd inspire. But for one reason and another (and another and another and another), it wasn't to be. We are, though, more or less to freeze now, I think. As is my wont, we'll take a quick digression already. I'm sure everyone reading this has different things they'd like to get out of the next release of Debian. It's probably reasonably appropriate for me to give a brief idea of what I'd like to get out of it. Obviously, you're welcome to agree with these or not. First, I'd like the release process to be a bit smoother than in the past. Our release process has a few problems: we tend to have no idea when it's going to end, or where it's going; we tend to not make as much use of people who're willing to do beta-testing as we might; and we tend to end up with ridiculously old versions of most of our packages when we're finally done. Second, I'd like to have less buggy packages. Personally, I'm embarrassed to give someone a potato CD, and watch bugs appear doing a standard install, which could and should've been noticed and fixed with just a minimum of testing. Third, I'd really like to see Debian include some of the nice "desktopy" stuff that's coming out for Linux these days: office software, DVD players, games, KDE, Gnome, Mozilla and so on. I'd like to see the installer cope nicely with the hardware that goes with it, video cards and sound cards and TV cards and whatever. Much of this is already packaged, but much of it's somewhat out of date, or buggy, or not integrated as well as it could be or whatever. I'd like to be able to install a Debian system on some random name brand computer and be able to give it to my parents or my cousin and have it be fairly usable; maybe with Wine or VMWare or plex86 on it for any specific Windows programs they need. There are probably a hundred other goals people have that they'll work towards for woody, but *my* ideal release would meet those three. The actual woody release may well not, but, hey, I can hope. How I'd like to run the whole freeze thing is probably somewhat influenced by the above. Now, I've screwed up a bit here, because I haven't taken the time to properly discuss how we're going to do the freeze. First, and probably most noticably, since we've already got separate testing and unstable suites, I don't think we'll need to fork a frozen branch as well. So testers will just need to point at testing/woody, and uploads will just continue targeting unstable. For those people who want to do some heavy development on their package that they don't want to go into woody (or to get in the way of bugfixes for woody), I'm inclined to think they should probably upload to experimental, or use their home directory on klecker.debian.org. This should make things a bit easier for the autobuilders, which tend to have some difficulties coping with "frozen unstable" uploads. Additionally, and more importantly, I think we need a little more structure to our testing than just `Here's 6000 packages, whaddaya think?'. So, what I've been thinking, and what I'm (belatedly) proposing, is to roughly invert the test cycles and the freeze itself, so that instead of freezing everything then doing test cycles to work out where we're at, we instead choose some part of Debian to test, test it, and, if it's good enough, freeze it. Once everything's successfully tested and frozen, we release. The three main test cycles I think we'll need are as follows: 1. The base system 2. Boot-floppies, standard packages and tasks 3. Optional and extra packages Hopefully, this would allow us to have fairly current versions of most of our packages (ie, optional packages), and also gives us plenty of time to at least document any known bugs in our base system. We won't begin any of these cycles until we have basically functional packages for that portion of the system: so for example test cycle one won't begin until we've fixed the RC bugs in required and important packages (and determined what packages are in woody base), test cycle two won't begin until we've got working boot-floppies for all architectures, and any optional or extra packages that are uninstallable or have RC bugs will be removed before test cycle three begins. During each cycle, updated packages will be acceptable, but major reorganisations (like X4, the new perl packages, split packages, etc) and new packages won't be. Note that "new" will probably be compared to whether it's in testing or not, not whether it was uploaded to unstable the night before the cycle begins; so it's probably best to make sure packages are recompiled against new and renamed libraries and so forth earlier rather than later, which is probably a a good thing anyway. Otherwise, packages will continue to go in according to the rules of testing: ie, their dependencies are okay, they don't have RC bugs, etc. This does mean that packages uploaded a week before the end of the cycle that are only low urgency won't go in either (unless the cycle's repeated), since they won't have had the requisite ten days of testing in unstable before the cycle ends. At the end of each cycle, we'll either say "Yup, all those packages are done, they're ready for release right now" and move on, or "Hmm, we'd really be better off working on this some more", and repeat the cycle. Hopefully we won't need to repeat any of the cycles more than a couple of times. If we have month long cycles (which seems about reasonable) and repeat all the cycles twice, we'll have a "freeze" that lasts about as long as the potato freeze did. Note that this will be a fairly hard freeze: once a package gets frozen, changes will stop being automatically accepted by the testing scripts (duh), and won't be manually accepted unless it's a release critical issue and the changes have been carefully reviewed by at least a couple of people, and everyone's confident nothing'll get broken because of the changes. If the bug *has* to be fixed, but we can't do it in a way that we can be absolutely sure won't break things, we'll probably need to reset the testing cycles right back to the start to make sure things haven't become royally screwed. Or at least, that's what I say now (and what seems good policy as far as QA goes). We'll see what actually ends up happening. So, a theoretical (and overly optimistic) timeline: 2001.02.15 - 2001.02.28 i386 boot-floppies updated for woody (and any other architectures) mips, hppa, ia64 get their architectures in sync and work on boot-floppies, and work out if they're going to release with woody or not 2001.03.01 debian-cd folks preduce a "preview release" for i386, and any other architectures that have vaguely functional boot-floppies 2001.03.01 - 2001.03.31 policy gets finalised (/usr/share/doc? task-* packages? invoke-rc.d? crypto and non-US?) people work on porting boot-floppies to all architectures that plan on releasing any major new updates to base packages that'll be included in woody get added to woody (apt 0.4, perl 5.6 reorg) any RC bugs in base packages get fixed (binutils/m68k, ncurses/sparc, ...) 2001.04.01 the architectures that'll release with woody have working base systems (and probably passable boot-floppies) 2001.04.01 - 2001.04.30 base packages testing cycle; QA and testing focus on finding and fixing any irritating bugs that can be fixed in those packages without having to rewrite them from scratch boot-floppies become usable, and basically feature complete for all released architectures RC bugs in standard and task related packages fixed 2001.05.01 base packages finalised: security updates only boot-floppies are basically feature complete no new standard packages, no new tasks, no changes to what're in tasks 2001.05.01 - 2001.05.31 standard installs finalised, boot-floppies bugs fixed, etc RC bugs in optional/extra packages fixed (for those packages that want to release) 2001.06.01 no more RC bugs in any packages first CD complete, and won't change except for security updates standard installs (ie, ones that use tasks to choose what packages to install rather than dropping into dselect/console-apt) are complete, and won't change either 2001.06.01 - 2001.06.30 final testing of optional/extra packages finalisation of release notes, press releases etc 2001.07.01 - 2001.07.07 final security updates before release CDs built 2001.07.08 release Now, those dates are obviously not realistic: it's questionable whether there'll even be alpha-quality i386 boot-floppies by the end of this month; and some of the test cycles will probably be delayed because RC bugs won't be fixed; and some may need to be repeated, or reverted. Let me note that again for anyone from the press that might be reading: <blink> THOSE DATES ARE NOT REALISTIC! </blink> [0] As far as risks go; the biggest ones seem likely to be fixing weird toolchain issues (getting Qt to build on alpha, binutils on m68k, ncurses on sparc...), and getting from more or less nothing to working boot-floppies. For reference, it took about six months (Nov '99 - Jun '00) to get boot-floppies for potato, the above timeline only budgets three or four for the same job. So go help Adam on boot-floppies. So now's probably a good time to orphan those packages you haven't been maintaining for a while, or to update those packages that've had new upstream versions for a year, or to send in patches for those bugs that've gone unfixed for months, or to do that reorganisation you've been leaving 'til the last minute. From about this point until we've released, it's probably reasonable for people to NMU packages with release-critical bugs without overly much notification. Hopefully we'll have some Bugsquash weekends organised soonish as far as that goes. In all the above, I've blithely assumed that there are a bunch of non-developers who're helping out doing test installs and upgrades from potato and reporting bugs and generally helping out with QA. This usually takes place on the debian-testing mailing list, and in the past there's been someone organising that (producing "install report" forms, and helping out people who haven't used the bug tracking system before report useful bugs, and so forth). I don't think we've got anyone available to do that yet this time around, and we probably need someone. Volunteers might like to work on getting something organised on the -testing list. We also probably need some documentation people. At the very least, we need someone (ideally someone*s*) to write and collate release notes. [1]. Volunteers probably should join the debian-doc list and the debian-boot list and work out how to hack on the release documentation. So, hopefully that doesn't raise too many more questions than it answers. In the next few weeks, the most important things to do is make sure your (and others') packages are basically how you want them to look when they're released. So, file bugs, ask for help, work on patches, upload fixes, and work on boot-floppies. Have I mentioned you should help out with boot-floppies? Cheers, aj [0] Not that I'm trying to imply that all members of the press would be low-brow enough to have mail readers that use HTML. Heaven forbid. Would you like to hear about Debian's Secret Plan to Fight Inflation? [1] It'd probably also be nice if someone'd write a testing/freeze FAQ too, since there're probably going to be a fair few (as though there aren't already). Hopefully we won't have to do much reinventing next release, so it should last a little while at least. Ideally someone other than me should write it, since I've been working on testing and thinking about how a release should go for a year, so I've forgotten half the assumptions I've made and so on... -- Anthony Towns <ajt@debian.org> Woody Release Manager
Attachment:
pgpZenlwpF7Pf.pgp
Description: PGP signature