sed -i 's/gregkh@suse.de/gregkh@linuxfoundation.org/g' .addressbook

I thought it would be easier to do a round of stable kernel releases in the middle of the larger kernel merge window, to prevent the next round from being so big (given that there are a lot of patches usually applying during the -rc1 merge window cycle).

So, I've now done:

• Linux 2.6.32.54-rc1 release
• Linux 3.0.17-rc1 release
• Linux 3.1.9-rc1 release
• Linux 3.2.1-rc1 release

Please go test and let me know if there are any problems with any of these kernels. If I've missed any patches that you feel should be in them, also please let me know.

Note, this is most likely going to be the LAST 3.1.y kernel release, so please move off to the 3.2 kernel at this point in time. Maintaining so many different kernel branches all at once is not trivial, and I want to minimize it if at all possible.

As 3.2 is now out, here's a note as to the current status of the different stable/longterm kernel trees.

First off, please everyone remember to mark any patch that you want to have applied to the stable kernel trees with a simple:

Cc: stable <stable@vger.kernel.org>

marking in the Signed-off-by: area. Once the patch hits Linus's tree, I will automatically be notified of it and it will be applied if possible. If it does not applied, you will be notified of that.

Note that the address is stable@vger.kernel.org, not the older address that used to be used before October of 2011.

At this time, all stable and longterm kernel trees are being maintained in one big git tree, located at:

git.kernel.org:/pub/scm/linux/kernel/git/stable/linux-stable.git

There are different branches for every different major kernel version.

Here's the different active kernel versions that I am maintaining at the moment:

• 3.2.y - this will be maintained until 3.3 comes out
• 3.1.y - there will be only one, maybe two, more releases of this tree
• 3.0.y - this is the new "longterm" kernel release, it will be maintained for 2 years at the minimum by me.
• 2.6.32.y - this is the previous "longterm" kernel release. It is approaching it's end-of-life, and I think I only have another month or so doing releases of this. After I am finished with it, it might be picked up by someone else, but I'm not going to promise anything.

All other longterm kernels are being maintained in various forms (usually quite sporadically, if at all), by other people, and I can not speak for their lifetime at all, that is up to those individuals.

If anyone has any questions about any of this, please let me know.

tl;dr;

• -stable kernel releases stay the same
• this proposal is how we pick the -longterm releases
• -longterm kernels will be picked every year, and maintained for 2 years before being dropped.
• the same Documentation/stablekernelrules.txt will apply for -longterm kernels, as before.

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.

Andi reports that the 2.6.35 kernel is being used by a number of different distros, but they will be phased out as their support lifetime expires. There are also a number of embedded users of the kernel as well as some individual ones. So that -longterm kernel is having a lot of benefit for a wide range of users.

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 rules apply to these -longterm kernels as described in Documentation/stablekernelrules.txt

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?

Feel free to comment on the google+ thread about this, or on the lkml thread.

Sixth in a long series of complaints... See part 1 and part 2 and part 3 and part 4 and part 5 for previous atrocities.

There's nothing like waking up and receiving in your inbox, a few scant hours after the merge window has opened up again, a plea for why you haven't already reviewed and applied all 117+ patches that the author sent to you a few weeks ago, back when they well knew you could not apply them due to the merge window being closed.

Oh, and to top it all off, as the message was sent in HTML format, it didn't hit the mailing lists, I was the only one who received it. Because of that, I figured it was better if I just ignored it as well, just like the vger.kernel.org filters did.

I think I'll just ignore this whole set of patches until after LinuxCon Vancouver which should give me enough time to cool off.

This message brought to you by your favorite convicted monopolist.