For many years, each Linux kernel release was assigned a series of three numbers, X.Y.Z, with an even Y indicating a "stable" release, and an odd Y indicating an "unstable" development release. Z was incremented for each individual kernel release. The "stable" 1.0.0 Linux kernel was released in March of 1994. New development was then continued in the "unstable" 1.1.z branch, until the "stable" 1.2.0 Linux kernel was release in March of 1995. Major improvements in the kernel lead to X being incremented to 2, and a "stable" 2.0 kernel was released in June of 1996. Active development then continued in the "unstable" 2.1 tree. This process continued with "stable" 2.2, 2.4 and 2.6 kernel trees, and each stable tree gained an official maintainer while Linux creator Linus Torvalds focused on newer features in the next "unstable" tree. Development in these "unstable" trees could go on for periods of multiple years before a "stable" tree was branched.

This long-standing odd/even development model was officially scrapped in 2004 thanks to the success that Linus and Andrew Morton were having working together, and significant "unstable" development began happening between each 2.6.Z release. In a recent thread it was asked what it would take for an "unstable" 2.7 development tree to be created, to which Linus noted replied:

"Nothing. I'm not going back to the old model. The new model is so much better that it's not even worth entertaining as a theory to go back. That said, I _am_ considering changing just the numbering. Not to go back to the old model, but because a constantly increasing minor number leads to big numbers. I'm not all that thrilled with '26' as a number: it's hard to remember. [..] I think the time-based releases (ie the '2 weeks of merge window until -rc1, followed by roughly two months of stabilization') has been so successful that I'd prefer to skip the version numbering model too. We don't do releases based on 'features' any more, so why should we do version _numbering_ based on 'features'?"

"It's been almost three months since 2.6.25 (87 days to be exact, I think), making this a longer-than-usual release cycle. Or maybe it just feels that way, and we're always getting close to three months these days," said Linux creator Linus Torvalds, announcing the 2.6.26 Linux kernel, adding, "but it's out there now." He continued:

"The diffs from -rc9 are pretty small, with with the bulk actually being Documentation updates (almost 80% is just added docs). The rest tends to be one-liners for some regressions or otherwise pretty small patches. Several regressions did get fixed in the last few days, thanks to everybody involved."

Click the 2.6.26 tag to review all the previous release candidate announcements building up to this release. Source level changes can be reviewed via Linus' 2.6 gitweb kernel tree. The latest kernel can be downloaded from the Linux Kernel Archives.

"Ok, the last -rc obviously wasn't the last one after all, since here's a new one," noted Linus Torvalds, announcing the 2.6.26-rc9 kernel. He continued, "enough changes that we needed another -rc, and the regression list isn't emptying fast enough either (probably because a number of people, including reporters, are vacationing)." He went on to summarize:

"The actual bulk of this all is a new UVC video driver for the standard USB Video Class specification. It's a new driver, so shouldn't cause any regressions, but it's fairly sizable [...] ie 78% is just that one new driver, and almost 92% is driver updates in general (although some of them are reverts, so they show up as diffs against -rc8, but they actually cause the _total_ diff against 2.6.25 to shrink a bit). The fs updates are partly some minor updates to 9p, ecryptfs, proc and udf, but partly some delayed cleanup patches that went through Al. Bad Al. But when Al sends me patches, I apply them. I worry what would happen if I didn't. The rest is mainly small fixes (one-liners and 'few-liners') all over the place, many of them merged from Andrew's -mm queue."

"It hasn't been a week, I know, and this is a pretty small set of changes since -rc7, but I'm going to be mostly incommunicado for the next week or so, so I just released what will hopefully be the last -rc," began Linux creator Linus Torvalds, announcing the 2.6.26-rc8 kernel. He added, "or maybe not. It depends on how good you all are while I'm not looking." Regarding the latest release candidate, Linus explained:

"Most of the bulk of the changes here are to Xen and to KVM in particular, which shows up as a rather unusual dirstat: 65% is in arch/x86 (counting the asm-x86 changes too). The rest is mostly random stuff, the appended ShortLog gives a reasonable idea. Several bugzilla entries are hopefully now closed."

"Another week, another -rc," began Linux creator Linus Torvalds, announcing the 2.6.26-rc7 Linux kernel, "and as usual, it's mainly drivers and arch updates - over 90% of changes are in one or the other." He continued:

"A big part of it (about two thirds of the driver update, in fact) is a late-dropping AGP/DRM update that adds support for some new Intel and ATI graphics cards. And a big part of the arch update is the inevitable def_config updates, of course. I'm not all that happy about the timing of the support for the new cards, but at the same time I also hate delaying new drivers. Obviously the hope is that it can't cause any regressions, since the added code is almost entirely for stuff that simply wasn't supported at all before."

Linus concluded, "if you ignore the driver and arch updates, the rest is pretty minor. About half is in networking, and half of the remaining is filesystems updates (mainly ocfs2). And random smatterings elsewhere, like some scheduler updates."

"In the kerneloops.org stats, a new oops is rapidly climbing the charts, began Arjan van de Ven, referring to his website where he automatically collects kernel oops and warning reports from mailing lists, bugzillas, and a special client. Regarding the latest oops, he noted, "the oops is a page fault in the ext3 'do_slit' function, and the first report of it was with 2.6.26-rc6-git3." Linux creator Linus Torvalds took a quick interest in the issue, observing that all the oopses seemed to be on the i686 architecture, suggesting, "could this perhaps be an indication that it is specific to i686 some way (eg a compiler issue?)"

Shortly before Linus sent out his emails, Dave Airlie confirmed that this was indeed a known compiler bug affecting GCC 4.3.1. The bug report notes, "any ext* filesystem which enables the dir_index feature is likely susceptible". Linus caught up on his email and retorted, "gaah. I should read all my email instead of wasting my time trying to match up the code with what I can reproduce.." The reason the Red Hat bug report wasn't automatically picked up by the kerneloops website was because the oops was reported in a jpeg image, leading Arjan to quip, "maybe one day if I'm really bored I'll implement OCR into [kerneloops.org] ;)".

"I'd like to say that the diffs are shrinking and things are calming down, but I'd be lying," began Linux creator Linus Torvalds, announcing the 2.6.26-rc6 kernel. He noted, "another week, another -rc, and another 350 commits. Yes, the diff is smaller than the one from rc4 to rc5 (despite having more commits), so we're on the right trajectory, but I was hoping for less churn at this stage." Linus continued:

"As usual, most of the changes are to drivers (with arch updates a strong second). The DVB updates are the biggest chunk of that, but on the whole it's quite spread out. As mentioned, the diffs are smaller and there are more commits, and yes, most of the commits are really rather small and trivial fixes.

"Give it a try, we should have a few less regressions once more,"

"Another week, another batch of mostly pretty small fixes. Hopefully the regression list is shrinking, and we've fixed at least a couple of the oopses on Arjan's list," said Linux creator Linus Torvalds, announcing the 2.6.26-rc5 kernel. He added, "as usual, the bulk of the changes are in drivers and arch code - together they are about 70% of the diffstat. And the arch stats are bloated by some new/updated SH and avr defconfig files, which is also fairly common at this stage." Linus concluded:

"Perhaps unusually, 13% is in kernel/, almost all of it fixing up some scheduler issues - with the bulk of it by far being a couple of reverts due to performance regressions. But there's a few other fixes too. And then there is networking and some ocfs2 updates. Along with various one-liners sprinkled all around.

"The shortlog (appended) gives a reasonable view of it all. Nothing hugely exciting sticks to my mind, but then I don't think we've had any really hugely exciting problem spots either.."

"You know the drill by now: another week, another -rc," began Linux creator, Linus Torvalds, announcing the 2.6.26-rc4 kernel. "There's a lot of small stuff in here", he continued, "most people won't even notice. The most noticeable thing is for all you 32-bit x86 people who use PAE (enabled by the HIGHMEM64G config option) due to having too much memory in your machine - mprotect() was broken due to some of the PAT fix/cleanup patches, causing the NX bit to be not set correctly." Linus described the fixed bug:

"If you had PAE enabled _and_ a recent enough CPU to have NX, but not recent enough to be 64-bit (or you were just perverse and wanted to run a 32-bit kernel despite having a chip that could do 64-bit and enough memory that you _really_ should have used a 64-bit kernel), you'd get various random program failures with SIGSEGV. It ranged from X not starting up to apparently OpenOffice not working if it did."

He went on to note, "most of the changes, as usual, are in drivers, at 60%, with some DRI changes leading the way (fixing a number of other regressions, mainly by reverting the under-cooked vblank update). Network, MMC, USB, watchdog and IDE drivers also got updates. We had CIFS and NFS updates, and some arch updates as usual." Linus concluded, "nothing really hugely exciting, I think we're doing pretty ok in the release cycle, and I'm getting the feeling that things are calming down."

"Is there a write up of what you consider the 'proper' git workflow?" Theodore Ts'o asked Linux creator Linus Torvalds, "why do you consider rebasing topic branches a bad thing?" Linus replied, "rebasing branches is absolutely not a bad thing for individual developers. But it *is* a bad thing for a subsystem maintainer." He went on to differentiate between 'grunts' who write the code and 'managers' who primarily collect other people's code, "a grunt should use 'git rebase' to keep his own work in line. A technical manager, while he hopefully does some useful work on his own, should strive to make _others_ do as much work as possible, and then 'git rebase' is the wrong thing, because it will always make it harder for the people around you to track your tree and to help you update your tree." Linus compared his own patch management style and productivity from over six years ago before he started using BK and git, to his current style using git:

"You can either try to drink from the firehose and inevitably be bitched about because you're holding something up or not giving something the attention it deserves, or you can try to make sure that you can let others help you. And you'd better select the 'let other people help you', because otherwise you _will_ burn out. It's not a matter of 'if', but of 'when'. [...] And when you're in that kind of ballpark, you should at least think of yourself as being where I was six+ years ago before BK. You should really seriously try to make sure that you are *not* the single point of failure, and you should plan on doing git merges. [...] I think a lot of people are a lot happier with how I can take their work these days than they were six+ years ago."

"This time around, we have 60+% of the changes in drivers, notably drives/video and drivers/media, with some infiniband, networking and usb lovin' to fill things out," began Linux creator Linus Torvalds, announcing the 2.6.26-rc3 kernel. "The rest is (as usual) mostly arch updates," he continued, "this time mostly mips, m68k and uml." Linus noticed that Linux kernel development has been managed with git now as long as it was managed with BitKeeper, a little over three years for both tools. He explained, "the most striking difference has nothing to do with git or BK (the switch-over timing was just the reason I decided to take a look), but with the fact that we're not just continuing to develop, but we're developing faster and with more people," adding:

"So during the three years 2002->2005, we had 63,428 commits, attributed to 1,560 different authors (caveat: misspellings etc will mean that some people get counted more than once). During the last three years, we've had 96,885 attributed to 4,068 distinct authors (with the same caveat, obviously).

"I didn't do a lot of per-commit statistics yet, but from the little I've done it also seems like we've gotten increasingly better at doing small commits (which is probably one of the reasons we have a larger number of them, but also why we have more authors - small commits is how people get into doing kernel development)."