Rationale for pushing back the freeze (Score 1)

Anyone who's been watching Debian for more than 1 year knows that freeze time is a huge strain on the project. The release manager, Richard Braakman, has stated his wish that the complete duration of the freeze should be no greater than 3 or four weeks.

My discussion with him regarding the preparedness of the boot-floppies, in particular, is just to make sure he has all the information he needs to make this wish into a reality. The whole point is to go into the freeze with a feature-complete and beta-ready installation system; with that in place, a 4 week freeze is plausible. Without it, it's not. For those who remember the slink freeze, that was about a 16 week cycle (it froze in mid-Nov, release in mid-March), and was quite stressful to all. Our goals is that freeze is predicated on a pretty stable set of packages, which makes our own ability to test installation from scratch and slink to potato upgrading in a more sane fashion.

Let me just cover a few other points, quickly.

• The main reason why I want more time for boot-floppies features to go in is that I feel these features are very important. Let me mention them briefly: a new task/profile selection mechanism, with the means to continue to use these mechanisms even after installation; use of apt in almost all cases; an apt configurator, with the capability to autosense official cdroms in expected locations; ability to install base2_2.tgz via http and maybe ftp; bootp/dhcp network data population when available; X package installation hand-holder, able to autosense your correct X server package. I feel these advances are important. Even with the delay, I hope we have time to implement them.
• Those who say we'll never freeze are just talking crazy. We have a lot of desire to update and obsolete the slink distribution.
• Regarding Linux 2.4, no, we do not plan release cycles around Linux release cycles, which should be clear to anyone. For better or worse. Assuming Linux 2.4 is stable (2.2 wasn't that great w.r.t. stability when it came out, IMHO) and comes out in the next couple of weeks, I wouldn't rule out 2.4 for sure. Right now, we're planning on using 2.2.13 (although that can very for our 5 different architectures).
• We do realize that the current release engineering mechanisms are showing the strain of how large the project has grown. There are two approaches to this problem: (a) do more "point releases" of the stable system, which simply requires a larger team than we currently have worrying about stable even after it's released; (b) radically reengineer release management, where the most likely candidate for this is the "package pool" proposal -- I don't have the URL offhand.
• Even with all that being said, I'd like to reiterate that, AFAIK, Debian is the only distribution with a proven and robust way to upgrade your distribution (whether it's for new releases, picking packages out of unstable, or whatever).
• While we're in the "excuses" department, I don't think there are many out there that realize how much effort it is to coordinate Debian in general (or boot-floppies, for that matter). This work goes on behind the scenes, and some of you interpret the slow-moving nature of these issues to indifference. I can assure you we are not indifferent, especially to the criticisms regaring frequency of release and the quality of the boot-floppies.

I'd like to thank all of you who have expressed support and tolerance for Debian here.

.....Adam Di [e-mail].....http://www.onShore.c om/