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 lists. 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 the MAINTAINERS file.

  • 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 master 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 queue 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 tree 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 on kernel.org. 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 patchwork instance.