Add questions prompt
[stable-kernel-talk.git] / 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>