Home News Featured Blogs Greg Kroah-Hartman

Future of the -longterm kernel releases.

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...
Read more... Comment (0)

How to piss off a Linux kernel subsystem maintainer - part 6

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...
Read more... Comment (0)

Two lazyweb requests

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. For example, the Linux kernel Makefile takes almost 2 seconds to run through this file, even if the file is in the...
Read more... Comment (0)

Help me come up with good questions for Linus at LinuxCon Japan 2011

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 over...
Read more... Comment (0)

openSUSE Tumbleweed status for the week of April 22, 2011

Here's a short note as to the status of some recent activity in the openSUSE:Tumbleweed repo: the kernel is at the 2.6.38 release level tracking the upstream stable 2.6.38 releases. lxde (and its sub-packages) was added calibre was added other smaller packages were added KDE update seems stable and working. It's in the openSUSE:Tumbleweed:KDE repo if anyone wants to test it out now. I'll be working next few weeks to merge this into the main openSUSE:Tumbleweed repo as my bandwidth allows. There is a GNOME 3.0 Tumbleweed repo at openSUSE:Tumbleweed:GNOME. It's properly building right now, but the same caveats...
Read more... Comment (0)
Page 5 of 6

Who we are ?

The Linux Foundation is a non-profit consortium dedicated to the growth of Linux.

More About the foundation...

Frequent Questions

Linux Training / Board

/** BC-056 Ameex changes to add tracking code - 2016-01-22 **/ ?>