Occasional regression fix in stable without a corresponding
commit in Linus's tree, because the change that regressed was
OK in mainline
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
Coordinating longterm branches
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?