The git directory content manager was born in early April of 2005 [story], less than a week after the announcement that BitKeeper would no longer be available free of charge to kernel developers [story]. The tool was originally written by Linux creator Linus Torvalds, and rapidly evolved with the help of an active developer community which Linus repeatedly noted he hoped would eventually take over [story]. A scant two months after development on the tool began, the 2.6.12 kernel was released, managed by git [story].

Now, Linus has announced that Junio Hamano is the new git maintainer. "I always said I didn't really want to maintain it in the long run," Linus explained, "and maybe some of you thought I was just saying that, especially as the weeks dragged out to over three months, but hey, that's just because this thing ended up being a bit bigger and more professional than I originally even envisioned." He went on to note that Junio was the obvious choice, and that this change means he will be able to return his full focus to the Linux Kernel mailing list.

Junio thanked those involved, described his development methods, and discussed the upcoming 1.0 release. Regarding 1.0, he suggested that all features are in, and that he is primarily looking for bugfixes and documentation updates. Following the announcement, Ryan Anderson posted an updated "Git 1.0 Synopis", a brief overview of the tool and its features. His document begins, "Git, sometimes called 'global information tracker', is a 'directory content manager'. Git has been designed to handle absolutely massive projects with speed and efficiency, and the release of the 2.6.12 and (soon) the 2.6.13 version of the Linux kernel would indicate that it does this task well."

Following SCO's allegations regarding the origination of some source code files comprising the Linux Kernel, in May of 2004 Linux creator Linus Torvalds implemented a simple method for tracking how patches reach the source tree [story]. The simple system was further refined in the following months [story], and has become second nature to most kernel developers. However, a recent debate on the lkml illustrated the fact that nothing is simple, in this case with concerns that archiving someone else's email address in the "Signed-off-by:" line could violate the UK's Data Protection Act.

Alan Cox [interview] suggested that to solve for this concern, the DCO, or Developer's Certificate of Origin, be updated to explicitly give permission to include an email address when archiving patch information. Linus agreed, "yes, I'll update the SubmittingPatches [documentation file] to state explicitly that the sign-off is a public record." Alan pointed out that adding a comment to the file alone is not enough, but that the new wording needs to be part of the DCO, "you have to -actively- agree to the DCO to submit a change, and that is what makes it work (whether you put something in submitting patches or not that is more explanatory)." Again, Linus agreed, "I'll also run it past the OSDL lawyer, and if others were to run it past their lawyers, that would be good." Once approved, the update will become version 1.1 of the DCO.

The Linux Kernel Archives are perhaps most familiar through their web interface, http://kernel.org/. The latest release of the Linux kernel is easily found here, along with patches by various Linux kernel hackers, and mirrors of other popular free and open source projects. Countless people worldwide happily rely on this archive without giving much thought to the effort behind it.

In a recent announcement to the Linux Kernel Mailing List, H. Peter Anvin detailed a recent upgrade of the infrastructure behind kernel.org. The new servers were donated by Hewlett-Packard, and are each quad Opterons with 24 gigabytes of RAM and 10 terabytes of disk space. Internet Systems Consortium, Inc. donates the bandwidth in the form of two independent gigabit-connected datacenters, PAIX Palo Alto and e200paul in San Francisco. H. Peter Anvin, Nathan Laredo, and Kees Cook all donate time to maintain the archives. KernelTrap recently spoke with Peter Anvin to learn more about the history behind the Linux Kernel Archives.

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

Linus Torvalds began working on an interim solution called "git" in the absence of BitKeeper [story]. A README included with the source describes it as, "a stupid (but extremely fast) directory content manager. It doesn't do a whole lot, but what it _does_ do is track directory contents efficiently." The documentation goes on to describe two abstractions used by the tool, an "object database", and a "current directory cache". Objects in the object database are referred to by the SHA1 hash of their zlib compressed contents. The various supported object types include, "blobs" which are simply binary blobs of data with no added verification, "trees" which are lists of objects sorted by name, and "changesets" which provide a historical view of an object describing "how we got there, and why". The current directory cache is a binary file "which contains an efficient representation of a virtual directory content at some random time."

During the discussion regarding git and its rapid evolution, Linus explained, "in many ways you can just see git as a filesystem - it's content- addressable, and it has a notion of versioning, but I really really designed it coming at the problem from the viewpoint of a _filesystem_ person (hey, kernels is what I do), and I actually have absolutely _zero_ interest in creating a traditional SCM system." As for actual usage, Linus noted, "I think we can make the workflow look like bk, ie pretty much like "git pull" and "git push". And for well-behaved stuff (ie minimal changes to the same files on both sides) it will even be fast. I think." Read on for much of the resulting discussion which provides a fuller understanding of how the evolving tool will work.

Linus Torvalds offered an explanation to the lkml of the recent decision to switch away from using BitKeeper to manage the Linux kernel [story]. He began, "as a number of people are already aware (and in some cases have been aware over the last several weeks), we've been trying to work out a conflict over BK usage over the last month or two (and it feels like longer ;). That hasn't been working out, and as a result, the kernel team is looking at alternatives." He continued on to thank Larry and BitMover for their efforts in trying to make things work. He added, "NOTE! BitKeeper isn't going away per se. Right now, the only real thing that has happened is that I've decided to not use BK mainly because I need to figure out the alternatives, and rather than continuing "things as normal", I decided to bite the bullet and just see what life without BK looks like. So far it's a gray and bleak world ;)"

Citing the fact that his three years of BitKeeper usage have helped him to improve how he works on the kernel, he added, "so I just wanted to say that I'm personally very happy with BK, and with Larry. It didn't work out, but it sure as hell made a big difference to kernel development. And we'll work out the temporary problem of having to figure out a set of tools to allow us to continue to do the things that BK allowed us to do." As for what tool was likely to replace BitKeeper, Linus offered, "don't bother telling me about subversion. If you must, start reading up on 'monotone'. That seems to be the most viable alternative, but don't pester the developers so much that they don't get any work done. They are already aware of my problems ;)"

BitKeeper was first utilized by a Linux project in December of 1999, when it was employed by the Linux PowerPC project. Then in February of 2002, Linux creator Linus Torvalds decided that BitKeeper was "the best tool for the job" and started using it to manage the mainline kernel, an event that received much attention in the free and open source communities [story], and beyond. BitMover, the company behind BitKeeper, was founded by its current CEO, Larry McVoy [interview], who originally conceived of BitKeeper as a tool to keep Linus from getting burnt out by the growing task of managing the Linux Kernel. Since Linus began using the tool three years ago, the pace of Linux kernel development has doubled [story].

There are two definitions for the word "free" that are commonly used to describe software. The first is "Free as in Freedom", and the other is "Free as in Free Beer". BitKeeper was made available freely under the latter definition, allowing free and open source software developers to use the tool without having to pay any money. It was provided under the agreement that anyone actively using the free tool would not develop a competing product at the same time. In other words, the aim was to provide a tool that could be freely used, but not freely cloned. At the same time, a more advanced version of BitKeeper has been sold commercially, and both products remain the intellectual property of BitMover.

A vocal group has long protested Linus' use of BitKeeper, considering Linux the free and open source flagship product. GNU Project founder Richard Stallman [interview] is among the protestors, harshly criticizing Linus' decision to use a non-free (as in freedom) tool [story]. However, most acknowledge that no free tool currently exists that is as powerful as BitKeeper, offering the ability to perform truly distributed development. Attempts to reverse engineer some of BitKeeper's features have lead to repeated cautions by BitMover. Most recently two such reverse engineering attempts have contributed to BitMover's decision to end the development and availability of the free BitKeeper product.

Linux creator Linus Torvalds started a lengthy discussion on the lkml regarding release numbering for the Linux kernel. Some have complained about kernel stability with the new development model discussed back in mid-2004 [story] in which active development occurs in the "stable" 2.6 kernel. In his recent email, Linus explained, "the problem with major development trees like 2.4.x vs 2.5.x was that the release cycles were too long, and that people hated the back- and forward-porting. That said, it did serve a purpose - people kind of knew where they stood, even though we always ended up having to have big changes in the stable tree too, just to keep up with a changing landscape." His new proposal involves still using an even and odd numbering scheme, but on a smaller level. Thus, the upcoming 2.6.12 would be "stable" in that it should only contain bugfixes over 2.6.11. Then 2.6.13 would be more development oriented, including some larger changes. These larger changes would again stabalize in 2.6.14, and so on. He adds, "we'd still do the -rcX candidates as we go along in either case, so as a user you wouldn't even _need_ to know, but the numbering would be a rough guide to intentions. Ie I'd expect that distributions would always try to base their stuff off a 2.6.<even> release."

The lengthy discussion that followed was a collection of mixed reactions. Some liked the proposal, but others were confused as to what it was supposed to solve. Essentially the idea seems to be to get more people to test the kernel, as only with more testers can bugs be found. The current strategy of using a series of "-rc" kernels [story] is confusing to many as in most projects this indicates a "release candidate", or something thought to be stable, whereas with the Linux kernel an -rc release is frequently where the active development takes place. As the common user has come to realize this, the -rc kernels have gotten less testing. Linus says, "that's the whole point here, at least to me. I want to have people test things out, but it doesn't matter how many -rc kernels I'd do, it just won't happen. It's not a 'real release'." Andrew Morton [story]'s -mm tree is intended to weed out obvious errors with big changes before merging patches upstream in the mainline kernel, but again as it frequently proves less stable it tends to get less testing.

Three years after Linux creator Linus Torvalds began using BitKeeper to manage the Linux kernel source tree, debates have continued to spring up on the Linux kernel mailing list [story]. A BitKeeper press release from nearly a year ago claims that the move has resulted in doubling the pace of Linux kernel development, a claim examined in a later two part interview on NewsForge from last May, including comments from Linus and Larry McVoy [interview]. In spite of this significant boost in productivity, there remains a group who vehemently oppose Linus' choice to use BitKeeper.

In a recent thread, Larry noted that the version of BitKeeper in use by Linux kernel developers uses an unsigned short to count changesets, and that in about 100 days the number of changesets in the Linux kernel source tree will grow too large to fit in this variable. A new version of BK will soon be released to allow developers to continue to work even after this 64 thousand changeset boundary is reached. While explaining this, Larry also noted that there was a plan to update the BK license to provide a more precise definition of what is and what is not allowed. Specifically, as is, the license requires that you agree to not work on another SCM product if you use or have used the free BK product. Larry explains, "we've had some people who have indicated that they believed that if they used BK they were agreeing that they would never work on another SCM system. We can see how it is possible that people would interpret the license that way but that wasn't our intent. What we would like to do is change the language to say that if you use BK you are agreeing that you won't work on another SCM for 1 year after you stop using BK. But after that you would be able to hack on anything that you wanted."

Larry went on to note that the reason for this clause is to prevent people from using the free BK product, then to stop using it to work on a competing product, then to go back and use the free BK product again gathering more ideas, then to stop using it to further work on the competing product, and so on. For anyone unwilling to use BK due to its licensing, there are numerous alternative methods for obtaining up-to-date snapshots of the Linux kernel, and Linus continues to accept plain text patch files from non-BK users.

A lengthy and interesting thread was started on the lkml by Chris Wright looking to define a centralized place to report security issues in the Linux Kernel. Chris offered his services in getting things set up, addressing his email to Linus Torvalds, Andrew Morton [interview], Alan Cox [interview] and Marcelo Tosatti [interview]. He explained that he wanted to centralize the information "to help track it, make sure things don't fall through the cracks, and make sure of timely fix and disclosure". The resulting discussion was joined by numerous members of the kernel hacking community, exposing a wide range of opinions.

Linus agreed that it sounded like a good idea, but qualified this by adding, "the _only_ requirement that I have is that there be no stupid embargo on the list. Any list with a time limit (vendor-sec) I will not have anything to do with." An embargo in this case is the time period from when a security problem is first reported to when a fix can be made public. Marcelo pointed out that a certain amount of time is necessary, "for the vendors to catch up", explaining that "it is a simple matter of synchronization". Linus again stressed his dislike for the vendor-sec mailing list suggesting that at times the length of the embargo period is often more about politics than anything else. He then added, "but in the absense of politics, I'd _happily_ have a self-imposed embargo that is limited to some reasonable timeframe (and "reasonable" is definitely counted in days, not weeks. And absolutely _not_ in months, like apparently sometimes happens on vendor-sec)." In a followup comment he clarified, "btw, the only thing I care about is the embargo on the _fix_", noting that he was comfortable if there was a need to delay publishing an explanation of the security hole so long as the fix itself was quickly released.

The question was recently raised on the lkml why such a wide range of GCC [forum] versions were being actively supported by the Linux kernel. One reason offered was, "because the new compilers are a lot slower", an argument that left some perplexed. "Why is this an issue when compiling a kernel? How often do you compile your kernel?"

Linux creator Linus Torvalds agreed that the speed of the compiler was indeed one of the reasons that older versions are still supported, "for some people that is literally where _most_ of the CPU cycles go". Beyond that, he pointed out that earlier versions of the GCC 3.x compiler would generate worse code than 2.95.x, and that they were simply buggier. Linus explained, "for a _long_ time, the only reason to upgrade gcc was literally C++ support: basic C support was getting _worse_ with new compilers in pretty much every regard." He went on to add, "things seem to have improved a bit lately. The gcc-3.x series was basically not worth it for plain C until 3.3 or so."

At the July 2004 kernel summit, it was decided that the current 2.6 development process with teamwork between Andrew Morton [interview] and Linux creator Linus Torvalds was proving quite effective. The process involves using Andrew's test -mm tree [forum] as a staging area for patches prior to going into Linus' mainline tree [forum]. The system has allowed for continued evolution and new features in the 2.6 stable kernel, however it has also lead to a fair amount of discussion and debate [story]. Much of the concern is that with new features constantly being introduced, true stabilization may not be possible.

One theory presented on the lkml was that the process has changed because, "these days nobody wants to be a stable-release maintainer anymore. It's boring." 2.2 maintainer Alan Cox [story] disagreed, "that depends what kind of an engineer you are. Just as there are people who love standards body work and compliance testing/debugging there are people who care about stable trees." When asked if he was willing to maintain a stable 2.6.x kernel, Alan replied, "I'll do it if Linus wants". That is, while 2.6.10 is being developed, the suggestion is to continue to stabalize 2.6.9, releasing 2.6.9.1, 2.6.9.2, etc. And when 2.6.10 is released, to then focus on stabalizing it. Alan already maintains a 2.6-ac patchset [forum] which includes a growing number of bugfixes. However he notes that it is not intended to be all-inclusive, "the goal of -ac is to contain the stuff I personally consider important. A lot of the smaller bugfixes individually are fine but a 'complete set of bugfixes' turns into a large change set and then needs an entire validation and release cycle of its own."