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."
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
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
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
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
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.