Debian Weekly News - email

October GNOME for Debian:

-- Vincent Renardias <> Fri, 5 Nov 1999 17:44:03 +0100
Subject: Adam Di Carlo's Rationale (was Re: FREEZE RESCHEDULED)
References: <> <> <> <> <>
From: Adam Di Carlo <>
Date: 08 Nov 1999 21:26:14 -0500

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<URL:>

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

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.

Date: Tue, 9 Nov 1999 07:23:23 +1100
From: Chris Leishman <>
Subject: Partial freeze?


Here is another thought (probably one that has come up before - gotta love
going around in circles.  Let me know if I am).

The problem at the moment is that no-one wants to freeze, because we don't
know how long we will be frozen for - and in that time things get stale and
old.  And why don't we know how long we will be frozen for?  Because some
"critical to release" packages (like boot-floppies) are not stable and we don't
know how long they will take to become so.

However - IMHO if we don't freeze, then we are in the same position as
unstable always is - at any point there can be an update that will cause a
different "critical to release" package to fail.  Who knows - in a month when
we have boot-floppies working, some other new or updated package might (or
new policy) might still prevent us from freezing for the same reasons..

Bit of a catch 22 really.  If we freeze, then things can stabilise, but they
might also get stale.  If we don't, then things won't get stale, but they may
not stabilise quickly.

How about this then:  We identify those packages which are considered
"critical to release".  This would include packages like boot-floppies and
policy.  Then we declare a _freeze on those packages_.  The same freeze rules
apply - only bug fixes to these packages allowed.

However, new uploads can continue while this stuff stabilises - as long as
they don't cause problems with the "critical to release" packages.  If they
do, then the freeze rules apply to that upload (no new code).

Eventually we freeze the whole distribution for a very short time to clean
release critical bugs in non-core packages.  We should take a fairly hard line
on these, and basically say that if there was a version without _new code_
that didn't exhibit the problem, we backdate to it rather than bugfix.

Ok..conclusions from this idea... This _may_ lengthen the freeze time, since
we are effectively doing 2 freezes.  But the second phase (the phase that can
introduce stagnation) will be much shorter than it is in our current situation.

Another conclusion may be that this just sounds like common sence, and there
is no need to make it official...but I've always found these things work much
better when they are enforced.

The last remaining question is how workable this concept is....

Best regards,


(wish me well for my macroeconomics exam in...oh...1 1/2 hours :)

            Linux, because I'd like to *get there* today
Reply with subject 'request key' for GPG public key.  KeyID 0xB4E24219

Subject: New members of the archive maintenance team
From: James Troup <>
Date: 09 Nov 1999 00:41:51 +0000

Hash: SHA1

[ Please don't reply to debian-devel-announce ]


I'd like to publicly welcome Gergely Madarasz and Antti-Juhani
Kaijanaho who are joining Guy, Richard and I as members of the archive
maintenance team.

Even though we originally only asked for one person to help, we
decided to take on two new members due to the number of NEW packages
being uploaded every day.

Thank you to everyone else who kindly volunteered their help.

- --
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.4 and Gnu Privacy Guard <>


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 Joey Hess.