Fill in brief overview of Linux release model

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

diff --git a/index.html b/index.html
index 546aa047b0752efc8449c7b80e70e048d6f4fde5..2f131ff8efefb492e1b58abf8f500addf50d4b97 100644 (file)
--- a/index.html
+++ b/index.html
@@ -111,7 +111,63 @@
 </div>
 
 <div class="slide">
-  <h1>Linux release model</h1>
+  <h1>Linux release model (1)</h1>
+  <p>
+    The old model:
+  </p>
+  <ul class="incremental">
+    <li>
+      Each stable release had even second component.  Bug fixes and
+      minor features in stable releases with third component
+      incremented (e.g. 2.4.27)
+    </li>
+    <li>
+      Major development done separately, resulting in series of
+      unstable releases with odd second component (e.g. 2.5.50)
+    </li>
+    <li>
+      After a year or two, development resulted in a new stable
+      release
+    </li>
+    <li>
+      Problem: users waited years for new features, and then got many
+      more changes all at once.  Particularly bad in the 2.4-2.6
+      transition.
+    </li>
+  </ul>
+</div>
+
+<div class="slide">
+  <h1>Linux release model (2)</h1>
+  <p>
+    The new model:
+  </p>
+  <ul class="incremental">
+    <li>
+      Development results in a new stable(-ish) release every 2-3
+      months
+      <ul class="incremental">
+       <li>
+         git (and previously BitKeeper) made distributed development
+          and testing a lot easier
+       </li>
+      </ul>
+    </li>
+    <li>
+      Each 2.6.<var>x</var> release has stable update branch; releases
+      numbered 2.6.<var>x</var>.<var>y</var>
+      <ul class="incremental">
+       <li>
+         Usually closed shortly after next stable release, but may
+         continue as a 'longterm' branch (e.g. 2.6.32.<var>y</var>)
+       </li>
+      </ul>
+    </li>
+    <li>
+      Linux 3.0 doesn't change this, except that <var>x</var> is now
+      the second component and <var>y</var> is the third
+    </li>
+  </ul>
 </div>
 
 <div class="slide">