|And then there were two (kernels)
||[Nov. 7th, 2011|08:57 pm]
The Fedora kernel team resolved a few weeks ago to get back to rebasing the kernel to the latest stable release as soon as reasonably possible. There are multiple reasons for this, but primarily we get two main benefits. The first is that each new kernel release typically fixes a number of bugs and supports a wider variety of hardware than the previous release. (Yes, there is the possibility of regressions. We're aware of this.) The second is that the team has fewer kernels to support across all of the releases.
In keeping with this resolution, davej committed the rebase of F15 to the 3.1 kernel today. We kept the 2.6.4x naming that was started with the 3.0 rebase, so this naturally becomes 2.6.41. That means F15 an F16 are both based on 3.1 at this point, though I will point out that we won't be pushing 3.1 into F15 until 3.1.1 is released and built on F16. So now we're down to two kernels to focus on in Fedora: 3.1.x for F15/F16 and what will be 3.2 for F17/rawhide.
Now, I know I will get comments about stable releases and large version bumps and regressions being introduced (see above where I already said that). These are all fine points, and they are not to be dismissed out of hand. However, we simply get more bugs fixed by rebasing than we ever would if we did not. The number of bugs that were closed when F15 went from 2.6.38 to 3.0.x was significant. I can think of perhaps 3 regressions that came from it, only one of which really gave me any sort of pause.
And here's another kicker that most rebase critics seem to dismiss but is, in my humble opinion, extremely important. Upstream kernel developers don't want to look at problems on stale kernels. They might say they care, and they go through valiant efforts to get stuff backported and into -stable releases, but let's be honest. They are off working on the stuff that will go into linux-next (which isn't even what is supposed to go into the not-yet-released kernel), fixing the bugs they missed after the not-yet-released kernel merge window closes, and trying to make sure the developers and users sending in reports to the various mailing lists aren't being ignored. They are in a word, busy.
Asking upstream about something seen on a kernel that is 3 releases old isn't likely going to get very far, and if it does the first question asked is usually "Can you hit this on kernel?" Keeping Fedora close to where the developers are working is, again in my opinion, quite worthwhile. The code base is relatively fresh in the collective upstream mind, and we're much more likely to trigger "oh... that might be XYZ" responses than hear "2.6?? I can't even remember the last time I booted a 2.6 kernel."
So anyway, I'm pretty relieved we're getting back to doing frequent rebases. I'd like to start gathering some more statistics on how it goes as well, so that we can measure the impact and make sure we aren't turning "Onward!" into "Unsafe at any speed". It will be doubly useful because some amount of extrapolation can be done to reflect on upstream as well. I know davej has some bugzilla statistics, but I'm not sure they're quite as fine grained as they could be to track this particular thing. I think I found my next side project.
(Some of you may have noticed I keep saying 2 kernels, and I don't mention the fact that F14 is still on 2.6.35 which would really mean 3 kernels. Well... you remember that guy that from Goonies that lived locked up in the basement? Strong, loveable, but a touch slow in the head? Yeah. That's basically F14 at this point. We feed it a candy bar in the form of a security fix every now and then, but that's about it. When it goes EOL in December, I won't really miss it.)