X-Git-Url: https://git.decadent.org.uk/gitweb/?a=blobdiff_plain;ds=sidebyside;f=index.html;h=9dd36d429cfa48c6ff6d4f99e7a813d8377dd7db;hb=7bf4965d510f9780e8e050390559fb1e68a8450c;hp=c60f3c5864facf35a2fe911ccd751a20a0ac18b8;hpb=b2da64e45dc6520d96a82dde4cd4aa8affa695dc;p=stable-kernel-talk.git
diff --git a/index.html b/index.html
index c60f3c5..9dd36d4 100644
--- a/index.html
+++ b/index.html
@@ -95,11 +95,15 @@
notified and may provide a backported version
- Any commit in Linus's tree, or a fix for a stable-only
- regression, can be nominated by mail to this list, if it
+ Any commit in Linus's tree can be nominated by mail to this list, if it
meets the criteria - see
Documentation/stable_kernel_rules.txt
+
+ Occasional regression fix in stable without a corresponding
+ commit in Linus's tree, because the change that regressed was
+ OK in mainline
+
@@ -107,31 +111,27 @@
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
+ Maintainer sends pending changes to mailing list, original
+ authors, etc., for time-limited review and testing
-
- 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
+ Fix 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
+ Fix might have been found to introduce a regression in
+ mainline, so must wait until second fix available
-
- All changes that passed review (and maybe some that were
- added) are applied to the stable branch and the release is
- tagged
+ Maintainer drops/adds changes based on review, then applies
+ to stable branch and tags release
-
- Greg pushes the tag to kernel.org (possibly after pulling
- from the other maintainer) which generates tarballs,
- updates the front page, etc.
+ Greg pushes tag to kernel.org (possibly after pulling from
+ another maintainer) which generates tarballs, updates the front
+ page, etc.
-
Maintainer announces the release, shortly followed by LWN
@@ -169,6 +169,45 @@
+
+
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?
+
+
+
+
+
+