KernelTrap - 2.6.11

Linux: 2.6.12 Available, The First Git Release

Jeremy — Sat, 18 Jun 2005 17:07:10 +0000

Nearly three and a half months since the last stable release, Linus Torvalds announced the availability of version 2.6.12 of the Linux Kernel. He notes that the changes since -rc6 are minimal, "as you can see from the appended diffstat, most of the things are pretty small (ie it looks like a long list, and then you look at the diffstat and realize that most of the changes end up being just a line or two)." He adds, "one of the least important changes is still worth pointing out," talking about the recent update to the Developer's Certificate of Origin [story]. "The sign-off procedure was clarified to make it clear that the person signing off understands that the project - and thus the patch and the sign-off itself, of course - is public and will be archived."

This is the first stable release of the Linux kernel since the source code was moved out of BitKeeper in early April of 2005 [story]. 2.6.12-rc3, released in late April, was the first release candidate kernel managed by Git [story], thus Linus' git repository only holds changes since 2.6.12-rc2. Due to this fact, Linus did not release a complete changelog between 2.6.11 [story] and 2.6.12. He explains, "the full ChangeLog ended up missing, because I only have the history from 2.6.12-rc2 in my git archives, but if you want to, you can puzzle it together by taking the 2.6.12 changelog and merging it with the -rc1 and -rc2 logs in the testing directory." The latest version of the Linux kernel can be obtained directly from the kernel.org archive [story], or your nearest kernel archives mirror.

Linux: Defining Stable Trees, 2.6.11.2 Released

Jeremy — Wed, 09 Mar 2005 13:17:01 +0000

Greg KH and Chris Wright continue to finalize how the -stable Linux kernel tree will work in an email Greg described as, "everything you ever wanted to know about Linux 2.6 -stable releases." Provided as patches against the last official 2.6.x release, the -stable branch uses 2.6.x.y numbering. The list of requirements for includable patches [story] has been further refined, while a proceedure for submitting patches, specifics for a review cycle, and mention of a review committee were added. New patches will generally be in review for 48 hours before the patch is added to the -stable tree. If any single member of the review committee votes against the patch, it will be dropped from the queue and not included in a stable release. Greg explains that the review comittee is made up of "a number of kernel developers who have volunteered for this task, and a few that haven't." Security patches are accepted directly from the kernel security team [story], bypassing the normal review cycle.

This announcement was quickly followed by the release of 2.6.11.2. Greg explained, "it contains one patch, which is already in the -bk tree, and came from the security team (hence the lack of the longer review cycle)." The changlog describes the event poll fix as, "return proper error on overflow condition".

Linux: 2.6.11.1 Released, Stabilizing 2.6.11

Jeremy — Sat, 05 Mar 2005 20:32:37 +0000

Greg KH announced the first maintenance release of the 2.6.11 kernel [story], 2.6.11.1. Quickly acting on the recent lengthy discussion regarding kernel release numbering [story] [story], Greg and Chris Wright have begun to maintain this branch. With each 2.6.x release, they will maintain 2.6.x.y releases available from your nearest kernel.org mirror. This first maintenance release includes three simple patches, not including the makefile change, addressing a problem with keyboards on Dell machines, and raid6 compilation on the ppc architecture. Andrew Morton [interview] noted that he has additional fixes appropriate for this tree that will likely lead to a 2.6.11.2 release in the relatively near future.

Greg went on to highlight the requirements for patches to be able to be merged into this new tree: they must be no bigger than 100 lines, they must fix only one thing, they must fix real bugs that are confirmed to be affecting people, and they must fix a build error, an oops, a hang, or a real security issue. Patches explicitly not allowed include things to fix "theoretical race conditions" without an exploit, or "trivial" fixes like spelling changes or whitespace cleanups. Greg described the effort's mantra as "release early and often".