Writing a "what do you think of this proposal" type email to linux-kernel or on my blog on a Friday evening, isn't the best way to get good feedback. But, let's try an experiment here, how about I post my first thoughts here, see if I get any feedback, and then on Monday post it to a larger audience based on the response?

I'm giving a talk about this topic at LinuxCon in Vancouver next week, and have had a number of different conversations about this with different groups lately, so that is why I am thinking about it at the moment:

Latest version of this text can be found at
https://raw.github.com/gregkh/stable-presentation/master/longterm-future.txt

---------------------------------------
The future of the -longterm Linux kernel releases:

History:

2.6.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
2.6.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
2.6.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.

Today:

Now that 2.6.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.

Proposal:

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)).
- the normal -stable kernel rules apply, as documented in
Documentation/stable_kernel_rules.txt for the -longterm kernels.

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 kernel.org 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 kernel.org admins to get this running properly.

Thoughts?
Shared publiclyView activity