Debian decides to adopt time-based release freezes

This is great, except I wish it was one year.<p>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.

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.

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

How about not freezing the vast majority of packages <i>at all</i>?<p>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.<p>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 <i>ridiculously stupid</i> to freeze Firefox that way.

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:<p><a href="http://modeemi.fi/~tuomov/b/archives/2007/03/03/T19_15_26/" rel="nofollow">http://modeemi.fi/~tuomov/b/archives/2007/03/03/T19_15_26/</a>