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       Stable branch maintainer sends pending changes to the mailing
 115       list, the original authors, etc., for a time-limited period of
 116       review and testing
 117       <ul>
 118         <li>
 119           Although the changes have been accepted by Linus, some might
 120           not be needed in a stable branch or might not work due to
 121           missing dependencies
 122         </li>
 123         <li>
 124           A fix might have been found to introduce a regression in
 125           mainline, so should only be applied to the stable branch
 126           along with a second fix for the regression
 127         </li>
 128       </ul>
 129     </li>
 130     <li>
 131       All changes that passed review (and maybe some that were
 132       added) are applied to the stable branch and the release is
 133       tagged
 134     </li>
 135     <li>
 136       Greg pushes the tag to kernel.org (possibly after pulling
 137       from the other maintainer) which generates tarballs,
 138       updates the front page, etc.
 139     </li>
 140     <li>
 141       Maintainer announces the release, shortly followed by LWN
 142       and other news media
 143     </li>
 144   </ul>
 145 </div>
 146
 147 <div class="slide">
 148   <h1>Distributions and stable updates</h1>
 149   <ul>
 150     <li>
 151       Package maintainers want to get bug fixes without waiting for
 152       the next release - particularly for security
 153     </li>
 154     <li>
 155       Maintainers report bugs upstream, find and sometimes write
 156       fixes, and stable updates are a way to share these fixes across
 157       distributions
 158       <ul>
 159         <li>
 160           Are you doing this?  If not, what's stopping you?
 161         </li>
 162       </ul>
 163     </li>
 164     <li>
 165       Distribution stable releases have a much longer support period
 166       than kernel release cycle, but updating to every new Linus
 167       release is too risky
 168     </li>
 169     <li>
 170       So the longterm stable branches are very important for most
 171       distributions with stable releases
 172     </li>
 173   </ul>
 174 </div>
 175
 176 <div class="slide">
 177   <h1>Coordinating longterm branches</h1>
 178   <ul>
 179     <li>
 180       Linux 2.6.32 was chosen as the basis for RHEL 6, and other
 181       distributions preparing a stable release in 2010 opted to do
 182       the same
 183     </li>
 184     <li>
 185       The 2.6.32.<var>y</var> longterm branch is the basis for kernel
 186       packages in Debian 6.0, SLE11 SP1 and Ubuntu 10.04 LTS and
 187       has over 3,500 changes
 188     </li>
 189     <li>
 190       Other longterm branches have not been quite as widely used or as
 191       active - maybe because release schedules didn't align as well
 192     </li>
 193     <li>
 194       Do package maintainers expect/want there to be a longterm stable
 195       branch for the kernel version in a stable release?
 196     </li>
 197     <li>
 198       Should we be coordinating more explicitly to ensure that this
 199       happens?
 200     </li>
 201     <li>
 202       Would you be prepared to maintain such a branch at kernel.org?
 203     </li>
 204   </ul>
 205 </div>
 206
 207 <div class="slide">
 208   <h1>Credits</h1>
 209   <ul>
 210     <li>
 211       Linux 'Tux' logo &copy; Larry Ewing, Simon Budig.
 212       <!--
 213 Redistribution is free but has to include this notice.
 214       -->
 215     </li>
 216   </ul>
 217 </div>
 218
 219 </div>
 220
 221 </body>
 222 </html>