X-Git-Url: https://git.decadent.org.uk/gitweb/?p=stable-kernel-talk.git;a=blobdiff_plain;f=index.html;h=c303bf1b97fee0c165b555b3e4be53c6fda63c19;hp=8a48acef7d6682bb11c15a0a844fc25d1ad31598;hb=977f69564879aa552520e559b3327909ede37125;hpb=060f501eceefb6841344bb3795a1e74757d5e6d6

diff --git a/index.html b/index.html
index 8a48ace..c303bf1 100644
--- a/index.html
+++ b/index.html
@@ -56,24 +56,25 @@
   <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>
@@ -94,16 +95,112 @@
       notified and may provide a backported version
     </li>
     <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
+      Any commit in Linus's tree can be nominated by mail to this list, if it
+      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>
+    <li>
+      Occasional regression fix in stable without a corresponding
+      commit in Linus's tree, because the change that regressed was
+      OK in mainline
+    </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>
-	  See
-	  <a href="http://www.kernel.org/doc/Documentation/stable_kernel_rules.txt"><tt>Documentation/stable_kernel_rules.txt</tt></a>
+	  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>
+	  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>