Role of a Linux Kernel Maintainer

At LinuxCon Japan a few weeks ago I gave a talk entitled, “Linux Kernel Maintainers, What they do and how you can help them.”

The video of the talk is now online here if you want to see what I said, and the full slides, and text of what I said can be found in the presentation’s repository.

If you have ever wondered why a maintainer of an open source project could be a bit grumpy about anything you have sent them, I strongly suggest you go read the notes I wrote for that talk, or the slides, which includes all speaker notes.

Also, if you ever want to know what to do, in order to get your patches accepted, please go read the slides, I’m not going to repeat the information here.

Well, with one exception.

But first, it seems that this talk has kicked off a bunch of discussion. First off was Jake Edge’s excellent summary of the talk on lwn.net, which kicked off a bunch of comments by people who didn’t seem to have read the slides, or seen the talk, but it sparked a bunch of interest anyway, as everyone likes watching when people argue.

Then Jon Corbet weighed in on the topic of mocking which was a very good summary of some of the issues involved when maintainers of open source projects are overwhelmed by bad submissions, or just beaten down by constantly having to answer the same questions every single week, and no one seeming to read documentation where things like that are answered. Again, highly recommended, go read both of them, and the comments for the articles.

(What, you aren’t a lwn.net subscriber? Why not! Shame on you, go fix that right now.)

After that, the Linux Kernel Summit Call For Participation went out, and lots of the proposals that are being submitted deal with maintainers, our workloads, and how we can handle the issues involved. Go read them here for an idea of what we are currently grappling with if you are interested.

The part I wanted to repeat from my talk is this, what I, as a Linux kernel subsystem maintainer pledge to kernel developers who send me patches for the various parts of the kernel that I maintain:

• I will review your patch within 1-2 weeks (see details below).
• I will offer semi-constructive criticism of your patches.
• I will let you know the status of your patch if it is rejected, or if it is accepted, what tree it has gone into, where you can find it, and when you can expect to see it merged into Linus’s tree.

That’s it. And from you, I expect to get well-formatted, fully documented, cleanly applying patches that do useful things, and everyone involved will be happy, right?

Note about 1-2 week response time:

Of course, if I’m sick, or traveling on insane Asia trips, my response time will be delayed, but feel free to email me asking the status of a patch you have sent me, I’m happy to respond back that I just haven’t gotten to it. I would much rather field these kinds of inquiries (after waiting a few weeks) then loose patches and make people mad.

Also, consider the kernel merge window requirements, during the merge window, I can’t accept new patches into my tree that are not bugfixes for this specific kernel release, so that means there is usually a 3 week window starting about 1 week before Linus’s release, lasting until after a -rc1 kernel is released, before I can get to your patch. During that time period hundreds of patches accrue, so please give me some time to dig out from all of them. Usually by -rc3 I’m caught up, if not, email me and ask.