Kernel Rebasing
During a Fedora release's lifetime, the kernel is often rebased to the most recent stable version. A release might ship with e.g. Linux 3.1 and then be rebased to Linxu 3.2.1 shortly thereafter. There are a few reasons the kernel maintainers do this, and this page will hopefully explain why and how we use this method of kernel maintenance in Fedora.
Why rebase?
Basically, if we don't keep the kernel on at least a somewhat recent upstream release the amount of work required to support that release grows beyond what we can realistically maintain.
Let's use F16 as an example. Fedora 16 shipped with the Linux 3.1.y stable series of kernels. The 3.1.y stable series went EOL upstream a couple of months after F16 shipped, which means that there was no more upstream maintenance on it at all. No auto-backports, no security fixes, nothing. If we were to stick with 3.1.y for the entirety of F16, the Fedora kernel maintainers would have roughly another year and a half of using a kernel that upstream absolutely did not care about. They would need to weed through all of the commits that went into 3.2.y (until it goes EOL) and 3.3 and 3.4 to figure out which fix security issues, which fix issues that hit enough people to warrant a backport, etc. Then they would need to backport them which starts out easy enough but as time goes on becomes increasingly difficult. The rate of change in the upstream kernel is extremely fast paced so once the upstream kernel becomes a couple of releases removed from what Fedora is using the "simple" fixes are heavily dependent on code changes and subsystem reworks that went in prior to that.
By rebasing the Fedora kernel frequently, we limit the amount of work required to actually fix issues that our users see. Fedora also gets new hardware enablement from the newer kernels, and new features. Perhaps most importantly, Fedora stays relevant to upstream so that when bugs are found the upstream developers typically still have the changes that went into that kernel fresh in their memories. That is very important as we work with upstream to provide fixes for the bugs. If the kernel is "stale" in the eyes of the upstream developers, we tend to get much less participation.
How are rebases done?
This will focus on rebases within stable releases. Rawhide is continuously being rebased to the latest upstream git kernel and that is fairly expected for that repository.
A typical stable Fedora release rebase follows a fairly set pattern. The kernel will remain on the upstream stable release that it originally shipped with (e.g. 3.1.y) until the first stable release of next version of the kernel is released (e.g. 3.2.1). At that point in time the Fedora kernel maintainers will rebase the newest stable release and submit an update into updates-testing. Once that update has gone through the normal Fedora update process and received enough karma to be pushed to the stable updates repository, the maintainers wait a bit longer and evaluate how well that new kernel is working for the majority of those users.
If the new update seems to be working well and does not introduce a large number of regressions, the Fedora kernel maintainers will typically rebase the oldest stable Fedora release as well and repeat the process. This is done to minimize the number of different kernels the team is supporting at one time. The maintainers exercise a bit more caution when rebasing the oldest stable release in an attempt to follow the update guidelines as best as possible. In the last few weeks of that release, a rebase might be skipped and only important security fixes will be backported.
Frequently Asked Questions
Does this mean you don't backport things at all?
No, the Fedora kernel maintainers do backports all the time. We backport fixes, hardware enablement, security issues, etc. However, by rebasing frequently we're only having to do that from usually one release away.
Doesn't RHEL stick with a single kernel version and do selective backports? Why can't Fedora follow the same model for a much shorter release?
The difference there is in applicable manpower. There are significantly more people working on the RHEL kernel than there are Fedora. We have two engineers and some great heavy lifing from a couple of wireless developers and a few others for topic specific bugs.
Why don't you use the "longterm" upstream kernels (e.g. 2.6.32.y, 2.6.35.y)
There are two reasons why the "longterm" kernels don't often work out. The first is that each Fedora release brings a new kernel at GA time and those schedules rarely coincide with a fresh "longterm" kernel being announced. Remember, "First" is one of Fedora's four Fs. We do use the normal stable kernel releases very heavily, but those are short term.
The second reason the "longterm" kernels aren't used is that the majority of them are fairly poorly maintained after a while. Fedora 14 stuck with the 2.6.35.y longterm kernel and towards the end of F14's lifetime that was an exercise in frustration. It is rare that enough upstream developers care about a longterm kernel to truly focus on maintaining it. When that happens, it tends to correlate with that particular kernel being used by a major Enterprise kernel distribution basing on it.