|
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. |
As of 2.6.14-rc1, Linus Torvalds has accepted FUSE (Filesystem in Userspace) into the official tree. This has been a long time coming, with a lot of controversy. Linus himself has been the most outspoken person against the project, saying that no filesystem could ever sanely be isolated from the rest of the kernel, and that it was a mistake to try.
Miklos Szeredi, the primary FUSE developer, has worked for years to win over the critics, cleaning up the implementation and refactoring patches in response to various long discussions on the linux-kernel mailing list. FUSE has also been very popular among users, with no shortage of folks willing to describe their own personal uses. And this constant hard work and evangelism eventually paid off early in 2005, when Andrew Morton accepted FUSE into his -mm kernel series.
Andrew, essentially a secondary maintainer of the official 2.6 tree, maintains the -mm series as a warehouse for patches heading into the main line. For controversial or very invasive patches, the -mm tree has come to be considered a perfect staging area. It gets a huge number of users, and so any patches included in it receive much more testing than they would as just an available patch.
Acceptance of FUSE into the -mm tree has led to massive experimentation with FUSE by users, with the result that Miklos has gotten a lot more feedback and answered more requests than he would have, and he has also been able to point out that not many fixes have actually been required in spite of the heavier use.
Although FUSE has finally made the leap into the 2.6 tree, not every objection to FUSE has been solved. The project remains, in some ways, an ugly hack, trying to split parts of the kernel that are not meant to be split and join parts not meant to be joined. FUSE was ultimately accepted because no one could find a less ugly implementation.
Greg Kroah-Hartman has handed off the full I2C Subsystem maintainership to Jean Delvare. Jean had been doing a lot of work in that area for months, and for much of that time, Greg considered him to be an unofficial co-maintainer of the 12C project, but now Greg has stepped down in order to work on other things. Greg won't be completely abandoning his I2C work, however, and he will continue to serve as the conduit who will pass I2C updates to Andrew Morton for the -mm tree and to Linus Torvalds for the mainline.
Brett Russ, having worked for some time privately, recently released a low level driver for the Marvell SATA family. This driver seems to be on the fast-track for inclusion in the main kernel, as some folks have been wishing for just such a thing, and Jeff Garzik (the SATA Subsystem maintainer) was also very excited to see this work being done. Some kernel hackers like Christoph Hellwig have been more critical of the patch and of Jeff's style of maintainership; but unless something big happens, Brett's work is very likely to go into the tree.
Kristen Carlson Accardi from Intel has taken over various PCI Hotplug areas from Dely L. Sy, also from Intel. Originally, she just updated the contact information in source files to indicate the change, but the MAINTAINERS file now lists her as the official maintainer for the PCIE and SHPC hotplug drivers.
The git version control system has reached version 0.99.7, with the maintainer Junio C. Hamano pushing hard for a 1.0 release. Actually, he originally expected 1.0 to come out a lot sooner than it has. But git development is still moving at a fierce pace, so it is not surprising that it would still be a little out of control. Linus Torvalds is still one of the biggest contributors and a strong guiding force in git development, as well as a big evangelist, explaining features and demonstrating power-user tricks.
Cogito, the user friendly wrapper-script that turns git into a tool for the rest of us, has reached version 0.15.1, which may look like a low number, but it is completely usable. If you haven't tried git/Cogito yet, go get it right away. It's fast, it's powerful, it's distributed, it's simple to use, and it's fun.
In his latest effort to speed up the release cycle, Linus Torvalds plans to keep a tight lid on when large changes can enter the 2.6 tree. After each new kernel, there will be a two week period during which large changes will be considered for inclusion. After this cut-off time, development enters a "calm-down mode" when only smaller changes and fixes will be accepted.
Since the implementation of this policy, a number of newcomers have submitted new drivers and other large patches. Because of this new policy, some of these developers were told they have missed the window and will have to wait until the release after next.
A slow release cycle is a problem that besets most open source software. Sometimes, as in the case of Perl 6 and the Enlightenment window manager, developers decide that any release cycle is too much release cycle and embark on ambitious, radical changes that they hope one day might settle down into something ready for public use.
Or, as tends to be the case when developers decide against having a project leader and just allow a group of people to modify the sources as they please, a development effort can simply spiral out of control. The FVWM window manager and the LNX-BBC bootable business card projects have both suffered from this phenomenon at one time or another.
Projects like the Linux kernel that do care about the release cycle have found their own mechanisms. According to the basic tenets of open source development, the project leader encourages everyone to contribute in the best way that they can, but the release cycle problem still troubles many projects. Unless someone hits on a really great idea, it is likely that each project will wrestle with the issue on its own, with no one solution working for the vast majority of other open source projects in the world.
The primary kernel.org server has moved to the Oregon State University Open Source Lab. There have been a number of problems before and after the migration, particularly where the mirroring process between the master server and the various other public servers that mirror the kernel.org data. Some developers noticed problems tracking the kernel's git repository, and this problem was traced to one of the servers not mirroring properly. Developers would try to update their kernel repositories, only to notice conflicts between the divergent versions on the servers.
This sort of problem is par for the course and seems to have been fixed fairly quickly in this case. One issue is that Linux keeps getting more popular, and so kernel.org hardware that seems perfectly able to handle the load at one time will gradually (or not so gradually) be overwhelmed.