|
The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching ten thousand messages in a given week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown. Our regular monthly column keeps you abreast of the latest discussions and decisions, selected and summarized by Zack. Zack has been publishing a weekly online digest, the Kernel Traffic newsletter for over five years now. Even reading Kernel Traffic alone can be a time consuming task. Linux Magazine now provides you with the quintessence of Linux Kernel activities, straight from the horse's mouth. |
Paul Mackerras has created gitool, a graphical tool for creating git commits. gitool allows users to create and submit commit messages, shows lists of files and their status as new or changed, and lets the reader choose files to view based on that status. It also performs three-way-diffs between the tree head, any checked in changes to the repository, and any changes that have not yet been checked in.
Linus Torvalds likes the tool, but has some significant objections, including disliking the name itself and the fact that gitool is not simply another mode for the already-existing gitk repository browser. Aside from that, Linus's main objections are just with the user interface, not with the repository interaction features.
Ray Lehtiniemi has written a cute little tool called headergraphs for graphing kernel header file dependencies. The images that headergraphs produces are very cool, with smooth-flowing lines, and different shapes representing different relationships between files.
Folks seem to be having a bit of fun with it, and Ray has been very responsive to suggestions so far, migrating from PostScript to png files (and planning to allow users to choose the output file format eventually), and working on increasing the information density of each graph. The sample graphs Ray created also reveal how complex some of the kernel header dependencies really are. See Figure 1 for an example of a headergraphs graph.
For more on headergraphs, see the headergraphs page at the kernel.org website http://www.kernel.org/pub/linux/kernel/people/rayl/headergraphs/.The description on the headergraphs page describes the graphic elements. headergraphs uses a variety of colors and shapes to convey information. This looks like a fun little tool!
For years, the linux-kernel mailing list administrators worked hard blocking spam with hand-crafted rules, but now they've decided to use bogofilter to automate the process. One of their first public steps was to start training the Bayesian filter on email as it came through, without actually blocking anything.
After awhile of eyeballing this, Matti Aarnio and the rest of the administrators judged that bogofilter would now be able to actually recognize when something was or was not spam, so they turned on the filtering capability, and linux-kernel became a bogofilter-protected list.
After almost a month, however, some users were reporting that the spam problem seemed worse than ever, and some legitimate emails were turning up as false positives as well - though Matti reported that only about 10 legitimate emails per week were being marked as spam.
At that time, his assessment of bogofilter was that the Bayesian algorithms had learned about all they were going to, and so the amount of spam getting through to the list could be expected to stay at the current levels.
He also remarked that converting the list from an open forum, where anyone could post, to a closed forum, where only list members could post, was becoming a more and more appealing as a solution to the spam problem. Linus Torvalds has always opposed this however, saying that it's important to make it as easy as possible for users to report bugs and join the discussion.
But Linus also joined this recent discussion, saying that bogofilter was also not a good solution to spam, because the Bayesian filters were just not sufficient for catching all spam. He recommended SpamAssassin instead. But as Alan Cox points out, "every good spammer reruns their message through spamassassin adding random text till they get a good score *then* they spew it out."
So it seems there is as yet no good spam system at work for linux-kernel. Marc Perkel has offered the services of junkemailfilter.com, and perhaps the linux-kernel administrators should consider letting him have a go at it.
Luke Yang posted a patch adding over a dozen maintainers of the Blackfin architecture, including himself. He included Sonic Zhang in that list, and also listed Sonic as the sole maintainer of the Blackfin serial driver.
Jim Cromie has proposed adding a new field to the MAINTAINERS file, the "V" field, where anyone owning the appropriate hardware can offer to verify and test the code. As Jim sees it, they would be offering their services in exchange for a little notoriety in the MAINTAINERS file. But Adrian Bunk has pointed out that the "V" information would be likely to become outdated and useless; however, Andrew Morton may support the creation of a TESTERS file to hold volunteer "QA people". So far this plan has not been put into effect.
Josh Triplett has made a few updates to the MAINTAINERS file himself. He listed Dipankar Sarma as the Read-Copy Update (RCU) maintainer; and himself as taking over from Paul E. McKenney as the RCUTorture module maintainer.
Stefan Richter also updated the MAINTAINERS file recently, making a few changes to the IEEE 1394 driver listings. First, the "IEEE 1394 ETHERNET (eth1394)" entry has been renamed "IEEE 1394 IPV4 (eth1394)", upgraded from "Orphan" status to receiving the "Odd Fixes", and Stefan listed himself as the maintainer. For the "IEEE 1394 SUBSYSTEM" entry, Stefan listed himself as comaintainer with Ben Collins, replacing Jody McIntyre. He also listed himself replacing Jody as sole maintainer of the "IEEE 1394 PCILYNX DRIVER" entry, this time downgrading the driver from "Maintained" to just receiving "Odd fixes". All these changes were approved by both Ben and Jody.
Arjan van de Ven, acting on behalf of Intel, has announced the initial release of the Linux-ready Firmware Developer Kit at http://linuxfirmwarekit.org. This useful open source tool tests how well Linux will work with the BIOS on a given computer.
Developers can put the Firmware Developer Kit to work by burning it onto a CDROM, booting from that CD, and letting it run a variety of tests, which it then summarizes on the screen. The main audience for this tool is BIOS engineers, but Arjan says it could also be useful to kernel developers and distribution developers diagnosing particular kernel bugs that seem like they may be BIOS related.
By releasing the Firmware Developer Kit as an open source project, Intel hopes folks will help expand the tool to cover more test cases. How popular or useful the tool will become remains to be seen, but it does seem to have gotten a fairly warm reception on the linux-kernel mailing list, where Pavel Machek, at least, expressed interest in some tests related to software suspend.
Perhaps ironically, Intel is not using git for the kit's repository, relying on Subversion instead.