Adam Di Carlo's Rationale (was Re: FREEZE RESCHEDULED)
Included is a justification for the delay in freeze that I sent to the
slashdot forum. This is the first time I ever posted there, but I'm
worried about becoming the most hated person in Debian. Anyhow, I'm
posting it here in case people wanna read it.
Let me just preface this by saying that I agree with those who say
that a 2 month delayed freeze with a 1 month cycle (if we can achieve
that) is going to be better than a 3 month freeze. For the developers
here, I hope that you hold back uploading very unstable packages until
after the potato release.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
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.
[FYI, my current estimate is that we will have a feature complete
boot-floppies by Dec 1. I can state with some conviction that by 1
Jan 2000 we'll have what I'd call a "release quality" boot-floppies
(i.e., has undergone much testing; may still have documentation to be
done).]
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 [for package acquisition; yes, I know there
are cases with SOCKS proxies and other obscure situations where this
might not be a reality]; 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 as indifference. I can assure you we are not
indifferent, especially to the criticisms regaring frequency of
release and the quality of the boot-floppies.
Reply to: