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, or a fix for a stable-only
regression, can be nominated by mail to this list, if it
meets the criteria - see
Documentation/stable_kernel_rules.txt
The stable update process (2)
Stable branch maintainer sends pending changes to the mailing
list, the original authors, etc., for a time-limited period of
review and testing
Although the changes have been accepted by Linus, some might
not be needed in a stable branch or might not work due to
missing dependencies
A fix might have been found to introduce a regression in
mainline, so should only be applied to the stable branch
along with a second fix for the regression
All changes that passed review (and maybe some that were
added) are applied to the stable branch and the release is
tagged
Greg pushes the tag to kernel.org (possibly after pulling
from the other maintainer) which generates tarballs,
updates the front page, etc.
Maintainer announces the release, shortly followed by LWN
and other news media
Distributions and stable updates
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