+ <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">
+ <h1>Debian kernel team (1)</h1>
+ <p>
+ Who are we?
+ </p>
+ <ul class="incremental">
+ <li>
+ Currently 5 general maintainers: Maximilian Attems, Bastian
+ Blank, dann frazier, Moritz Muehlenhoff and me
+ </li>
+ <li>
+ Many more specialised contributors:
+ <ul>
+ <li>Specific architectures</li>
+ <li>Specific features (e.g. Xen)</li>
+ <li>Bug triage</li>
+ </ul>
+ </li>
+ <li>
+ Would appreciate more help, particularly with bug triage and
+ PowerPC
+ </li>
+ </ul>
+</div>
+
+<div class="slide">
+ <h1>Debian kernel team (2)</h1>
+ <p>
+ What do we do?
+ </p>
+ <ul class="incremental">
+ <li>
+ Bug triage - takes a huge amount of time
+ </li>
+ <li>
+ Backport bug fixes and features - particularly new hardware
+ support for stable
+ <ul class="incremental">
+ <li>...while trying not to change kernel ABI in stable</li>
+ </ul>
+ </li>
+ <li>
+ Update build configurations for each new upstream release -
+ e.g. to enable new drivers
+ </li>
+ <li>
+ Try to ensure smooth upgrades when there are major
+ implementation changes - e.g. KMS, switch to libata drivers
+ </li>
+ <li>
+ Integrate <em>some</em> features not accepted upstream
+ </li>
+ </ul>
+</div>
+
+<div class="slide">
+ <h1>Official Linux kernel packages (1)</h1>
+ <p>
+ Main source package is <span class="package">linux-2.6</span>
+ (still!). Most binary package names change regularly.
+ </p>
+ <ul class="incremental">
+ <li>
+ <span class="package">linux-image-<var>upstream</var>-<var>abi</var>-<var>flavour</var></span>
+ - compiled kernel and modules
+ </li>
+ <li>
+ <span class="package">linux-headers-<var>upstream</var>-<var>abi</var>-<var>flavour</var></span>
+ (and others) - development package for OOT modules
+ </li>
+ <li>
+ <span class="package">linux-libc-dev</span> - headers for userland
+ </li>
+ <li>
+ <span class="package">linux-source-<var>upstream</var></span> -
+ for custom kernels
+ </li>
+ <li>
+ <span class="package">linux-doc-<var>upstream</var></span>,
+ <span class="package">linux-tools-<var>upstream</var></span>, etc.
+ </li>
+ <li>
+ <span class="package">linux-support-<var>upstream</var>-<var>abi</var></span> -
+ scripts and metadata to support linux-latest-2.6
+ </li>
+ </ul>