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.