gregkh's blog

Last week I released the 2.6.32.58 kernel and said it would be the last one of this series that I was releasing. Given that this was one of the most successful kernel series out there, by number of users, I figured it was worth a brief history of how this came to be, and what I have learned from it.

With my recent job change, I'm starting to run into a bunch of people asking "What exactly are you going to be doing now?"

I've tried responding by describing the kernel related stuff I've been doing for the past years, and it turns out that a lot of people didn't even realize I was doing that.

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:

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:

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.

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 mak

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.

I have a python script that I run all the time as part of my process for emailing out "your patch has been accepted" messages when I accept a Linux kernel patch into one of the many different development trees I maintain. This script's goal is to merely determine the character encoding that the email needs to be sent in, either "UTF-8" or "ISO-8859-1" or "ANSI_X3.4-1968". It's really simple which is great, but it is slow when fed a file of any real length.

My previous plea for help worked out very well. The resulting video of the talk can be seen here, with one of the highlights being the phrase, "It is cheaper to work upstream in the kernel" from Dirk Hohndel who works at Intel. There's a summary of the talk on lwn.net over here if you don't want to sit through the whole video.

Here's a short note as to the status of some recent activity in the openSUSE:Tumbleweed repo: