Greg Kroah-Hartman revealed the 2.6.32 conspiracy that got many important organizations to gather round the 2.6.32 release of the Linux kernel and support it for years. He had seen the benefit of long-term support for 2.6.16 and inspired the conspiracy to do the same for 2.6.32. The advantages for large deployments and distros to support the same kernel were huge increases in contributions and bug reports.
Interestingly, the period of support more closely matched the cadence of Debian GNU/Linux rather than frisky releases like Ubuntu and their “cadence” strategy. Chuckle. Debian developers played a large role in supporting the endless string of backported code from newer kernels. This strategy may become more important as use of GNU/Linux grows in business and government and breaks through to an OEM to consumer channel. Expertise in the kernel is scarce. It is important to get the greatest benefit from the global contribution and that is to share the result widely in the most usable form, a kernel with long-term support upstream. That takes a burden off everyone using the product, right down to the end user.
“During a few of these meetings, in mid to late 2009, the kernel developers working for all of the various distros quickly figured out that the timeline for the next major releases of a number of products appeared to be lining up to happen all near the same timeframe. Because of the success of the 2.6.16 kernel, and how it worked to provide a solid base for a distro to work off of for a long time, we all agreed, informally, to push for a specific kernel release within our communities/companies that I would then maintain in the kernel.org community in the same way I had done for the 2.6.16 kernel release.
We all drifted back to our companies, and planted the seeds that maybe something like the 2.6.32 kernel would be a nice one to do our product on. This planting worked so well, I had to refrain from fits of laughter in one meeting where a project manager got up and said, “We decided that the 2.6.32 kernel would be the best for our product, what does engineering think about this?””
I still have 2.6.32-5 on one system. It works. Why change it?