Debian's 3.2 kernel includes backported support for much newer hardware from more recent kernels. Debian's primary kernel maintainer, Ben Hutchings, also serves as the upstream maintainer of the 3.2 stable kernel series.
And that I think is the biggest problem of Debian. They aim stability but how can you possibly claim that your custom backports are stable when e.g. the original developers have stopped supporting it?
They may be able to pull it off with the kernel, but they can't possibly do it for all their packages. As an example: How are the Django backports to 1.2 more stable than upgrading to 1.3 when the official Django project has stopped supporting 1.2?
Who says the original developers stopped supporting it? Head on over to http://www.kernel.org and you'll see that 3.2 has longterm support (ie the kernel developers backport relevant fixes and patches). There are more details at https://www.kernel.org/releases.html including end of life dates. Given the time span between Debian releases, 3.2 is an excellent choice, if not the only one.
Since the release of Django 1.4, version 1.2 stopped receiving security fixes by the Django development team. What that means is that a Debian maintainer (which probably is not a Django developer) would have to hack any new security fix into the unsupported 1.2. And this is deemed more stable than say, upgrading to 1.3.
Note that Django is just an example, obviously there are many more packages with the exact same problem.
If the Debian maintainer has any idea what he’s doing, then this is likely to be more stable than upgrading to a new release that introduces new features and possibly incompatibilities. Fortunately, most Debian maintainers have a very good idea of what they’re doing.
Likely yes. But if I had to choose between the original developers and someone that has to maintain 20 different packages, I will chose the original developers.
"stable" does not necessarily mean "better"; In the case of Debian, it can mean "unchanging"... that is you can rely on it to not break your software even if you keep it ("stable") updated.
Security fixes that addresses issues in 1.2 will be back-ported from 1.4 by either A) upstream, or if that fails B) the Debian maintainer, or if that also fails, C) Debian security team. Thats the promise made by The Debian security team which cover the latest stable major release, and for the prior stable release for one year.
And it works. Most of all fixes are done by A or B, but the promise is one which the security team takes very serious. For one release, the security team backported security updates for 4 years. A achievement of taking responsibility in a "open source" project if I ever saw one.
I used to be all for the way backports are handled, until I had an excruciating experience with a perl module recently (the Locale::Maketext vulnerability). 1.19 is vulnerable, so they "backported" the CVE change, without realizing that this means their franken-1.19 version is exactly the same code now as the latest 1.23. All that's different is the POD and $VERSION.
Which sucks, because application software needs to handle environments with Locale::Maketext 1.19 differently to environments with 1.23, else you get double-escaping bugs.
The response? Reporting the actual, correct module version (or god forbid, sync the comments/POD as well) instead of the incorrect, unchanged version number "would break stuff". As opposed to incorporating a breaking API change without bumping module version, which also breaks stuff... Ouch.
I guess I only have myself to blame, I should be more involved with debian maintenance of packages I care about.
That's one of the reasons why I try to get as much software from the actual developers as possible, instead of relying on packages maintained by [Debian|Ubuntu|Red Hat|...].
Obviously this is a lot of work (patches, managing dependencies, ...) if you do it for everything, but if you stick to the most important packages (e.g. nginx for your webserver, postgres for your db server, ...) I think it's manageable and will give you a lot of benefits.
(Thinking about the Debian OpenSSL fiasco a few years ago, I guess one could make an even stronger argument, though to be fair it was a pretty extreme case and I don't think anything like that has happened since back then.)
//Edit: I got curious about the OpenSSL issue from 2008 and it turns out that the Debian maintainers weren't solely responsible for the bug[0].
But Red Hat used to (they probably still do) continuously backport a lot of drivers an functionality from newer kernels to their older, stable, kernel for the first 5.5 years after a release: