I’ve griped before about kernel development being scattered and spread about.
A quick grep of MAINTAINERS shows over 200 git trees and even more mailing
Today’s discussion is a partial enumeration of some common mailing lists, git
trees and patchwork instances. You can certainly find some of this in
LKML. The main mailing list. This is the one everyone thinks of when they
think ‘kernel’. Really though, it mostly serves as an archive of everything
at this point. I do not recommend e-mailing just LKML with no other lists or
people. Sometimes you’ll get a response but think of it more as writing to
your blog that has 10 followers you’ve never met, 7 of which are bots. Or your
twitter. There is a patchwork
instance and various mail archives out there. I haven’t found one I actually
like as much as GMANE unfortunately. The closest corresponding git tree is the
where all releases happen.
The stable mailing list. This is where patches go to be picked up for stable
releases. The stable release have a set of rules
for how patches are picked up. Most important is that the patch must be in
Linus’ tree before it will be applied to stable. Greg KH is the main stable
maintainer. He does a fantastic job for taking care of the large number of
patches that come in. In general, if a patch is properly tagged for stable yes
it will show up eventually. There is a tree for his
of patches to be applied along with stable git trees
Linux -next. This is the closest thing
to an integration tree right now. The goal is to find merge conflicts and bugs
before they hit Linus’ tree. All the work of merging trees is handled manually.
Typically subsystem maintainers have a branch that’s designated for -next which
gets pulled in on a daily basis. Running -next is not usually recommended for
anything more than “does this fix your problem” unless you are willing to
actively report bugs. Running -next and learning how to report bugs is a
great way to get involved though. There’s a tree
with tags per day.
The -mm tree. This gets its name from memory management but really it’s
Andrew Morton’s queue. Lots of odd fixes end up getting queued through here.
Officially, this gets maintained with quilt. The tree for -next “mmotm” (mm of
the moment) is available as a series.
If you just want the memory management part of the tree, there’s a tree
available for that.
Networking. netdev is the primary
mailing list which covers everything from core networking infrastructure to
drivers. And there’s even a patchwork
instance too! David Miller is the top level networking maintainer and has a
for all your networking needs. He has a separate -next tree.
One thing to keep in mind is that networking patches are sent to stable in
batches and not just tagged and picked up by Greg KH. This sometimes means a
larger gap between when a patch lands in Linus’ branch and when it gets into
a stable release.
Fedora tree. Most of the git trees listed above are “source git/src-git”
trees, meaning it’s the actual source code. Fedora officially distributes
everything in “pkg-git” form. If you look at the official Fedora kernel
repository, you’ll see it
contains a bunch of patches and support files. This is similar to the -mm and
-stable-queue. Josh Boyer (Fedora kernel maintainer emeritus) has some
scripts to take the Fedora pkg-git and put it
This gets updated automatically with each build.
DRM. This is for anything and everything related to graphics. Most everything
is hosted a freedesktop.org, including the mailing list.
Recently, DRM has switched to a group maintainer model (Daniel Vetter has
written about some
of this philosophy before). Ultimately though, all the patches will come
through the main DRM git repo. There’s
a DRM -tip for -next like testing
of all the latest graphics work. Graphics maintainers may occasionally request
you test that tree if you have graphics problems. There’s also a
Source From: fedoraplanet.org.
Original article title: Laura Abbott: Fantastic kernel patches and where to find them.
This full article can be read at: Laura Abbott: Fantastic kernel patches and where to find them.