Debian decides to adopt time-based release freezes | Hacker News Reader

Debian decides to adopt time-based release freezes

debian.org

60 pointsJeremyChase14 comments

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.

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.

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.

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.

I think you are right, but still there is a discipline that openbsd uses that others might find useful. Theo gave a talk about their engineering release process that sounded scalable.

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.

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.

Each stable version of Debian is maintained for one year after the release of the next. Unless this policy changes, this means that the next releases will be supported for a minimum of three years. If the releases were yearly, as you wish, there would be only two years of security support, which would hurt precisely those users that want long term support and use Debian stable.

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.

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

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

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

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.

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/

Reply on news.ycombinator.com