Possible changes to longterm kernel maintenance [LWN.net]

Possible changes to longterm kernel maintenance

Posted Aug 13, 2011 17:04 UTC (Sat) by alvieboy (subscriber, #51617)
Parent article: Possible changes to longterm kernel maintenance

As the kernel/distro maintainer for a commercial (focused) linux distribution, I have always been in trouble choosing which kernel to use and evaluate (as well as other core parts like C library). Latest kernels (>=2.6.32.X) have too much issues for us to use them unless in very specific scenarios. Those issues might not relate to the kernel directly (for example, we do have to support old mISDN releases), but the whole system integration is at a stake [I remember a simple iptables formatting change broke all of our reporting system, as well as frequent crashes on Xen due to heavy memory/IO contention].

We cannot afford a full regression test. We need to rely on what kernel guys tell us - it's a "longterm" and "stable" release. This means we can expect patches for severe problems to be applied, without compromising the system as a whole. We don't hack the kernel ourselves, nor have the means and knowledge to do so. Nor can we afford to be a "debian" or a "redhat" - effort spent extracting, forward/backporting patches is just too high for a company like mine.

In case you're wondering, yes we do comply to all licensing terms in all our components, and often we do contribute back (although our contributions are rarely accepted mainstream).

2 years for a long term kernel is a killer. 2 years for developing a full-fledged product is just too narrow - a 5-year support would be ideal here.

Things must move on, but for small companies (<30 employees) doing linux, tracking all kernel changes and adapting them (not all of those changes are kernel-mode specific, they require userspace adaptation) is a no-go.

Remember official Xen Dom0 support was stuck to 2.6.18.

Alvie

(Log in to post comments)

Possible changes to longterm kernel maintenance

Posted Aug 14, 2011 8:22 UTC (Sun) by lkundrak (subscriber, #43452) [Link]

Note that it is now somehow hard to track RedHat kernel.

Possible changes to longterm kernel maintenance

Posted Aug 25, 2011 6:47 UTC (Thu) by hpro (subscriber, #74751) [Link]

There was a lot of stir about that when it landed, but what happpened after that? Did everyone just settle, taking it, or did someone actually try to go through the motions for arguing that a tarball is not "preferred form" ?

Possible changes to longterm kernel maintenance

Posted Aug 20, 2011 18:58 UTC (Sat) by BenHutchings (subscriber, #37955) [Link]

As the kernel/distro maintainer for a commercial (focused) linux distribution, I have always been in trouble choosing which kernel to use and evaluate (as well as other core parts like C library).

Then I suggest you create a derivative of a long-term supported distribution (Debian/RHEL/SLE/Ubuntu) instead of trying to create one from scratch.

We cannot afford a full regression test. [...] Nor can we afford to be a "debian" or a "redhat" - effort spent extracting, forward/backporting patches is just too high for a company like mine.

I have to take issue with this idea that Debian has massive development resources. Adjusting for available time, the entire Debian kernel team probably adds up to no more than 2 full-time developers. AFAIK, none of us are paid to work on Debian; it's all spare time.

What you are saying is: we want other people to do maintenance for us. You are perfectly allowed to do that; in fact most distributions are largely dependent on upstream developers for maintenance of most packages. But I think you'll have to track another long-term distribution. If you care about support for new hardware, for example, you aren't going to get it in the longterm series, which only adds support where the necessary code change is very small.