Add questions prompt

[stable-kernel-talk.git] / index.html

diff --git a/index.html b/index.html
index c60f3c5864facf35a2fe911ccd751a20a0ac18b8..9dd36d429cfa48c6ff6d4f99e7a813d8377dd7db 100644 (file)
--- a/index.html
+++ b/index.html
@@ -95,11 +95,15 @@
       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
+      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>
 
@@ -107,31 +111,27 @@
   <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
+      Maintainer sends pending changes to mailing list, original
+      authors, etc., for time-limited 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
+         Fix 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
+         Fix might have been found to introduce a regression in
+         mainline, so must wait until second fix available
        </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
+      Maintainer drops/adds changes based on review, then applies
+      to stable branch and tags release
     </li>
     <li>
-      Greg pushes the tag to kernel.org (possibly after pulling
-      from the other maintainer) which generates tarballs,
-      updates the front page, etc.
+      Greg pushes tag to kernel.org (possibly after pulling from
+      another maintainer) which generates tarballs, updates the front
+      page, etc.
     </li>
     <li>
       Maintainer announces the release, shortly followed by LWN
@@ -169,6 +169,45 @@
   </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>
+
 <div class="slide">
   <h1>Credits</h1>
   <ul>