[
Editor's note: Greg Kroah-Hartman has graciously agreed to write an
occasional column for LWN in which he answers questions that readers may
wish to ask of the kernel development community. Greg will do a great job,
but the key to a successful column will be good questions; please come up
with your best and send them in.]
Hi, and welcome to a new semi-weekly column. In here, we are going to
try to answer your common questions about Linux kernel development.
This column will rely on the readers to submit new questions to be
answered either here in comments, or by email to greg@kroah.com, with
the understanding that not all questions can be answered.
Valid topics can range from the technical, to the procedural, or on
toward anything remotely related to the Linux kernel that you can think
of.
To start it off, I've provided a few "seed" questions that I get asked a
lot, and would like to finally answer in one place so I don't have to do
it again.
Why is the 2.6.27 kernel still being maintained while the newer
2.6.29 kernel is no longer getting updates?
The Linux kernel stable series strives to only maintain one kernel tree
at at time, the most recent one, with a small overlap of a release or
two when a new kernel is released. So for right now, as the 2.6.31
kernel was just released, both the .31 and .30 trees are being updated.
After the next release of the .30 stable tree, it will be abandoned, and
only the .31 tree will be updated with security and bug fixes.
But some kernel trees are a bit "special". The 2.6.27 kernel looked
like a good kernel to maintain for a longer period of time. Some users
have reported that they like to remain on one kernel version for longer
than 3-4 months, so the 2.6.27 kernel tree will try to be a tree that
they can rely on to get security and bug fixes for a longer time frame.
As the 2.6.27 kernel was first released on October 9, 2008, there has
almost been a full year of support for this kernel so far.
After I get tired of maintaining this kernel branch, Adrian Bunk has
volunteered to maintain it even longer, so in another year or so,
maintenance will switch over to him, and it will continue to live on.
How do I get a patch included in the stable kernel updates?
First off, take a look at the file
Documentation/stable_kernel_rules.txt to
verify that the patch you are
considering meets the rules for a stable kernel release. If it does,
the easiest way to get it included is to add a:
Cc: stable <stable@kernel.org>
line to the Signed-off-by: area in the patch before it is sent to the
subsystem maintainer. When a patch with that line in it is accepted
into Linus's kernel tree, the stable team will be automatically notified
that the patch should be included, and they will queue it up for the
next stable kernel release(s).
If you notice a patch that you feel should be included in the stable
release, and does not have this marking, and is already in Linus's tree,
a simple email to the stable@kernel.org address with the git commit id
of the patch in Linus's tree and a short description of which stable
kernel releases you feel it should be included in is all that is needed.
So bring on the questions!
(
Log in to post comments)