gregkh's blog

It's been about a year since I did a status report of what's going on in
the openSUSE:Tumbleweed repo, let me know if you find this actually
useful or not so that I can determine if I should keep it up.

Snowboarding in Cacsade Cement, March 2012 from Greg KH on Vimeo.

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:

Cc: stable

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.

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 (

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.