+<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>
+ 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>
+
+<div class="slide">
+ <h1>Coordinating longterm branches</h1>
+ <ul>
+ <li>
+ 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
+ </li>
+ <li>
+ The 2.6.32.<var>y</var> 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
+ </li>
+ <li>
+ Other longterm branches have not been quite as widely used or as
+ active - maybe because release schedules didn't align as well
+ </li>
+ <li>
+ Do package maintainers expect/want there to be a longterm stable
+ branch for the kernel version in a stable release?
+ </li>
+ <li>
+ Should we be coordinating more explicitly to ensure that this
+ happens?
+ </li>
+ <li>
+ Would you be prepared to maintain such a branch at kernel.org?
+ </li>
+ </ul>
+</div>
+
+<div class="slide">
+ <h1>Questions?</h1>
+ <p>
+ The FAQ is
+ <a href="http://www.kernel.org/doc/Documentation/stable_kernel_rules.txt"><tt>Documentation/stable_kernel_rules.txt</tt></a>
+ </p>
+</div>
+