Takashi Iwai: Guidance for subsystem maintainers

May 13, 2014

Participants: Jason Cooper, Jiri Kosina, Josh Triplett, Laurent Pinchart, Linus Walleij, Mark Brown, Mauro Carvalho Chehab, Olof Johansson, Sarah A Sharp, and Stephen Warren.

People tagged: Andrew Morton and Linus Torvalds.

Takashi Iwai noted different communication styles across different subsystems, and wondered if some baseline guidance would help casual developers. Jiri Kosina is concerned that forcing a given working style on all maintainers was destined to fail, pointing out that even git is not universally used. Sarah A Sharp argued that the real issue was not the technical workflow, but rather the social norms of maintainership. Sarah added that these norms vary depending on (for example) the level of confidence that a given maintainer desires before queueing a patch, so that some maintainers queue quickly and resolve bugs during the next -rc cycle, while others do extensive testing before queueing a patch. Laurent Pinchart suggested simply documenting each maintainer's workflow, for example, whether they wanted to be explicitly CCed on patches or whether they prefer to pick up patches from their mailing list. Laurent gave the example of someone modifying drivers across the whole kernel as needing this information. Stephen Warren suggested recording this information in MAINTAINERS and having get_maintainers.pl output it. Mark Brown liked the idea of communicating best practice, and suggested the -next tree as a relatively good place to look for commits expected to show up in the next merge window. Mark also suggested that frequently reposted series of patches might eventually get ignored if significant progress was not being made. Finally, although Mark is OK with automation, he uses “artisan hand-crafted” acknowledgments of accepted patches. Jason Cooper suggested tip-bot, but via a link that is not uniformly accessible.

Josh Triplett noted that social problems can in fact have technical solutions, calling out Linus's switch to bitkeeper and then to git as examples. Josh reiterated the difficulty of submitting patches implementing a cross-subsystem change: some get merged immediately with an email acknowledgment, others get merged with no notification, some disappear completely until they suddenly appear in Linus's tree a couple of version later, and still others disappear permanently. Josh reported being sometimes tempted to simply push such changes directly to Linus, but suggested the alternative of automating the responses based on git hooks. Jiri Kosina and Linus Walleij liked the idea of automating the interaction. Olof Johansson avoids some of these problems in the arm-soc tree by merging these sorts of topic branches, and then having other maintainers base their work on these merges, or, alternatively, merging the work of these other maintainers. Mauro Carvalho Chehab suggested use of Acked-by: tags by maintainers to acknowledge that a given patch would be merged elsewhere, and indicating a given maintainer's willingness to help resolve merge conflicts. Josh Triplett agreed that Acked-by: tags are useful, but said that he didn't always get them. Josh also felt that automation didn't really require discussion at Kernel Summit, but rather just needed doing.

Takashi Iwai clarified that he was most concerned with making it easier for people to learn how they should go about submitting a patch to a given subsystem. He believes that the choice of patch-collection technology and communication style should be a free choice.