Browse files

longterm future text

  • Loading branch information...
1 parent 77c74d5 commit 536033a17ffdf6ae908cbbc43ed88a390e3a5f69 @gregkh committed Aug 12, 2011
Showing with 75 additions and 0 deletions.
  1. +75 −0 longterm-future.txt
75 longterm-future.txt
@@ -0,0 +1,75 @@
+Future of the -longterm kernel releases.
+.16 became a "longterm" kernel because my day job (at SUSE) picked the
+2.6.16 kernel for its "enterprise" release and it made things a lot
+easier for me to keep working at applying bugfixes and other stable
+patches to it to make my job simpler (applying a known-good bunch of
+patches in one stable update was easier than a set of smaller patches
+that were only tested by a smaller group of people.)
+Seeing that this worked well, a cabal of developers got together at a
+few different Linux conferences and determined that based on their
+future distro release cycles, we could all aim for standardizing on the
+.32 kernel, saving us all time and energy in the long run. We turned
+around and planted the proper seeds within the different organizations
+and low-and-behold, project managers figured that this was their idea
+and sold it to the rest of the groups and made it happen. Right now all
+of the major "enterprise" and "stable" distro releases are based on the
+.32 kernel, making this trial a huge success.
+Last year, two different community members (Andi and Paul) asked me
+if they could maintain the 2.6.34 and 2.6.35 kernels as -longterm kernel
+releases as their companies needed this type of support. I agreed, and
+they have done a great job at this, but it doesn't seem that any other
+groups other than their individual companies are using these kernels.
+Now that .32 is over a year and a half, and the enterprise distros are
+off doing their thing with their multi-year upgrade cycles, there's no
+real need from the distros for a new longterm kernel release. But it
+turns out that the distros are not the only user of the kernel, other
+groups and companies have been approaching me over the past year, asking
+how they could pick the next longterm kernel, or what the process is in
+determining this.
+To keep this all out in the open, let's figure out what to do here.
+Consumer devices have a 1-2 year lifespan, and want and need the
+experience of the kernel community maintaining their "base" kernel for
+them. There is no real "enterprise" embedded distro out there from what
+I can see. montaVista and WindRiver have some offerings in this area, but
+they are not that widely used and are usually more "deep embedded".
+There's also talk that the CELF group and Linaro are wanting to do
+something on a "longterm" basis, and are fishing around for how to
+properly handle this with the community to share the workload. Android
+also is another huge player here, upgrading their kernel every major
+release, and they could use the support of a longterm kernel as well.
+Here's a first cut at a proposal, let me know if you like it, hate it,
+would work for you and your company, or not at all:
+- a new -longterm kernel is picked every year.
+- a -longterm kernel is maintained for 2 years and then dropped.
+- -stable kernels keep the same schedule that they have been (dropping
+ the last one after a new release happens.) These releases are best
+ for products that require new hardware updates (desktop distros,
+ community distros, fast-moving embedded distros (like Yocto)).
+This means that there are 2 -longterm kernels being maintained at the
+same time, and one -stable kernel. I'm volunteering to do this work, as
+it's pretty much what I'm doing today anyway, and I have all of the
+scripts and workflow down.
+Public Notifications:
+The current site doesn't properly show what is and is not
+being maintained as a -stable and -longterm kernel. I have a proposal
+for how to fix this involving 'git notes', I just need to sit down and
+do the work with the admins to get this running properly.

0 comments on commit 536033a

Please sign in to comment.