

Debian decides to adopt time-based release freezes - JeremyChase
http://www.debian.org/News/2009/20090729

======
ars
This is great, except I wish it was one year.

After about 1 year I start having a significant number of packages from
testing, and it gets more and more troublesome. In particular security updates
become hard to separate from the usual churn of testing. And most of the
packages from testing are not even packages I want, but rather dependencies
pulled in automatically.

~~~
davidw
As I alluded to below, I think with that large a project, that's done almost
entirely by volunteers, one year just isn't enough turnaround.

~~~
wglb
But OpenBSD does it on a six month basis. I am wondering if it is more the
degree of organization and planning rather than the size of the project.

~~~
mahmud
I seriously doubt that OpenBSD has as many packages, with as much
documentation, localization, on as many platforms as debian does. Debian is
HUGE; and don't you forget the million other more specialized debianish
distros that feed off of it.

~~~
smithjchris
This is correct. They also manage the core of the OS without all the nasty
package interdependencies you get with Debian.

Debian does too much. That is the issue if you ask me.

~~~
rcoder
Debian only "does too much" if what you want from an OS is a simple platform
on which to build your own bespoke solution. The BSD operating systems, and
OpenBSD in particular, abdicate a lot more responsibility for actual system
management and application deployment to the sysadmin, while Debian provides
opinionated defaults (in the form of package install layouts and configuration
styles) that work for most environments.

Both have their place, but for general-purpose servers, I find Debian to be a
much more productive system on top of which to build solutions. For firewalls,
embedded storage devices, or load balancers, on the other hand, I still reach
for a recent OpenBSD install disk, because the smaller footprint and security
hardening have real advantages for systems running such a limited set of
services.

------
davidw
Great news, and about time. I am not sure about a two year cycle though...
that might be a bit too long for what I want as a user. But with such a big
project, anything shorter might be difficult to accomplish, too. Anyway, it's
a welcome direction: it's difficult to base things on a system that's not
predictable.

~~~
JeremyChase
Historically, they have released almost every two years anyway. Potato and
Woody are the only exceptions (1 year and 3 years). So it makes sense to me to
shift it.

[http://www.debian.org/doc/manuals/project-history/ch-
release...](http://www.debian.org/doc/manuals/project-history/ch-
releases.en.html)

~~~
davidw
Sure, but stating that as a goal is quite different from "have mostly done
so".

------
mariana
Not all Debian developers agree with this "decision" anyway. They are right
now discussing it. See: <http://lists.debian.org/debian-
project/2009/07/msg00148.html>

------
blasdel
How about not freezing the vast majority of packages _at all_?

A huge amount of their effort is spent doing pointless crap like freezing
versions of 10,000 end-user software packages, and backporting updates with
the features stripped out.

It's totally reasonable to freeze versions of the kernel, glibc, xorg, dbus,
etc. every 18 months or so. It makes some sense to regularly freeze heavily-
interdependent meta-packages like Gnome or KDE, since their release model
matches up. It's _ridiculously stupid_ to freeze Firefox that way.

------
artificer
Looks like a nice decision, however I also feel that Debian's problem is the
huge freeze of thousands of packages, making the 'stable' ('stale' is better
for some) distribution out of date quickly while adding a large burden to it's
developers and maintainers. This blog post by the author of Ion window manager
sums it all up better than I could:

<http://modeemi.fi/~tuomov/b/archives/2007/03/03/T19_15_26/>

