X-Git-Url: https://git.decadent.org.uk/gitweb/?p=stable-kernel-talk.git;a=blobdiff_plain;f=index.html;h=52567ff3a3d1fa33775c68576aa06d75f2ae0c71;hp=8a48acef7d6682bb11c15a0a844fc25d1ad31598;hb=929759125f4548474dbaff7a33a1a79265b502f9;hpb=060f501eceefb6841344bb3795a1e74757d5e6d6
diff --git a/index.html b/index.html
index 8a48ace..52567ff 100644
--- a/index.html
+++ b/index.html
@@ -56,24 +56,25 @@
Linux stable releases
-
- Linus releases a 'stable' 3.x every 2-3 months after
+ Linus releases a stable 3.x every 2-3 months after
a series of release candidates
-
- Greg K-H maintains a 'stable branch' for each Linus release, with
- releases numbered 3.x.y
+ Greg K-H maintains a stable branch for each Linus
+ release, with stable update releases numbered
+ 3.x.y
-
- Stable branch includes cherry-picked or backported changes to
- fix serious bugs and add support for new devices
+ Branch includes cherry-picked or backported changes to fix
+ serious bugs and add support for new devices
-
- Stable update releases roughly every 1-2 weeks, at least until
+ Updates released roughly every 1-2 weeks, at least until
3.x+1 is available
-
- A 'long-term' stable branch may be maintained by Greg or another
- developer beyond this period
+ A longterm stable branch may be maintained by Greg or
+ another developer beyond this period (I look after 3.2)
@@ -96,14 +97,106 @@
Any commit in Linus's tree, or a fix for a stable-only
regression, can be nominated by mail to this list, if it
- meets the criteria
+ meets the criteria - see
+ Documentation/stable_kernel_rules.txt
+
+
+
+
+
+
The stable update process (2)
+
+ -
+ Stable branch maintainer sends pending changes to the mailing
+ list, the original authors, etc., for a time-limited period of
+ review and testing
-
- See
- Documentation/stable_kernel_rules.txt
+ Although the changes have been accepted by Linus, some might
+ not be needed in a stable branch or might not work due to
+ missing dependencies
+
+ -
+ A fix might have been found to introduce a regression in
+ mainline, so should only be applied to the stable branch
+ along with a second fix for the regression
+ -
+ All changes that passed review (and maybe some that were
+ added) are applied to the stable branch and the release is
+ tagged
+
+ -
+ Greg pushes the tag to kernel.org (possibly after pulling
+ from the other maintainer) which generates tarballs,
+ updates the front page, etc.
+
+ -
+ Maintainer announces the release, shortly followed by LWN
+ and other news media
+
+
+
+
+
+
Distributions and stable updates
+
+ -
+ Package maintainers want to get bug fixes without waiting for
+ the next release - particularly for security
+
+ -
+ Maintainers report bugs upstream, find and sometimes write
+ fixes, and stable updates are a way to share these fixes across
+ distributions
+
+ -
+ Are you doing this? If not, what's stopping you?
+
+
+
+ -
+ Distribution stable releases have a much longer support period
+ than kernel release cycle, but updating to every new Linus
+ release is too risky
+
+ -
+ So the longterm stable branches are very important for most
+ distributions with stable releases
+
+
+
+
+
+
Coordinating longterm branches
+
+ -
+ Linux 2.6.32 was chosen as the basis for RHEL 6, and other
+ distributions preparing a stable release in 2010 opted to do
+ the same
+
+ -
+ The 2.6.32.y longterm branch is the basis for kernel
+ packages in Debian 6.0, SLE11 SP1 and Ubuntu 10.04 LTS and
+ has over 3,500 changes
+
+ -
+ Other longterm branches have not been quite as widely used or as
+ active - maybe because release schedules didn't align as well
+
+ -
+ Do package maintainers expect/want there to be a longterm stable
+ branch for the kernel version in a stable release?
+
+ -
+ Should we be coordinating more explicitly to ensure that this
+ happens?
+
+ -
+ Would you be prepared to maintain such a branch at kernel.org?
+