Stable kernel maintenance for distributions

Linux stable releases

Linus releases a stable 3.x every 2-3 months after a series of release candidates
Greg K-H maintains a stable branch for each Linus release, with stable update releases numbered 3.x.y
Branch includes cherry-picked or backported changes to fix serious bugs and add support for new devices
Updates released roughly every 1-2 weeks, at least until 3.x+1 is available
A longterm stable branch may be maintained by Greg or another developer beyond this period (I look after 3.2)

All changes go to mailing list stable@vger.kernel.org
A commit with a Cc: pseudo-header for this address will be picked up by stable maintainers once Linus pulls the commit
If it doesn't apply to a stable branch, the author is usually notified and may provide a backported version
Any commit in Linus's tree can be nominated by mail to this list, if it meets the criteria - see Documentation/stable_kernel_rules.txt
Occasional regression fix in stable without a corresponding commit in Linus's tree, because the change that regressed was OK in mainline

Maintainer sends pending changes to mailing list, original authors, etc., for time-limited review and testing
- Fix might not be needed in a stable branch, or might not work due to missing dependencies
- Fix might have been found to introduce a regression in mainline, so must wait until second fix available
Maintainer drops/adds changes based on review, then applies to stable branch and tags release
Greg pushes tag to kernel.org (possibly after pulling from another maintainer) which generates tarballs, updates the front page, etc.
Maintainer announces the release, shortly followed by LWN and other news media

Package maintainers want to get bug fixes without waiting for the next release - particularly for security
Maintainers report bugs upstream, find and sometimes write fixes, and stable updates are a way to share these fixes across distributions
- Are you doing this? If not, what's stopping you?
Distribution stable releases have a much longer support period than kernel release cycle, but updating to every new Linus release is too risky
So the longterm stable branches are very important for most distributions with stable releases

Linux 2.6.32 was chosen as the basis for RHEL 6, and other distributions preparing a stable release in 2010 opted to do the same
The 2.6.32.y longterm branch is the basis for kernel packages in Debian 6.0, SLE11 SP1 and Ubuntu 10.04 LTS and has over 3,500 changes
Other longterm branches have not been quite as widely used or as active - maybe because release schedules didn't align as well
Do package maintainers expect/want there to be a longterm stable branch for the kernel version in a stable release?
Should we be coordinating more explicitly to ensure that this happens?
Would you be prepared to maintain such a branch at kernel.org?