index.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   2         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   3
   4 <html xmlns="http://www.w3.org/1999/xhtml">
   5
   6 <head>
   7 <title>Stable kernel maintenance for distributions - FOSDEM 2013</title>
   8 <!-- metadata -->
   9 <meta name="generator" content="S5" />
  10 <meta name="author" content="Ben Hutchings" />
  11 <!-- configuration parameters -->
  12 <meta name="defaultView" content="slideshow" />
  13 <meta name="controlVis" content="hidden" />
  14 <!-- style sheet links -->
  15 <link rel="stylesheet" href="s5-blank/ui/default/slides.css" type="text/css" media="projection" id="slideProj" />
  16 <link rel="stylesheet" href="s5-blank/ui/default/outline.css" type="text/css" media="screen" id="outlineStyle" />
  17 <link rel="stylesheet" href="s5-blank/ui/default/print.css" type="text/css" media="print" id="slidePrint" />
  18 <link rel="stylesheet" href="s5-blank/ui/default/opera.css" type="text/css" media="projection" id="operaFix" />
  19 <style type="text/css">
  20   .logo { position: absolute; right: 0; top: 0; height: 100% }
  21   table { border-collapse: collapse }
  22   th { border-bottom: 2pt solid black }
  23   th, td { padding: 0 6pt }
  24   .package { font-family: monospace }
  25   var { font-family: sans }
  26 </style>
  27 <style type="text/css" media="print">
  28   .slide { page-break-after: always }
  29 </style>
  30 <!-- S5 JS -->
  31 <script src="s5-blank/ui/default/slides.js" type="text/javascript"></script>
  32 </head>
  33 <body>
  34
  35 <div class="layout">
  36 <div id="controls"><!-- DO NOT EDIT --></div>
  37 <div id="currentSlide"><!-- DO NOT EDIT --></div>
  38 <div id="header"></div>
  39 <div id="footer">
  40 <h1>FOSDEM 2013</h1>
  41 <h2>Stable kernel maintenance for distributions</h2>
  42 </div>
  43
  44 </div>
  45
  46 <div class="presentation">
  47
  48 <div class="slide">
  49 <h1>Stable kernel maintenance for distributions</h1>
  50 <object data="tux.svg" width="35%" align="right"></object>
  51 <h3>Ben Hutchings</h3>
  52 </div>
  53
  54
  55 <div class="slide">
  56   <h1>Linux stable releases</h1>
  57   <ul>
  58     <li>
  59       Linus releases a stable 3.<var>x</var> every 2-3 months after
  60       a series of release candidates
  61     </li>
  62     <li>
  63       Greg K-H maintains a <dfn>stable branch</dfn> for each Linus
  64       release, with <dfn>stable update</dfn> releases numbered
  65       3.<var>x</var>.<var>y</var>
  66     </li>
  67     <li>
  68       Branch includes cherry-picked or backported changes to fix
  69       serious bugs and add support for new devices
  70     </li>
  71     <li>
  72       Updates released roughly every 1-2 weeks, at least until
  73       3.<var>x</var>+1 is available
  74     </li>
  75     <li>
  76       A <dfn>longterm</dfn> stable branch may be maintained by Greg or
  77       another developer beyond this period (I look after 3.2)
  78     </li>
  79   </ul>
  80 </div>
  81
  82 <div class="slide">
  83   <h1>The stable update process (1)</h1>
  84   <ul>
  85     <li>
  86       All changes go to mailing
  87       list <a href="mailto:stable@vger.kernel.org">stable@vger.kernel.org</a>
  88     </li>
  89     <li>
  90       A commit with a <tt>Cc:</tt> pseudo-header for this address will
  91       be picked up by stable maintainers once Linus pulls the commit
  92     </li>
  93     <li>
  94       If it doesn't apply to a stable branch, the author is usually
  95       notified and may provide a backported version
  96     </li>
  97     <li>
  98       Any commit in Linus's tree can be nominated by mail to this list, if it
  99       meets the criteria - see
 100       <a href="http://www.kernel.org/doc/Documentation/stable_kernel_rules.txt"><tt>Documentation/stable_kernel_rules.txt</tt></a>
 101     </li>
 102     <li>
 103       Occasional regression fix in stable without a corresponding
 104       commit in Linus's tree, because the change that regressed was
 105       OK in mainline
 106     </li>
 107   </ul>
 108 </div>
 109
 110 <div class="slide">
 111   <h1>The stable update process (2)</h1>
 112   <ul>
 113     <li>
 114       Maintainer sends pending changes to mailing list, original
 115       authors, etc., for time-limited review and testing
 116       <ul>
 117         <li>
 118           Fix might not be needed in a stable branch, or might not
 119           work due to missing dependencies
 120         </li>
 121         <li>
 122           Fix might have been found to introduce a regression in
 123           mainline, so must wait until second fix available
 124         </li>
 125       </ul>
 126     </li>
 127     <li>
 128       Maintainer drops/adds changes based on review, then applies
 129       to stable branch and tags release
 130     </li>
 131     <li>
 132       Greg pushes tag to kernel.org (possibly after pulling from
 133       another maintainer) which generates tarballs, updates the front
 134       page, etc.
 135     </li>
 136     <li>
 137       Maintainer announces the release, shortly followed by LWN
 138       and other news media
 139     </li>
 140   </ul>
 141 </div>
 142
 143 <div class="slide">
 144   <h1>Distributions and stable updates</h1>
 145   <ul>
 146     <li>
 147       Package maintainers want to get bug fixes without waiting for
 148       the next release - particularly for security
 149     </li>
 150     <li>
 151       Maintainers report bugs upstream, find and sometimes write
 152       fixes, and stable updates are a way to share these fixes across
 153       distributions
 154       <ul>
 155         <li>
 156           Are you doing this?  If not, what's stopping you?
 157         </li>
 158       </ul>
 159     </li>
 160     <li>
 161       Distribution stable releases have a much longer support period
 162       than kernel release cycle, but updating to every new Linus
 163       release is too risky
 164     </li>
 165     <li>
 166       So the longterm stable branches are very important for most
 167       distributions with stable releases
 168     </li>
 169   </ul>
 170 </div>
 171
 172 <div class="slide">
 173   <h1>Coordinating longterm branches</h1>
 174   <ul>
 175     <li>
 176       Linux 2.6.32 was chosen as the basis for RHEL 6, and other
 177       distributions preparing a stable release in 2010 opted to do
 178       the same
 179     </li>
 180     <li>
 181       The 2.6.32.<var>y</var> longterm branch is the basis for kernel
 182       packages in Debian 6.0, SLE11 SP1 and Ubuntu 10.04 LTS and
 183       has over 3,500 changes
 184     </li>
 185     <li>
 186       Other longterm branches have not been quite as widely used or as
 187       active - maybe because release schedules didn't align as well
 188     </li>
 189     <li>
 190       Do package maintainers expect/want there to be a longterm stable
 191       branch for the kernel version in a stable release?
 192     </li>
 193     <li>
 194       Should we be coordinating more explicitly to ensure that this
 195       happens?
 196     </li>
 197     <li>
 198       Would you be prepared to maintain such a branch at kernel.org?
 199     </li>
 200   </ul>
 201 </div>
 202
 203 <div class="slide">
 204   <h1>Questions?</h1>
 205   <p>
 206     The FAQ is
 207     <a href="http://www.kernel.org/doc/Documentation/stable_kernel_rules.txt"><tt>Documentation/stable_kernel_rules.txt</tt></a>
 208   </p>
 209 </div>
 210
 211 <div class="slide">
 212   <h1>Credits</h1>
 213   <ul>
 214     <li>
 215       Linux 'Tux' logo &copy; Larry Ewing, Simon Budig.
 216       <!--
 217 Redistribution is free but has to include this notice.
 218       -->
 219     </li>
 220   </ul>
 221 </div>
 222
 223 </div>
 224
 225 </body>
 226 </html>