Daniel Vetter: community management/subsystem governance

September 10, 2018

Related Material:

  1. Kernel community management.
  2. Too many lords, not enough stewards.
  3. LCA Sydney: Burning Down the Castle.
  4. Why Github can't host the Linux Kernel Community.
  5. Why fd.o admins picked gitlab.
  6. Succession Planning: Is It time to Throw Linus Under a Bus? (summary).

LWN QoTW:

But the trick in making CI really effective is to make it about as addictive as a slot machine. Instant gratification and quick results is absolutely key, and developers want to watch it do its things. The more you can give them that, the more your developers will care about CI results (the green checkmark quickly starts to look like candy in your eyes), and the less maintainers have to check this themselves.

— Daniel Vetter

Additional Participants: Alexandre Belloni, Darren Hart, Dave Airlie, Geert Uytterhoeven, Guenter Roeck, James Bottomley, Jani Nikula, Jiri Kosina, Josh Triplett, Konstantin Ryabitsev, Laurent Pinchart, Leon Romanovsky, Linus Torvalds, Linus Walleij, Mark Brown, Maxime Ripard, Olof Johansson, Rafael J. Wysocki, Sasha Levin via Ksummit-discuss, Sean Paul, Theodore Y. Ts'o, Thomas Gleixner.

Daniel called out a community-management blog post by Laura Abbott, stating that he is particularly interested in new experiments in group maintainership, and sharing lessons learned as well. He also suggested that changing governance one subsystem at a time would be better than attempting to do a big-bang change of the whole kernel. Linus weighed in suggesting that different parts of the kernel will need different community-management models, that the discussion focus on specific situations where something bad happened (with which Daniel and Olof Johansson agreed, with Daniel providing more detail on his thoughts), and keeping in mind the effects of scale (but still learning from small freewheeling projects where applicable). Finally, Linus suggested a “Live without email - possible?” topic.

Patches without Email - Possible?

James Bottomley suggested that Linus's “Live without email - possible?” become “Patches without Email - Possible?”, a suggestion that Linus agreed wholeheartedly with, recalling the pre-Bitkeeper “patchbomb” development model with negative nostalgia. James clarified that he still likes email for discussions, and laid out three issues:

  1. How do reviews happen? Review mechanism (e.g., gerrit)? One choice, or per-subsystem choice?
  2. Should we make use of core reviewers and make acceptance dependent on actually getting reviews? And might this finally get reviewers the credit that they deserve?
  3. How are pull requests delivered to Linus?

Sasha Levin agreed that email was great for discussions, but noted that it can be difficult to locate the discussion that led up to a given patch. He does not feel that the addition of LKML links to commit logs is helping all that much. James disagreed, arguing that this was usually a simple matter of web searching. Sasha replied that the discussion is not necessarily localized, nor is it necessarily nicely packaged into a single LKML thread. Although Sasha agreed that grepping through mailboxes can work, he feels that it is problematic when adding a large number of fixes to a -stable release. This debate continued here, here, and here.

Konstantin Ryabitsev pointed out crget as a tool to track information about kernel code as it can from various places. Much discussion on crget and patchwork followed, with positives and blemishes for each. Challenges included the evolutionary and versioned nature of patches, newcomers and sporadic contributors becoming confused by per-subsystem processes, github/travis shortcomings, and stable tags. Olof pointed out the need to avoid linkrot, for example, via the canonical LKML email services based on message-id.