July 10, 2013
Participants: Steven Rostedt, John W. Linville, Rafael J. Wysocki, NeilBrown, Theodore Ts'o, David Woodhouse, Jason Cooper, H. Peter Anvin.
People tagged: (none)
Steven Rostedt noted that the recent loss of Seth Vidal should remind us that life is uncertain, and can end at any time. Steven argues that maintainers should therefore have backups (as Linus himself suggested a few years back), and communities should have plans in place to enable the show to go on. In addition, there should be provisions to handle cases where maintainers are temporarily incapacitated, possibly with predefined limits on what their understudies are permitted to do in the meantime.
Olof Johansson agreed that it is good to prepare for worst-case scenarios, and further noted that backup maintainers are useful in more normal circumstances, including vacations and intense short-term projects that might otherwise interfere with maintainership duties. Olof and Arnd Bergmann have had good success co-maintaining the arm-soc tree, albeit with some occasional switchover latency. Olof points out that having others step up and help out with reviews can be a good start towards co-maintainership. Jason Cooper, hobbyist maintainer, notes that he relies heavily on others to do code review and testing, and is hoping to get them access to the git tree he uses to allow them to help more directly with the maintainership role. Jason also attests to Olof's and Arnd's co-maintainership skills, as they are his upstream maintainers. H. Peter Anvin also vouched for co-maintainer teams.
Rafael J. Wysocki pointed out that the need is not only for maintainers, but also for a critical mass of people who are familiar with the code. Without naming names, Rafael noted that there are pieces of code in the kernel for which we have only one knowledgeable person or perhaps only a few who are extremely busy, a fact that he finds to be less than comfortable. Paul E. McKenney listed some things that he has been doing to increase the number of potential RCU maintainers. David Woodhouse chose to see the glass as half full, arguing that there are not many parts of the kernel that could not be understood by good kernel hackers willing to put their minds to it, and further arguing that the Linux kernel's consistent design and coding style is a big help.
NeilBrown suggests that this topic is related to the depth of maintainers tree proposed by Jan Kara, arguing that a lower-fanout hierarchy would allow maintainers to better track their sub-maintainers' code. Neil also argues for a focus on community health instead of on preparing for tragedy, especially given his doubts about the appeal of an “assistant maintainership” position.
Theodore Ts'o
is also hesitant about people being formally named as successors to a given
maintainer, arguing that the MAINTAINERS file can grow stale,
that updates can result in both hurt feelings and political drama.
Ted notes that this is one reason why the Linux kernel community does not have
a formally designated “core team”, even though most people
have a pretty clear idea who the core developers are.
However, Ted does advise maintainers to made sure that there are other
people who know enough that they could take over, and joins with Olof
in suggesting that getting others to do reviews can help build a stable
of maintainer-capable people.
Finally, Ted pointed to the example of
Leonard Zubkoff, who was
among other things the Linux kernel's BusLogic and DAC960 maintainer
when his life was cut short by a helicopter crash.
H. Peter Anvin
agreed, giving as an example a non-kernel open-source project where
he appointed a successor who did just enough work to prevent the project
from forking, causing it to instead die a long slow death.