Linus Torvalds announced the first release candidate for the upcoming 2.6.21 kernel, ending the two-week merge window [story], "there's a lot of changes, as is usual for an -rc1 thing, but at least so far it would seem that 2.6.20 has been a good base, and I don't think we have anything *really* scary here." Linus noted that the tickless kernel patch [story] was finally merged into the mainline kernel, "the most interesting core change may be the dyntick/nohz one, where timer ticks will only happen when needed. It's been brewing for a _loong_ time, but it's in the standard kernel now as an option." Thomas Gleixner explained a year ago how this could result in cooler CPUs and power savings, "the tickless kernel feature (CONFIG_NO_HZ) enables 'on-demand' timer interrupts: if there is no timer to be expired for say 1.5 seconds when the system goes idle, then the system will stay totally idle for 1.5 seconds."
As for the rest of the changes, Linus added, "there's a ton of architecture updates (arm, mips, powerpc, x86, you name it), ACPI updates, and lots of driver work. And just a lot of cleanups." Release candidate kernels can be downloaded from your nearest kernel.org mirror. You can browse through all the changes using the gitweb interface. Kernel Newbiews maintains a useful summary of all the changes going into the latest version of the Linux kernel.
Linux creator Linus Torvalds announced the 2.6.20-rc6 release candidate kernel, "it's been more than a week since -rc5, but I blame everybody (including me) being away for Linux.conf.au and then me waiting for a few days afterwards to let everybody sync up." He asked that people test the regressions reported against earlier release candidates [story], "so that we can confirm whether they are still active and relevant." Linus noted that he hoped this would be the final release candidate before 2.6.20 is released, then went on to discuss what's new:
"As to -rc6 itself: the bulk of it are the MTD updates (including a few new drivers), and the POWER update (and the bulk of _that_ in terms of patch size being defconfig updates ;)
"But there's various random fixes in infiniband, DVB, network drivers, scsi, usb, some filesystems (cifs, jffs2, nfs, ntfs, ocfs2) as well as core networking too. Oh, and KVM, of course. And stuff I probably have already forgotten."
Adrian Bunk posted a list of known regressions in the latest 2.6.20-rc4 Linux kernel compared to the previous 2.6.19 stable release [story]. In two emails, he listed six regressions that don't have fixes yet, and six regressions with fixes that haven't been merged yet.
In another email thread, Linux creator Linus Torvalds noted that his goal for 2.6.20 is to focus primarily on stability. He also noted that he intends to release the stable kernel at some point after linux.conf.au which is happening this year in Sydney, Australia between January 15th and 20th. He explains, "hopefully 'final -rc' before LCA, but I'll do the actual 2.6.20 release afterwards. I don't want to have a merge window during LCA, as I and many others will all be out anyway. So it's much better to have LCA happen during the end of the stabilization phase when there's hopefully not a lot going on. (Of course, often at the end of the stabilization phase there is all the 'ok, what about regression XyZ?' panic)"
With the release of the 2.6.19-rc1-mm1 kernel, the ext4 filesystem [story] was merged into Andrew Morton [interview]'s -mm tree for further testing. In the announcement Andrew notes that the new filesystem is compatible with ext3 until you add a file that has extents. He also notes, "when comparing performance with other filesystems, remember that ext3/4 by default offers higher data integrity guarantees than most. So when comparing with a metadata-only journalling filesystem, use `mount -o data=writeback'. (Although this doesn't seem to make much difference with ext3)" The goal is to stabilize the new filesystem within the next six to nine months, and ultimately to replace the ext3 filesystem.
With the release of the 2.6.18-rc3-mm1 kernel, Andrew Morton [interview] included a brief note stating, "fwiw, I recently took a position with Google." He then linked to a Linux Today article which details the reasons behind his recent move. The article begins, "Andrew Morton has started working for a new company, but his day job as the Linux 2.6 kernel maintainer will remain exactly the same." In the article, Andrew discusses one of the reasons Google was a good fit, "in my position as kernel maintainer I feel that I should not be employed by a company which has a direct interest in the kernel.org kernel because this would put me in a position of making decisions which are commercially significant to my employer's competitors. As Google maintains their own kernel variant for internal use, their interests are largely decoupled from what happens in the kernel.org kernel."
Following the piratical release of 2.6.14-rc2, a brief discussion looked at the advantages of using git to grab the latest version of the kernel code. A small break in service as the master.kernel.org server was situated in its new home [story] caused the 2.6.14-rc2 patch to not show up right away, and led to people pointing out the advantages of using git. When the ketchup script [story] was proposed as an alternative, it was illustrated how git can keep you up to date with the kernel down to a patch by patch level, or with a specific checkpoint. Linus further explained how git can be used to first track down that a bug was introduced between for example rc1-git3 and rc1-git4, and then to use "git-bisect" to further isolate the problem to a specific change.
As for -rc2, Linus noted, "not a whole lot o' excitement, ye scurvy dogs, but it has t' ALSA, LSM, audit and watchdog merges that be missed from -rc1, and a merge series with Andrew. But on t' whole pretty reasonable - you can see t' details in the shortlog (appended)." Evidently Monday the 19'th of September was International Talk Like A Pirate Day.
Back from the 2005 Linux Kernel Developers' Summit, Linus Torvalds released the 2.6.13-rc4 kernel. Linus noted that the improved development process discussed at the recent summit will begin after the upcoming release of the 2.6.13 kernel, "which is hopefully not too far away." The general idea of the new process, which improves upon last year's development model [story], is to require that all major merges happen within two weeks of a stable kernel release. All the rest of the time between releases should then be spent on fixing bugs. Linus summarized:
"So if you have a favourite kernel developer, please wake him up with a friendly kick to the head and explain this concept to him in small easy-to-understand words, and tell him that we're in the freeze process for 2.6.13 now, and that he should be gathering up the patches, and make sure they get to me _after_ 2.6.13 is out, but at that point do it in a timely manner."
Linux creator Linus Torvalds started a lengthy discussion on the lkml regarding release numbering for the Linux kernel. Some have complained about kernel stability with the new development model discussed back in mid-2004 [story] in which active development occurs in the "stable" 2.6 kernel. In his recent email, Linus explained, "the problem with major development trees like 2.4.x vs 2.5.x was that the release cycles were too long, and that people hated the back- and forward-porting. That said, it did serve a purpose - people kind of knew where they stood, even though we always ended up having to have big changes in the stable tree too, just to keep up with a changing landscape." His new proposal involves still using an even and odd numbering scheme, but on a smaller level. Thus, the upcoming 2.6.12 would be "stable" in that it should only contain bugfixes over 2.6.11. Then 2.6.13 would be more development oriented, including some larger changes. These larger changes would again stabalize in 2.6.14, and so on. He adds, "we'd still do the -rcX candidates as we go along in either case, so as a user you wouldn't even _need_ to know, but the numbering would be a rough guide to intentions. Ie I'd expect that distributions would always try to base their stuff off a 2.6.<even> release."
The lengthy discussion that followed was a collection of mixed reactions. Some liked the proposal, but others were confused as to what it was supposed to solve. Essentially the idea seems to be to get more people to test the kernel, as only with more testers can bugs be found. The current strategy of using a series of "-rc" kernels [story] is confusing to many as in most projects this indicates a "release candidate", or something thought to be stable, whereas with the Linux kernel an -rc release is frequently where the active development takes place. As the common user has come to realize this, the -rc kernels have gotten less testing. Linus says, "that's the whole point here, at least to me. I want to have people test things out, but it doesn't matter how many -rc kernels I'd do, it just won't happen. It's not a 'real release'." Andrew Morton [story]'s -mm tree is intended to weed out obvious errors with big changes before merging patches upstream in the mainline kernel, but again as it frequently proves less stable it tends to get less testing.
With the release of Linux kernel 2.6.9-rc1, Linus Torvalds further refined the new kernel development model [story] first proposed at the 2004 kernel summit [story]. The earlier 2.6.8 kernel was quickly followed by 188.8.131.52 [story] to address an oops in NFS. With today's 2.6.9-rc1 Linus explained, "administrative trivia, and one thing I agonized over: should I make the patches relative to 2.6.8 or 184.108.40.206? I decided that since there is nothing that says that 'basic bug-fix' releases for a previous release might not happen _after_ we've done a -rc release for the next version, I can't sanely do patches against a bugfix release."
With Linus having returned from a week-long vacation, he noted that there were "tons of patches merged", specially thanking Andrew Morton [interview] "who synced up 200+ patches". Regarding the specific changes in this release candidate, Linus said they are "all over: arm, ppc, sparc, acpi, i2c, usb, fbcon, ntfs, xfs, nfs, cpufreq, agp, sata, network drivers - you name it. Most of the changes are fairly small, but there's a lot of them."
Linus Torvalds released the 2.6.7-rc3 release candidate kernel which
contains a few cleanups. He notes:
"Ok, let's calm down for a while before the final 2.6.7.
-rc3 does a lot of sparse type cleanup, mainly thanks to Al Viro (but his
work ended up getting some other people involved too, since the list of
sparse warnings isn't as daunting any more). Some of that has unearthed
real bugs which Al fixed.
But there are DRM, AGP, cpufreq, sparc64, and input updates there too."
Read on for the full changelog.
Andrew Morton [interview] has released 2.6.2-rc3-mm1, including a new debug patch to detect when a process calls i_size_write() without holding the inode's i_sem. Andrew explains, "It generates a warning and a stack backtrace. We know that XFS generates such a trace. It will turn itself off after the first ten warnings. Please don't report the XFS case." Also appearing in this kernel is Rusty Russell's CPU hotplug code, recently discussed on the lkml. It is pointed out that 2.6.2-rc3-mm1 is broken on the ppc64 architecture, "something to do with the sched-domains patch although at this stage we do not know whether the problem lies with that patch or with the ppc64 code."
The desire to merge reiser4 [story] into the -mm kernel was again raised. Andrew responded favorably enough, requesting the necessary patches and complete documentation. He does caution, "be aware that the barriers for a new filesystem are relatively high: each one adds a significant maintenance burden to the VFS and MM developers. It will need cautious review." This comment is evidently in reference to 2.6 inclusion, not -mm inclusion, as he goes on to add, "but that doesn't mean we cannot get it out there, get you some more testing and exposure."