"The latest feature release GIT 1.5.5 is available at the usual places," began Git maintainer Junio Hamano, adding "we kept this cycle just slightly over two months, as the previous 1.5.4 cycle was painfully tooooo long."

Git is a distributed version control system that was originally written by Linus Torvalds in April of 2005. It was written to be only a temporary replacement for BitKeeper, which Linus had been using to manage kernel source code since February of 2002. Junio Hamano took over maintainership of Git in July of 2005, and the tool has long since become quite popular outside of even Linux kernel development. Regarding the latest stable release, Junio highlighted some of the changes, including:

"Comes with git-gui 0.10.1; bunch of portability improvement patches coming from an effort to port to Solaris has been applied; 'git fetch' over the native git protocol used to make a connection to find out the set of current remote refs and another to actually download the pack data. We now use only one connection for these tasks; 'git commit' does not run lstat(2) more than necessary anymore; bash completion script (in contrib) are aware of more commands and options; a catch-all 'color.ui' configuration variable can be used to enable coloring of all color-capable commands, instead of individual ones such as 'color.status' and 'color.branch'; bash completion's prompt helper function can talk about operation in-progress (e.g. merge, rebase, etc.); 'git help' can use different backends to show manual pages and this can be configured using 'man.viewer' configuration; 'git gui' learned an auto-spell checking; 'git checkout' and 'git remote' are rewritten in C; two conflict hunks that are separated by a very short span of common lines are now coalesced into one larger hunk, to make the result easier to read."

"The following three patches are intended to start the redesign of the suspend and hibernation framework for devices," began Rafael Wysocki. He noted that the first patch introduces new callbacks for suspend and hibernation, while the other two patches implement the new suspend and hibernation callbacks for the platform and PCI bus types. In describing the first patch in the series, he noted that previous callbacks were being phased out, explaining:

"The main purpose of doing this is to separate suspend (aka S2RAM and standby) callbacks from hibernation callbacks in such a way that the new callbacks won't take arguments and the semantics of each of them will be clearly specified. This has been requested for multiple times by many people, including Linus himself, and the reason is that within the current scheme if ->resume() is called, for example, it's difficult to say why it's been called (ie. is it a resume from RAM or from hibernation or a suspend/hibernation failure etc.?).

"The second purpose is to make the suspend/hibernation callbacks more flexible so that device drivers can handle more than they can within the current scheme. For example, some drivers may need to prevent new children of the device from being registered before their ->suspend() callbacks are executed or they may want to carry out some operations requiring the availability of some other devices, not directly bound via the parent-child relationship, in order to prepare for the execution of ->suspend(), etc."

Jörn Engel posted the sixth version of patches introducing his new LogFS filesystem for flash devices to the Linux kernel. He highlighted some areas of the code that need some more work, and cc'd the appropriate people for further review. Regarding LogFS itself, he noted that one of its big advantages compared to other solutions was improved mount time and reduced memory consumption compared to other solutions, "LogFS has an on-medium tree, fairly similar to Ext2 in structure, so mount times are O(1)." He went on to add that flash is becoming more and more common in standard PC hardware, explaining:

"Flash behaves significantly different to hard disks. In order to use flash, the current standard practice is to add an emulation layer and an old-fashioned hard disk filesystem. As can be expected, this is eating up some of the benefits flash can offer over hard disks. In principle it is possible to achieve better performance with a flash filesystem than with the current emulated approach. In practice our current flash filesystems are not even near that theoretical goal. LogFS in its current state is already closer."

"I skipped the public announcements for versions 5 and 6, but here is 7 :)," noted Vegard Nossum, announcing the latest release of his kmemcheck patch, currently applying against the 2.6.25-rc8 kernel. Vegard noted he is now hoping to get the patch merged into the mainline kernel during the upcoming 2.6.26 merge window. He described the patch:

"kmemcheck is a patch to the linux kernel that detects use of uninitialized memory. It does this by trapping every read and write to memory that was allocated dynamically (e.g. using kmalloc()). If a memory address is read that has not previously been written to, a message is printed to the kernel log."

Among the changes compared to earlier releases, v7 has undergone a lot of cleanup, some preparation has begun for an x86_64 port, error reporting stability has been improved, boot time and run time options have been added, and there have been several bug fixes.

"No cute April 1st shenanigans, just a regular -rc release that happened to come up today because I was waiting for the input layer oops-fixes to be ready and tested," began Linus Torvalds, announcing the 2.6.25-rc8 kernel on April 1st. He continued, "the bulk of the fixes are the usual random one-liners. [...] A lot of the one-liners are some sparse cleanups, which is probably unnecessary noise at this point, but when Al sends me a series I just tend to apply it because his patches tend to be rather careful and basically always correct." Linus added:

"The big thing that is actually *noticeable* to most people is that this should fix the two top regressions: we've had some suspend-resume regressions due to the stupid ACPI _PTS ordering issues, and while the cleanups were left, the ordering changes were reverted. So that should fix issues for some people (of course, the people who had it fixed are unhappy, but regressions are worse). The other thing that bit a number of people and is now fixed (and that also probably often showed up as a suspend/resume regression) was some 'struct device' lifetime changes that broke the input layer. Thanks to people who debugged that one."

"I and the other Kernel.org admins would like to announce downtime for ALL kernel.org machines (this includes all of the mirror machines, the public machines and the backend master). The downtime is scheduled to start on or around April 2nd, 2008 on or around 0001 UTC," began a GPG signed message on the Linux kernel mailing list from John 'Warthog9' Hawley, one of the kernel.org admins. Referencing a recent Slashdot discussion that compared Linux and FreeBSD performance, he continued:

"After much deliberation, research and argument in #korg (along with screaming matches between HPA and I over dinner) we are upgrading the kernel.org machines from Fedora Core 5 to FreeBSD 7.0. This decision does not come lightly to the Kernel.org admins, and we would like to point out several key things that helped us form our decision:"

John concluded, "we feel that we can better serve our mirrors, our users and the community by making the switch, and we hope to have the transition done very shortly."

Following the recent announcement that UBIFS is nearly production ready, it was asked how UBIFS compares to LogFS. LogFS author Jörn Engel suggested, "both share similar design goals. Biggest difference is that ubifs works on top of ubi and depends on ubi support, while logfs works on plain mtd (or block devices) and does everything itself. Code size difference is huge. Ubi weighs some 11kloc, ubifs some 30, logfs some 8." He continued:

"Ubi scales linearly, as it does a large scan at init time. It is still reasonably fast, as it reads just a few bytes worth of header per block. Logfs mounts in O(1) but will currently become mindbogglingly slow when the filesystem nears 100% full and write are purely random. Not that any other flash filesystem would perform well under these conditions - it is the known worst case scenario."

Artem Bityutskiy replied, "I personally refuse to compare a finished FS with handles all the crucial flash features to a non-finished FS. It just makes no sense. LogFS was talked about back 2005 in Linux Kongress, but is not finished yet. Let's talk about it when it is production ready."