"Oh great, not yet-another-kernel-tree, just what the world needs..." began Greg KH, continuing, "yes, this is an announcement of a new kernel tree, linux-staging." He explained:

"In a long and meandering thread with some of the other kernel developers a week or so ago, it came up that there is no single place for companies and developers to put their code for testing while it gets cleaned up for submission into the kernel tree. All of the different subsystems have trees, but they generally only want code that is about to go into this release, or the next one. For stuff that is farther off, there is no place to go. So, here's the tree for it."

In a readme created for the new tree, Greg adds, "the linux-staging tree was created to hold drivers and filesystems and other semi-major additions to the Linux kernel that are not ready to be merged at this point in time." He also requested that the new tree be included in Linux -next, leading Theodore Ts'o to ask, "does this mean that the nature of linux-next is changing? I thought the whole point of linux-next was only to have what would be pushed to Linus in the near future, so we could check for patch compatibility issues." Greg explained that he was hoping for an exception for his new -staging tree as it only includes whole new drivers and filesystems, not changes to existng features, "there is stuff that users can use to get hardware to work that currently is not supported on kernel.org kernels at all." As an example he noted, "there are 2 big network drivers in there that support a wide range of devices that some people would like to see working :)"

"Is there a write up of what you consider the 'proper' git workflow?" Theodore Ts'o asked Linux creator Linus Torvalds, "why do you consider rebasing topic branches a bad thing?" Linus replied, "rebasing branches is absolutely not a bad thing for individual developers. But it *is* a bad thing for a subsystem maintainer." He went on to differentiate between 'grunts' who write the code and 'managers' who primarily collect other people's code, "a grunt should use 'git rebase' to keep his own work in line. A technical manager, while he hopefully does some useful work on his own, should strive to make _others_ do as much work as possible, and then 'git rebase' is the wrong thing, because it will always make it harder for the people around you to track your tree and to help you update your tree." Linus compared his own patch management style and productivity from over six years ago before he started using BK and git, to his current style using git:

"You can either try to drink from the firehose and inevitably be bitched about because you're holding something up or not giving something the attention it deserves, or you can try to make sure that you can let others help you. And you'd better select the 'let other people help you', because otherwise you _will_ burn out. It's not a matter of 'if', but of 'when'. [...] And when you're in that kind of ballpark, you should at least think of yourself as being where I was six+ years ago before BK. You should really seriously try to make sure that you are *not* the single point of failure, and you should plan on doing git merges. [...] I think a lot of people are a lot happier with how I can take their work these days than they were six+ years ago."

"The following patches have been in the -mm tree for a while, and I plan to push them to Linus when the 2.6.25 merge window opens," began Theodore Ts'o, offering the patches for review before they are merged. He explained that the patches introduce some of the final changes to the ext4 on-disk format, "ext4, shouldn't be deployed to production systems yet, although we do salute those who are willing to be guinea pigs and play with this code!" He continued:

"With this patch series, it is expected that [the] ext4 format should be settling down. We still have delayed allocation and online defrag which aren't quite ready to merge, but those shouldn't affect the on-disk format. I don't expect any other on-disk format changes to show up after this point, but I've been wrong before.... any such changes would have to have a Really Good Reason, though."

"There are no 'persons responsible for defending the kernel GPL', there are just a few hundreds or thousands copyright holders of the kernel, and each of them has the right to sue you if he thinks you distribute something that violates his copyright," Adrian Bunk responded in a recent discussion about the legality of linking to GPL'd code in embedded applications. He added, "jurisdiction and applicable copyright law depends on things like where the copyright holder lives and where you distribute it." When it was asked how the constraints of a given piece of hardware might affect the interpretation of the GPL, Theodore T'so explained:

"At the end of the day it all boils down to what is a derived work. If an object file which is designed to link into a kernel is a derived work, then the GPL claims that it will infect across to that derived work. Whether or not it this is a case is a matter of much debate, and as far as I know, no court has ever ruled on point regarding the question of object files, dynamical linking, and whether or not that would be a derived work or not. It seems likely that the answer may vary from one legal jurisdiction to another. Hence, the only answer that we can give which is useful is, 'Take this off of LKML, and go ask a lawyer.'"

"I've just released the 2.6.23-rc9-ext4-1. It collapses some patches in preparation for pushing them to Linus, and adds some of the cleanup patches that had been incorporated into Andrew's broken-out-2007-10-01-04-09 series," announced Theodore Ts'o. He also noted of the current ext4 git tree, "it also has some new development patches in the unstable (not yet ready to push to mainline) portion of the patch series." In an earlier thread Theodore posted a series of patches specifically intended for inclusion in the upcoming 2.6.24 kernel. Included in the patch series was a patch for improving fsck performance, "in performance tests testing e2fsck time, we have seen that e2fsck time on ext3 grows linearly with the total number of inodes in the filesytem. In ext4 with the uninitialized block groups feature, the e2fsck time is constant, based solely on the number of used inodes rather than the total inode count." The patch included an explanation of how the feature works, enabled through a mkfs option:

"With this feature, there is a a high water mark of used inodes for each block group. Block and inode bitmaps can be uninitialized on disk via a flag in the group descriptor to avoid reading or scanning them at e2fsck time. A checksum of each group descriptor is used to ensure that corruption in the group descriptor's bit flags does not cause incorrect operation."

"The fact that we continue to expose internal data structures via sysfs is a gaping open pit [and] is far more likely to cause any kind of problems than changing an error return," Theodore Ts'o noted, responding to a thread discussing a patch to fix an error return code. Andrew Morton agreed, "I was staring in astonishment at the pending sysfs patch pile last night. Forty syfs patches and twenty-odd patches against driver core and the kobject layer." He continued, "that's a huge amount of churn for a core piece of kernel infrastructure which has been there for four or five years. Not a good sign." Andrew then added a humorous quip, "I mean, it's not as if, say, the CPU scheduler guys keep on rewriting all their junk. oh, wait.."

Sysfs maintainer Greg KH replied, "I'm sorry, have I missed a breakage lately? I don't know of one in over a year that has not been fixed. Do you?" He noted that when sysfs is used properly from user space no breakage occurs, "if you want to propose some other kind of alternative to exporting this kind of _needed_ information to userspace, in a simple and easy-to-use manner, please do so. Until then, stop complaining unnecessarily." He went on to explain that most sysfs changes are to support things like containers, requiring per-user/per-container views, something sysfs wasn't originally designed for. "These aren't being done just because we like to break things, we are trying to make things better, and fix real bugs here."

"What is going on whenever someone changes code is that they make a 'derivative work'," began Theodore Ts'o. "Whether or not you can even make a derivative work, and under what terms the derivative work can be licensed, is strictly up to the license of the original. For example, the BSD license says: 'redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met....' Note the 'with or without modification'. This is what allows people to change BSD licensed code and redistribute said changes." Regarding code that is GPL'd, he added, "it is not a relicencing, per se, since the original version of the file is still available under the original copyright; it is only the derived work which is under the more restrictive copyright."

Disagreement continued as to whether or not the BSD license allows the addition of new copyrights on unmodified or minimally modified code. Another disagreement was over the continued existence of improperly licensed files in developer source code repository histories from when BSD licensed files had been changed to the GPL, a problem since fixed. Jeff Garzik explained:

"In a purely open development environment, even personal developer trees are made public. That's the way we _want_ development to occur. Out in public, with a full audit trail. Your implied ideal scenario is tantamount to guaranteeing that mistakes are never committed to a public repository anywhere. Mistakes will happen. Even legal mistakes. In public.

"What you are seeing is an example of mistakes that were caught in review, and corrected. That's how any scalable review process works... the developer reviews his own work. the team reviews the developer's work. the maintainer reviews the team's work. the next maintainer reviews. and so on, to the top."

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

"BACK UP ANY IMPORTANT DATA," began the Linux 0.10 installation instructions. "Linux accesses your hardware directly, and if your hardware differs from mine, you could be in for a nasty surprise. Doublecheck that your hardware is compatible: AT style harddisk, VGA controller." The installation guide explained that there were five major steps in getting Linux installed and running on your computer, including the above first step of backing up the system. The second step was to use Minix and the mkfs command to create a new filesystem on an empty partition of your hard drive. Third you used dd to write the 'boot' and 'root' Linux disk images to floppy disks. The fourth step was actually booting from the floppies, "having a floppy as root-device isn't very fast (especially on a machine with less than 6MB total ram -> small buffer cache), but it works (I hope)." The final step was mounting the empty hard disk partition, copying the files from the floppy disks to the partition, and creating the necessary /dev files with mknod, "you should now have a filesystem you [can] boot from. Play around a bit, try to get acquainted with the new system. Log out when you've had enough." The document noted that while it was possible to install Linux using DOS, the instructions were intended for people using Minix:

"In general, this version is still meant for people with minix: they are more used to the system, and can do some things that DOS-based persons cannot. If you have only DOS, expect some troubles. As the version number suggests, this is still not the final product."

Theodore Ts'o posted an update on the ext4 filesystem [story], "I've respun the ext4 development patchset, with Amit's updated fallocate patches. I've added Dave's patch to add ia64 support to the fallocate system call, but *not* the XFS fallocate support patches. (Probably better for them to live in an xfs tree, where they can more easily tested and updated.) Yes, we haven't reached complete closure on the fallocate system call calling convention, but it's enough for us to get more testing in -mm." Jeff Garzik noted that none of this development was happening in the kernel as originally planned, "why isn't this stuff going upstream rapidly? AFAICT nothing much at all has happened upstream besides a mass renaming? The whole point of having ext4 in the kernel is to do development upstream, in the public view, getting new stuff in ASAP (even if that means changing or pulling some stuff later)."

Theodore acknowledged, "in general, yes, ext4 development has been a little slow; part of the problem is that we have a lot of people, but a number of folks are new and their patches need review before they are ready for upstream acceptance, and a number of other folks who should be doing the review have been overloaded with multiple other projects and have been time-sharing." He went on to note, "but we also get flamed when the patches don't meet various criteria, up to and including breaking on ia64. We are in the process of setting up automated testing to help address that problem, but it's a taken a little while to get that going. I'm also trying to schedule more time so I can do the needed review of the patches so they meet basic upstream standards so we *can* push them. If other folks would like to help with the review process, that would be more than welcome. But yes, we will try to get more of the patches pushed sooner rather than later."

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

The discussion about why the Reiser4 filesystem has not been merged into the Linux kernel [story] continues on the lkml. Hans Reiser [interview] contrasted the struggles Reiser4 has had trying to get merged versus recent discussion about the up and coming ext4 filesystem [story], "the code isn't even written, benchmarked, or tested yet, and it is going into the kernel already so that its developers don't have to deal with maintaining patches separate from the tree. Wow. Kind of hard to argue that it is not politically differentiated, isn't it?"

Theodore T'so responsed, "it is a development procedure that was developed after discussion and consensus building across LKML and the ext2/3/4 development team. It was not the original plan put forth by the ext2 developers, but after listening to the concerns and suggestions, we did not question the motives of the people making suggestions; we listened." He went on to note that parts of what will be ext4 were written a year ago, and have been heavily tested and reviewed. Others pointed out that the evolution between ext3 and ext4 will be a very public process, with patches being merged gradually, whereas Reiser4 is a completely different code base from Reiser3.

The latest chapter in this ongoing debate tends to be more about clashing personalities than the code in question. How this affects if and when the Reiser4 filesystem will be merged into the mainline Linux kernel is yet to be seen.