KS2012: Improving the maintainer model

Trond Myklebust led a discussion on day one of the 2012 Kernel Summit on how to improve the kernel maintainer model. He started with a comment from Thomas Gleixner that for 21 years the kernel development community has focused on scaling Linus, but has been rather slower in scaling the subsystem maintainer role. By this time, Linux is no longer a hobbyist project, and after 21 years it's probably time to focus more on scaling the maintainer role.

Trond noted that the kernel maintainer role is a mishmash that includes software architect, developer, reviewer, patch monkey, and software maintainer. In the context of a corporate project, these roles are typically held by multiple people. Trond noted that the maintainer role is to some extent already informally split, since we have reviewers, bug fixers, developers, and so on. However, he was interested to know whether it makes sense to give maintainers greater freedom to (formally) split out some of these roles, and if so, he requested that there should be a mechanism for formally recognizing this in the community (for example, via suitable annotation in the MAINTAINERS file).

One of the participants asked: what barriers keep somebody from taking on some of a maintainer's work? In response, Ted Ts'o indicated that there is no simple answer to that question, noting that kernel developers tend to set a higher bar for people with whom they have no history, whereas they set a lower bar (in terms of the kinds of changes that they permit) for people who have demonstrated a longer-term commitment to the code. "It's a human nature thing."

The conversation meandered over various topics. Along the way, Paul Gortmaker noted that the Documentation/SubmittingDrivers file could do with an update to align with current practices. Dave Jones noted that, likewise, REPORTING-BUGS could do with an update. In amongst the other discussion Linus noted that code that needs to go into two subsystems should be placed in a tree of its own that both subsystems can pull from, since the alternative (placing the code in one of the trees) create confusion when dealing with patches.

The discussion did not reach any definite conclusions about the maintainer role. However, it's clear that several maintainers are conscious that just as there was a need to improve Linus's scalability several years ago, the ever-increasing scale of the Linux kernel project means that now the subsystem-maintainer role could do with some scalability improvements of its own.