Last week I released the 220.127.116.11 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.
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).
-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.
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
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.