"In the early days, the project was conceived as a way of getting fresh blood into kernel development by giving them fairly simple but generally useful tasks and hoping they'd move more into the mainstream," began James Bottomley starting a thread titled Fixing the Kernel Janitors project. He continued, "if we wind forwards to 2008, there's considerable and rising friction being generated by janitorial patches,", references a recent thread complaining about worthless patches hitting the lkml. Later in the thread he added:

"That's why I think we have to change the process. If we keep the Janitors project, then the bar has to be raised so that it becomes more participatory and thought oriented (i.e. eliminate from the outset anyone who is not going to graduate from mechanical changes to more useful ones). That's why I think bug finding and reporting is a better thing to do. There are mechanical aspects to finding bugs but it is a useful service. Bug fixing is participatory because we usually do quite a lot of back and forth between the reporter and the fixer and at the end of the day quite a few people get curious about how the bug was triggered in the first place and actually go off and read the code."

"As you probably know there is a trend in enterprise computing towards networked storage. This is illustrated by the emergence during the past few years of standards like SRP (SCSI RDMA Protocol), iSCSI (Internet SCSI) and iSER (iSCSI Extensions for RDMA)," began Bart Van Assche, proposing that SCST be merged into the mainline kernel. He suggested that while similar to the STGT project which has been part of the mainline kernel since 2.6.20, "SCST is superior to STGT with respect to features, performance, maturity, stability, and number of existing target drivers. Unfortunately the SCST kernel code lives outside the kernel tree, which makes SCST harder to use than STGT."

SCSI subsystem maintainer, James Bottomley, was not convinced, explaining:

"The two target architectures perform essentially identical functions, so there's only really room for one in the kernel. Right at the moment, it's STGT. Problems in STGT come from the user<->kernel boundary which can be mitigated in a variety of ways. The fact that the figures are pretty much comparable on non IB networks shows this. I really need a whole lot more evidence than at worst a 20% performance difference on IB to pull one implementation out and replace it with another. Particularly as there's no real evidence that STGT can't be tweaked to recover the 20% even on IB."

"Yes, I know ... another tree, just what everyone wants," quipped James Bottomley, announcing his new merge candidate (-mc) tree:

"This one has a specific purpose: It's my tree tracking everyone else's git and quilt trees so I get early warning if there are going to be any merge issues. However, it struck me it might be useful to anyone wishing to track what's going upstream more closely."

James noted that his new tree is available in git, and being automatically built each night. "As you can see from the reverts and the skips, we have trouble even now (and that's after I fixed up most of the failures in SCSI). ACPI and the x86 trees clash hideously, so I kicked out x86. Jens' block tree has two patches which clash with Bart's ide quilt. Greg actually has one patch in his tree that clashes with one of mine." He also noted, "this tree is currently very storage centric (i.e. I haven't included net trees or quilts because I didn't think they'd be likely to clash with my SCSI trees). However, if it could be more generally useful, I could add other trees and quilts to it."

Jeff Garzik posted a two patch series introducing an asynchronous event notification infrastructure, "enabling SATA Asynchronous Notification ('AN') for CD/DVD devices that support it." He summarized:

"For devices that support SATA AN (only very recent ones do), this means that HAL and other userspace utilities no longer need to repeatedly poll the CD/DVD device to determine if the user has changed the media."

The first patch is for the SCSI driver and is based on work originally done by Kristen Carlson Accardi, along with "copious input from James Bottomley". The second patch updates libata to utilize the new SCSI event infrastructure.

James Bottomley announced the Linux Foundation Technical Advisory Board election results from September 5th, "sorry this has taken so long to get out ... I just, er, forgot." He noted that there were eight candidates. "Every candidate gave a nomination statement before the voting (with the three persons not present having their statements read to the meeting). We did single polling per position and had two rounds for a tie on the last candidate."

James then stated that the five people elected to the advisory board were, Arjan van de Ven, Greg Kroah Hartman, Christoph Lameter, Jon Corbett, and Olaf Kirch. The purpose of the advisory board was discussed earlier.

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

James Bottomley posted an article to the lkml titled, "The Dangers and Problems with GPLv3" authored by ten of the most active Linux kernel developers. The paper begins by examining the GPLv2's role in the success of the Linux kernel, then goes on to point out some potential flaws in the upcoming GPLv3. Specific issues are raised with the DRM clauses in the license, "while we find the use of DRM by media companies in their attempts to reach into user owned devices to control content deeply disturbing, our belief in the essential freedoms of section 3 forbids us from ever accepting any licence which contains end use restrictions", the additional restrictions clause, "the additional restrictions section in the current draft makes GPLv3 a pick and choose soup of possible restrictions which is going to be a nightmare for our distributions to sort out legally and get right", and the patents provisions, "as drafted, this currently looks like it would potentially jeopardise the entire patent portfolio of a company simply by the act of placing a GPLv3 licensed programme on their website." The document concludes, "the three key objections noted in section 5 are individually and collectively sufficient reason for us to reject the current licence proposal. However, we also note that the current draft with each of the unacceptable provisions stripped out completely represents at best marginal value over the tested and proven GPLv2."

The resulting discussion included a number of clarifications from Linux creator Linus Torvalds. When it was suggested that he should have specifically retained the right to modify the licensing of the entire kernel he pointed out that things work better as they are with nobody firmly in charge, "remember: the perfect is the enemy of the good. Asking for things that are perfect 'in theory' usually just results in things that are horrible 'in practice'. So not having anybody in charge could _in_theory_ cause problems. But _in_practice_ it's a hell of a lot better than somebody that people need to worry about." He also stressed that the Linux kernel is not a Free Software Foundation project, "I personally have always been very clear about this: Linux is 'Open Source'. It was never a FSF project, and it was always about giving source code back and keeping it open, not about anything else." He further clarified, "the whole 'Open Source' renaming was done largely _exactly_ because people wanted to distance themselves from the FSF. The fact that the FSF and it's followers refused to accept the name 'Open Source', and continued to call Linux 'Free Software' is not _our_ fault."