I must wonder why Debian needs to do 10 months of developing/bugfixing software in the first place. I mean most of the software is already supposedly "stable" releases from upstream, is it not? Maybe Debian should focus on working closer to upstream developers so that the software would be more directly usable out-of-the-box.
It's not so much the individual packages, it's the interaction between them, and dependencies. In this release, we got multiarch, which is quite an overhaul in how cross-compilation works (especially relevant for running 32-bit (often binary only, non-free) software under the amd64 architecture.
There are such issues as which version of libxml, libopenssl and even glibc certain packages work with (or especially, do not work with).
So, eg nginx upstream might test (mostly) against an upstream release of openssl and some libc, while the apache web server might be more conservative (this is a made up example, tomcat, especially legacy versions such as 6, might be a better example than apache httpd).
Multiarch took so long to ship that most of the proprietary binaries are now available in 64 bit. It is still marginally useful.
The testing issue is a big problem as up streams often have poor tests but that is an upstream issue really. Maybe the best solution is to provide CI frameworks for upstream to use that support current and future Debian versions easily (something like Travis but with more OS versions).
Even so, 10 months is a bit much. If the freeze were shorter, then Debian would have newer software. Fortunately, Debian releases are made roughly every 2 years, but even when Debian ships, it's already several months behind.
This isn't a problem for most servers, but it's a definite pain for developers like myself who use newer versions of software (extreme example, I use Arch) then try to backport to whatever's in the Debian repository. Sure, newer versions of software can be installed, but that kind of defeats the purpose of running Debian in the first place.
A shorter freeze means newer software in a release, which may reduce the need/temptation to use a package not in the stable repository, which is better for everyone.
In short form: I think the turn around time is increasing because Debian has to wait for conflicting interests to settle. Solution: stop waiting for everything including the kitchen sink, and only worry about including the highest-yield and most necessary software in "stable". Let the newest desktops, for example, stay in unstable and layer them on stable (Ubuntu could be a themed faster-moving layer that could use as much of the stable core as possible). With the decreased turnaround time for stable iterations (the Debian ecosystem's "core" platform), less stable layers (derived distributions) would actually become less of a burden to develop since they would have a base they can depend on - one that isn't too far away from bleeding edge, but still solid as a rock.
In long form: I think Debian should focus on getting the slowest-moving targets and major package-management design and minimally necessary policies well before, and above, faster-moving targets like UI and experimental features, etc... This means rethinking repos with an eye towards community division of labour along lines like turnover time (some tools simply haven't changed much in 20 years), popularity/necessity (kernel support, bootloaders, libraries), and bleeding-edge version expectations (desktop). In practice, Debian is pretty monolithic. People mostly install what's in their primary repo (the walled garden problem).
In practice, IMHO, this would mostly boil down to making it easier to pull in separate repositories under one install, layering them on those provided by stable and it's official installer, and other special-purpose repositories (for example, with an distro-specific virtual package to articulate the dependencies and make upgrades/downgrades/sidegrades clear and easy). I recognize a lot of motion in related areas (blends, debian live, stuff outlined in the article, etc - and a technically savy user can modify their sources), but I think that there is more than necessary being attempted under the name "Debian Stable" and this has been distracting from "stability" (and costing effectiveness). Specifically, the fastest-moving targets should not be considered part of Debian at all, IMHO, but separate distributions along lines that maximize stakeholder ownership and improve turnover time. It then becomes necessary to allow seamless distribution (repository) layering and interdependence (something the package manager can already do, but is difficult in practice for more than a few sources, even to experienced users). In essence, the package+repo system does not currently help much with forks and merges at that level - even though it is one of the most common problems in open software development. (Git has spoiled me.)
Ideally, IMHO, all Debian-based distributions should be installable from the same installer, even if they may want to provide their own (like Ubuntu), something that would be made possible because the packaging standards would have solidified to the point that other distro-builders (repo, and special-purpose package maintainers) can rely on them (my hope for "stable").
That said, I am just another "user" who prefers things not break over them looking brand new.
