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