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
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.
to post comments)