However, all that being said, there would still be the choosing of*more omitted*
someone, steady and capable, of holding on to the stable release and
being it's gate-keeper. It seems like it would become quite a chore
to decide what code is let into the stable version. It's also
considered by many to be "less" fun, not only to "manage the
stable distro", but backport code into the previous distro. Maybe no one _qualified_, wanted to manage a stable release. It takes time and possibly enough time to qualify as a
full-time job. It takes a special person to find gainful
employment as a vendor-neutral kernel maintainer. The alternative is
to try to work 2 jobs where, in programming, each job might "like"
to have 60-80 hours of attention per week. That's a demanding
sacrifice as well.
It may be the case that no one at the last closed door kernel developer
meeting wanted to undertake the care of a stable kernel. No
volunteers...no kernel. There is less "wiggle room" in the average,
mature, developer's schedule with the advent of easy outsourcing to
cheaper labor that doesn't come from societies that breed independence
and nurture talented, more mature, or eccentric developers that love
spending spare cycles working on Open Source code.
Nevertheless, it would be nice to see a no-new-features, stable series
spun off from these development kernels, maybe .4th number releases,
like 2.6.10 also becomes a 2.6.10.0 that starts a 2.6.10.1, then 2.6.10.2,
etc...with iteritive bug fixes to the same kernel and no new features
in such a branch, it might become stable enough for users to have confidence
installing them on their desktop or stable machines.