The ongoing discussion about the Reiser4 filesystem [story] continues on the lkml. Jeff Garzik discussed the complexity introduced by a plugin layer [story], suggesting it is really a second VFS, "furthermore, it completely changes the notion of what a Linux filesystem is. Currently, each Linux filesystem is a tightly constrained set of metadata support. reiser4 changes 'tightly constrained' to 'infinity'. While that freedom is certainly liberating, it also has obvious support costs due to new admin paradigms and customer configuration possibilities."

Linux creator Linus Torvalds weighed in on the discussion, "as long you call them 'plugins' and treat them as such, I (and I suspect a lot of other people) are totally uninterested, and in fact, a lot of people will suspect that the primary aim is to either subvert the kernel copyright rules, or at best to create a mess of incompatible semantics with no sane overlying rules for locking etc." He went on to add, "as far as I'm concerned, the problem with reiser4 is that it hasn't tried to work with the VFS people. Now, I realize that the main VFS people aren't always easy to work with (Al and Christoph, take a bow), but that doesn't really change the basic facts. Al in particular is _always_ right. I don't think I've ever had the cojones to argue with Al.."

Later in the same thread, Andrew Morton [interview] noted that he's currently reviewing the code, "meanwhile here's poor old me trying to find another four hours to finish reviewing the thing." Regarding the code he added, "the writeout code is ugly, although that's largely due to a mismatch between what reiser4 wants to do and what the VFS/MM expects it to do. If it works, we can live with it, although perhaps the VFS could be made smarter." He then suggested, "I'd say that resier4's major problem is the lack of xattrs, acls and direct-io. That's likely to significantly limit its vendor uptake." As for the plugin debate, Andrew said, "the plugins appear to be wildly misnamed - they're just an internal abstraction layer which permits later feature additions to be added in a clean and safe manner. Certainly not worth all this fuss."

Theodore Ts'o offered an insightful summary of issues affecting future development on the ext3 filesystem, "it is clear that many people feel they have a stake in the future development plans of the ext2/ext3 filesystem, as it [is] one of the most popular and commonly used filesystems, particular amongst the kernel development community. For this reason, the stakes are higher than it would be for other filesystems." He listed the three main concerns for future development as stability, compatibility confusion, and code complexity, "unfortunately, these various concerns were sometimes mixed together in the discussion two months ago, and so it was hard to make progress. Linus's concern seems to have been primarily the first point, with perhaps a minor consideration of the 3rd. Others dwelled very heavily on the second point."

Theodore went on to say, "to address these issues, after discussing the matter amongst ourselves, the ext2/3 developers would like to propose the following path forward." He listed a four step plan beginning with the creation of a new ext4 filesystem registered with the kernel temporarily as 'ext3dev', "this will be explicitly marked as an CONFIG_EXPERIMENTAL filesystem, and will in affect be a 'development fork' of ext3. A similar split of the fs/jbd will be made in order to support 64-bit jbd, which will be used by fs/ext4 and future versions of ocfs2." Theodore explained that new features will go into the ext3dev tree, with only bugfixes making their way back to the stable ext3 tree. He noted that it will remain important that the ext4 code base can mount ext3 filesystems, "this is necessary to ensure a future smooth upgrade path from ext3 to ext4 users." Finally, "probably in 6-9 months when we are satisified with the set of features that have been added to fs/ext4, and confident that the filesystem format has stablized, we will submit a patch which causes the fs/ext4 code to register itself as the ext4 filesystem." He further noted that once ext4 is deemed fully stable, it may completely replace ext3 in the source tree.

With the release of the 2.6.16 Linux kernel, Adrian Bunk reiterated his previously debated intention of maintaining the 2.6.16.y kernel tree well into the future. The first 2.6.x.y release was 2.6.8.1 by Linus Torvalds [story], a quick one line fix for NFS. The idea was revisted a few months later in October of 2004 [story], but didn't actually gain momentum until March of 2005 [story] [story]. Beginning with the 2.6.11 kernel, the process was formalized with Greg KH and Chris Wright officially maintaining 2.6.x.y releases [story] until 2.6.(x+2) is released. For example, stable patches will be applied to the current 2.6.16.y kernel by Greg and Chris until 2.6.18 is released sometime well in the future.

Adrian's plan is to pick up the development of the 2.6.16.y kernel at that point, maintaining it much as the 2.4 kernel tree is is maintained [interview]. His intention is to maintain the tree as long is it is used and people contribute patches. The earlier debate on this idea was met with mixed reactions. At that time Greg KH cautioned, "the time and energy to do this for a long period of time is huge. If I were you, I would listen to the people who have and do maintain these kinds of kernels, it's not a simple job by any means."

In a conversation that began as a request to include the SAS Transport Layer in the mainline Linux kernel, there was an interesting thread regarding specifications. Linux creator Linus Torvalds began the discussion saying, "a 'spec' is close to useless. I have _never_ seen a spec that was both big enough to be useful _and_ accurate. And I have seen _lots_ of total crap work that was based on specs. It's _the_ single worst way to write software, because it by definition means that the software was written to match theory, not reality."

Linus went on to list two reasons to avoid specifications when writing software. First, "they're dangerously wrong. Reality is different, and anybody who thinks specs matter over reality should get out of kernel programming NOW." Second, "specs have an inevitable tendency to try to introduce abstractions levels and wording and documentation policies that make sense for a written spec. Trying to implement actual code off the spec leads to the code looking and working like CRAP." As a "classic example" he pointed to the OSI model, "we still talk about the seven layers model, because it's a convenient model for _discussion_, but that has absolutely zero to do with any real-life software engineering. In other words, it's a way to _talk_ about things, not to implement them. And that's important. Specs are a basis for _talking_about_ things. But they are _not_ a basis for implementing software."

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.

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.

A discussion was raised as to whether or not GIT [story] would be a service that should be provided by development websites like SourceForge. Linus Torvalds suggested that this would be a good match-up. "The git architecture is admirably suited to an _untrusted_ central server," Linus explained, "ie exactly the SourceForge kind of setup." He went on to explain, "with git, developers don't have to trust SF, and if SF is down or something bad happens (disk crash, bad backups, whatever), you didn't 'lose' anything - the real development wasn't being done at SF anyway, it was a way to _connect_ the people who do real development."

As to whether or not this is likely to happen, Linus added, "it's possible that git usage won't expand all that much either. But quite frankly, I think git is a lot better than CVS (or even SVN) by now, and I wouldn't be surprised if it started getting some use outside of the git-only and kernel projects once people start getting more used to it. And so I'd be thrilled to have some site like SF support it."

Petr Baudis announced the creation of a homepage for git, the directory content manager used to manage the Linux kernel. Git was originally written by Linus Torvalds in early April of 2005 [story], and is now maintained by Junio Hamano [story]. Other online resources available for the tool include a tutorial that walks through the process of setting up and using git, a man page, and the gitweb interface providing easy browsing of the many kernel trees managed by git. The new webpage explains:

"GIT falls into the category of distributed source code management tools, similar to Arch or Darcs (or, in the commercial world, BitKeeper). Every GIT working directory is a full-fledged repository with full revision tracking capabilities, not dependent on network access to a central server."

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