In an email titled "read my lips: no more merges", Linux creator Linus Torvalds announced that the feature freeze, part of the newly improved development process [story], is now in effect for the 2.6.14 kernel. "Ok, it's been two weeks (actually, two weeks and one day) since 2.6.13, and that means that the merge window is closed," Linus explained. "I've released a 2.6.14-rc1, and we're now all supposed to help just clean up and fix everything, and aim for a really solid 2.6.14 release." He went on to add, "be nice now, and follow the rules: put away the new toys, and instead work on making sure the stuff that got merged is all solid. Ok?"

As for what was merged, Linus noted that there was "a lot of stuff all over the place." He began by pointing out that "pretty much every architecture got some updates," including alpha, arm, x86, x86-64, ppc, ia64, mips, and sparc. There was also "an absolutely _huge_ ACPI diff, largely because of some re-indentation." Other subsystems listed as receiving updates include drm, watchdog, hwmon, i2c, infiniband, input layer, md, dvb, v4l, pci, pcmcia, scsi, usb, sound driver, and network, "people may appreciate that the most common wireless network drivers got merged - centrino support is now in the standard kernel." Finally, Linus also noted, "on the filesystem level, FUSE got merged, and ntfs and xfs got updated. In the core VFS layer, the 'struct files' thing is now handled with RCU and has less expensive locking."

Linux creator Linus Torvalds sent a reminder to the Linux Kernel Mailing List that the merge window for 2.6.14 is coming to and end. "As per the new merge policies that were discussed during LKS in Ottawa earlier during the summer," Linus explained, "I'm going to accept new stuff for 2.6.14 only during the first two weeks after 2.6.13 was released." The new development policy was first discussed on the lkml with the release of 2.6.13-rc4 [story], and further elaborated with the release of 2.6.13 [story].

The 2.6.13 stable kernel was released on August 28'th [story]. "That release was ten days ago," Linus said, "so you've got four more days before I don't want any big merges." He went on to note that following the merge cutoff 2.6.14-rc1 will be released. "We certainly already have enough for 2.6.14," Linus noted, "but I just wanted to remind people that if they expected me to merge your work, you're getting closer to the cut-off point."

Linus Torvalds announced the release of the 2.6.13 Linux kernel. "The most painful part of 2.6.13 is likely to be the fact that we made x86 use the generic PCI bus setup code for assigning unassigned resources," Linus began. "That uncovered rather a lot of nasty small details, but should also mean that a lot of laptops in particular should be able to discover PCI devices behind bridges that the BIOS hasn't set up." He went on to note, "we've hopefully fixed up all the problems that the longish -rc series showed, and it shouldn't be that painful, but if you have device problems, please make a report that at a minimum contains the unified diff of the output of 'lspci -vvx' running on 2.6.12 vs 2.6.13. That might give us some clues."

During the 2005 Linux Kernel Developer's Summit it was decided that all major changes need to be merged within two weeks of a major release, giving the rest of the development cycle to fixing bugs [story]. Linus implied that the deadline would be pushed out a week this cycle, "I'm actually going to be away for most of next week, but in general we should now try to do all major merges within the first two weeks of the release. After that, we go into calm-down mode, and if you have work that didn't make the cut, you get to wait until 2.6.14." He also noted that going forward this should mean that major releases happen more frequently. You can download the latest kernel from your nearest Linux Kernel Archive mirror [story], and browse through all the changes using the 2.6 kernel's gitweb interface.

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."

In the debate following Andrew Morton [interview] posting his plans for 2.6.13 [story], the existence of a plugin layer in Reiser4 was discussed. Jeff Garzik put it blunty, "the plugin stuff is crap. This is not a filesystem but a filesystem new layer. IMO considered in that light, it duplicates functionality elsewhere." Andrew Morton went on to explain, "I think the concern here is that this is implemented at the wrong level. In Linux, a filesystem is some dumb thing which implements address_space_operations, filesystem_operations, etc."

Hans Reiser noted, "please remember that this is per file, per item, per node, per attribute, per disk format, per bitmap, per super block, etc., abstracting, not per filesystem abstracting." He explained a couple advantages to plugins being that it makes it much easier for developers to change the disk format, and allows for easy code reuse. He added, "the use of plugins forced all the programmers to think about reusability at every layer of design. V3 of reiserfs is way too hard to work on and modify. If you ask one of the team to code something for V3 instead of V4, they quietly groan at the thought. It is just so much easier to do in V4."

Andrew Morton replied, "advanced features such as those which you describe are implemented on top of the filesystem, not within it. reiser4 turns it all upside down. Now, some of the features which you envision are not amenable to above-the-fs implementations. But some will be, and that's where we should implement those." The lengthy discussion continued, an interesting read for Reiser4 supporters and detractors alike.