"Last month, at the kernel summit, there was discussion of putting a Reviewed-by: tag onto patches to document the oversight they had received on their way into the mainline," began Jonathan Corbet in an effort to define the meaning of the recently introduced reviewed-by tag. He continued, "that tag has made an occasional appearance since then, but there has not yet been a discussion of what it really means. So it has not yet brought a whole lot of value to the process."

In the continued discussion, it was requested that all commit tags be defined, prompting Jonathan to update his documentation to include Signed-off-by, Acked-by, Cc, and Tested-by along with his documentation for Reviewed-by. He offered the following definition for the new Reviewed-by tag:

"The patch has been reviewed and found acceptible according to the Reviewer's Statement as found at the bottom of this file. A Reviewed-by tag is a statement of opinion that the patch is an appropriate modification of the kernel without any remaining serious technical issues. Any interested reviewer (who has done the work) can offer a Reviewed-by tag for a patch."

"This feature allows a read-only view into a read-write filesystem. In the process of doing that, it also provides infrastructure for keeping track of the number of writers to any given mount," Dave Hansen began, describing his "read-only bind mounts" patches. He continued, "this has a number of uses. It allows chroots to have parts of filesystems writable. It will be useful for containers in the future because users may have root inside a container, but should not be allowed to write to some filesystems. This also replaces patches that vserver has had out of the tree for several years. It allows security enhancements by making sure that parts of your filesystem [are] read-only (such as when you don't trust your FTP server), when you don't want to have entire new filesystems mounted, or when you want atime selectively updated."

Christoph Hellwig was interested in seeing the patches get some more testing, "I still think we really want this in -mm. As we've seen at the kernel summit there's a pretty desperate need for it." Andrew Morton noted that the "unprivileged mounts" code was working in the same area, but described that work as "a bit stuck." He suggested, "it sounds like a better approach would be for me to merge the r/o bind mounts code and to drop (or maybe rework) the unprivileged mounts patches." Dave explained that they don't collide much, to which Andrew's reply suggested that the read-only mount patches would be merged into the -mm kernel soon.

Linus Torvalds announced the sixth release candidate of the upcoming 2.6.23 kernel, a final release expected within the next few weeks. He noted:

"So last week was a bust, with a lot of core people away for the kernel summit, and with -rc5 having two rather nasty (and silly) one-liner problems that bit a number of people - a missing NULL pointer check in TCP, and a missing list terminator in ata_piix.

"So the fixes for those things were both pretty trivial, and they've been in the -git trees for the last few days, but I just pushed out an -rc6 that also merges up some other updates that did come in during the week."

The -rc6 source level changes can be browsed via the gitweb interface.

"Some people seem to be using 'Acked-by' to mean, 'seems good to me', without necessarily doing a full review of the patch, and instead of trying to change the meaning of 'Acked-by', [the plan is] to have a new sign off which is a bit more explicitly about what it means," Theodore Tso explained in a recent thread on the Linux Kernel mailing list. He continued:

"This was proposed by Andrew and discussed at the Kernel Summit; the basic idea is that it is a formal indication that the person has done a *full* review of the patch (a few random comments from the local whitespace police don't count), and is willing to vouch that the patch is correct, safe, extremely unlikely to cause regressions, etc. If the patch does need to be reverted or fixed because it was buggy, then both the original submitter and the reviewer would bear responsibility and subsystem maintainers might take that into account when assessing the reputations of the submitter and reviewer in the future when deciding whether or not to accept a patch."

Andrew Morton noted that the idea isn't fully fleshed out yet, "we will start introducing Reviewed-by: (I haven't yet quite worked out how yet) but it will be a quite formal thing and it would be something which the reviewer explicitly provided. For now, let's please stick with acked-by". Theodore added, "there was also some discussion about whether or not patches would not be accepted at all without a Reviewed-by, but that probably won't happen initially. The general consensus was to gently ease into it and see how well it works first."

Linus Torvalds announced the fifth release candidate for the upcoming 2.6.23 Linux kernel noting that he was on his way to Cambridge, England, for the 2007 kernel summit. The invite-only kernel summit has been hosted in Ontario, Canada the past five years, this being the first year it has been hosted in Europe. It will happen over three days, from September 4'th through September 6'th.

Regarding 2.6.23-rc5, Linus noted, "hopefully we've addressed most regressions, so please do give it a good testing." He went on to summarize, "the shortlog and diffstat are appended: the diffstat is uglified by some powerpc defconfig updates, but otherwise it all looks pretty nice and small. The shortlog is fairly informative if you care about the details of what changed, but it does end up boiling down to 'fixing a number of generally pretty small issues'. Mostly in drivers and SCTP. So have fun, give it a go, and expect a quiet week next week."

"The elections for five of the ten members of the Linux Foundation Technical Advisory Board[TAB] are held every year, currently the election will be at the 2007 Kernel Summit in a BOF session," James Bottomley, the TAB chair, announced on the Linux Kernel mailing list. He noted that this voting session would be held on the evening of September 5'th or 6'th, providing an email address for sending nominations and adding that anyone is eligible, "only people invited to the kernel summit will be there in person (and therefore able to vote), but if you cannot attend, your nomination email will be read out before the voting begins." James went on to explain:

"It's really just a represent the community type of role. The LF uses the TAB to get a sense of the community for various things they and their members are thinking. Conversely, the TAB was initially formed to get a set of specific objectives out of the then OSDL (Doc Fellowship, Travel Fund, NDA programme and HW lending library plus a few other things). The TAB takes proposals from the community for things it needs that require an organisation to sort out (a good example of this is the currently being acted on PCI sig membership, which will give us access to the PCI specs plus a vendor ID that the virtualisation people asked for to help with virtual device recognition)."

Theodore Ts'o announced that the 2007 Linux Kernel Summit will be moved from its usual location in Ottawa, Canada, taking place this year in Cambridge, England. Ted described the move as a one-time experiment to be re-evaluated at a future date to see if it's worth moving the Kernel Summit to other locations in the future. He noted, "I understand that if it were only up to us developers, we'd want to have the conference in Honolulu, or perhaps in Australia or New Zealand. Unfortunately there are other stakeholers and other financial realities involved." Regarding this year's summit, Ted explained:

"This year, the Kernel Summit will be held in Cambridge, England, at the DeVere University Arms Hotel, September 5-6 (with a welcome reception on the 4th). The decision to move the Kernel Summit to England is a one-year experiment based on the very strong request of last year's kernel summit attendees to try a location outside of Ottawa, and especially from the roughly 1/3rd of the attendees that come from the UK or Europe. So the plan is for us to book the Ottawa Congress Ceter space for July 2008 (which we will need to do by mid-year 2007), and pending how well the Cambridge venue works out in September 2007, we'll figure out how often we want to try moving the Kernel Summit to other locations in future years beyond 2008."

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

At the July 2004 kernel summit, it was decided that there was no need to fork a 2.7 kernel [forum] to introduce new functionality into the Linux kernel. Instead, the decision was made that it was possible for Andrew Morton [interview] and Linus Torvalds to continue working together to first merge things into Andrew's -mm tree, and then after testing the changes to merge them into Linus' mainline tree [story]. This of course led to discussion, with some confusion as to how the 2.6 kernel [forum] could be considered stable while new features were still being merged in [story]. During another short discussion nine months after this decision, Rik van Riel [interview] offered some insight into why the new development model works:

"Things get merged one change at a time, and stabilised one change at a time. This is a big change from the even/odd numbered kernel series, where sometimes a bug crops up without anybody knowing exactly what change introduced it. The current development model seems to go much smoother than anything I've seen before."

An interesting thread on the lkml began when Greg KH submitted a patch for the 2.6 kernel saying, "Ok, to test out the new development model, here's a nice patch that simply removes the devfs code." This was quickly followed with a comment by Oliver Neukum who said, "may I point out that 2.6 is supposed to be a _stable_ series?" In one branch of the thread, the usefulness of devfs was examined.

In another thread, discussion was focused on this "new development model". Jonathan Corbet explained that Linus Torvalds and Andrew Morton [interview] were very happy with the results of their recent teamwork, and saw no immediate pressure to fork a 2.7 development branch. On the contrary, they intend to keep at it as they've been, with things first going into Andrew's -mm patchset [story] for testing, then eventually being merged into the mainline 2.6 kernel. Jonathan went on to explain, "Andrew stated his willingness to consider, for example, four-level page tables, MODULE_PARM removal, API changes, and more. 2.7 will only be created when it becomes clear that there are sufficient patches which are truly disruptive enough to require it. When 2.7 *is* created, it could be highly experimental, and may turn out to be a throwaway tree." And he summarized:

"Andrew's vision, as expressed at the summit, is that the mainline kernel will be the fastest and most feature-rich kernel around, but not, necessarily, the most stable. Final stabilization is to be done by distributors (as happens now, really), but the distributors are expected to merge their patches quickly."