<h1>Linux stable releases</h1>
<ul>
<li>
- Linus releases a 'stable' 3.<var>x</var> every 2-3 months after
+ Linus releases a stable 3.<var>x</var> every 2-3 months after
a series of release candidates
</li>
<li>
- Greg K-H maintains a 'stable branch' for each Linus release, with
- releases numbered 3.<var>x</var>.<var>y</var>
+ Greg K-H maintains a <dfn>stable branch</dfn> for each Linus
+ release, with <dfn>stable update</dfn> releases numbered
+ 3.<var>x</var>.<var>y</var>
</li>
<li>
- Stable branch includes cherry-picked or backported changes to
- fix serious bugs and add support for new devices
+ Branch includes cherry-picked or backported changes to fix
+ serious bugs and add support for new devices
</li>
<li>
- Stable update releases roughly every 1-2 weeks, at least until
+ Updates released roughly every 1-2 weeks, at least until
3.<var>x</var>+1 is available
</li>
<li>
- A 'long-term' stable branch may be maintained by Greg or another
- developer beyond this period
+ A <dfn>longterm</dfn> stable branch may be maintained by Greg or
+ another developer beyond this period (I look after 3.2)
</li>
</ul>
</div>
<li>
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
+ meets the criteria - see
+ <a href="http://www.kernel.org/doc/Documentation/stable_kernel_rules.txt"><tt>Documentation/stable_kernel_rules.txt</tt></a>
+ </li>
+ </ul>
+</div>
+
+<div class="slide">
+ <h1>The stable update process (2)</h1>
+ <ul>
+ <li>
+ Stable branch maintainer sends pending changes to the mailing
+ list, the original authors, etc., for a time-limited period of
+ review and testing
+ <ul>
+ <li>
+ 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
+ </li>
+ <li>
+ 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
+ </li>
+ </ul>
+ </li>
+ <li>
+ All changes that passed review (and maybe some that were
+ added) are applied to the stable branch and the release is
+ tagged
+ </li>
+ <li>
+ Greg pushes the tag to kernel.org (possibly after pulling
+ from the other maintainer) which generates tarballs,
+ updates the front page, etc.
+ </li>
+ <li>
+ Maintainer announces the release, shortly followed by LWN
+ and other news media
+ </li>
+ </ul>
+</div>
+
+<div class="slide">
+ <h1>Distributions and stable updates</h1>
+ <ul>
+ <li>
+ Package maintainers want to get bug fixes without waiting for
+ the next release - particularly for security
+ </li>
+ <li>
+ Maintainers report bugs upstream, find and sometimes write
+ fixes, and stable updates are a way to share these fixes across
+ distributions
<ul>
<li>
- See
- <a href="http://www.kernel.org/doc/Documentation/stable_kernel_rules.txt"><tt>Documentation/stable_kernel_rules.txt</tt></a>
+ Are you doing this? If not, what's stopping you?
</li>
</ul>
</li>
+ <li>
+ Distribution stable releases have a much longer support period
+ than kernel release cycle, but updating to every new Linus
+ release is too risky
+ </li>
+ <li>
+ So the longterm stable branches are very important for most
+ distributions with stable releases
+ </li>
</ul>
</div>