RFC: group maintainership for misc drm trees

[Daniel Vetter]

Hi all,

I've already chatted with some of you in private, here's the entire idea with a
bit more thought. My motiviation for group maintainership of drm-misc was that I
got a bit a guilty feeling the last few vacations/conferences when folks pinged
about reviewed/tested pretty patches not landing. But also just increasing the
bus factor and sharing the load better is good. And finally a shared misc drm
tree would allow fringe drivers to get faster into Dave's drm-next by
piggy-packing on top of the one pull request train. And it would also reduce a
bit tree proliferation (at one point we had drm-misc/-bridge/-panel/-trivial and
may more even). And at least everyone I chatted with seems to like the idea in
principle.

But what's still open is how to do it exactly. One big change with group
maintainership is that you can't rebase a tree anymore. And right now I need to
rebase drm-misc fairly often to throw out bad apples again. I think solving that
is the important bit to make a shared drm-misc work. A few ideas:

- I think CI is super-important. We're starting to finally roll that out for
  real for i915, and it's catching an awful lot of stuff already. Not yet ready
  for prime-time on public mailing lists, and for misc we probably can't test
  every patch before they land like we do for i915. But CI should have veto
  power before a pull request goes to Dave imo.

  For non-i915 Daniel Stone and others are working on ARM CI using the generic
  igt testcases for kms. And I'm open to merging driver-specific tests into igt
  too, if it makes sense, and e.g. Eric has already pushed some vc4 tests.

- Stuff needs to at least compile cleanly before pushing. I've been really bad
  at that wrt arm drivers with my own drm-misc, but turns out it's fairly easy
  to get this right: http://blog.ffwll.ch/2016/02/arm-kernel-cross-compiling.html

- Bad apples need to be kicked out with reverts, not rebases. I think that's
  fine for simple patches, and hence those can go directly to drm-misc. But a
  bunch of subsystem-wide refactorings go in through mis trees, and for those
  constantly mass-reverting until it's all solid is silly. And ime you need some
  soak time in a shared tree to iron out bugs with those kind of endeavours. We
  can address that with ad-hoc&short-lived topic branches which are then again
  owned by a single maintainer, but automatically pulled into an integration
  tree. After some soaking time to give CI systems time to crunch through those
  topic branches can then be merged into the main drm-misc and removed.

- Also we can't roll forward to latest drm-next easily with rebases any more. So
  that needs to happen either right after the pull request lands (when no patch
  has been merged meanwhile). Or with backmerges, which then need a short commit
  message as to way the backmerge is needed ("Backmerge because we need
  $feature" is what I usually type), plus sob line from the committer. And of
  course the backmerged treed must be stable/non-rebasing and preferrably the
  backmerge should be a release/pull-request tag.

- For tooling I suggest we just go with drm-intel maintainer-tools for a start.
  Picking dim has a few reasons:
  * Well tested, documented and fairly complete (includes e.g. bash-completion).
  * Integrated support for topic branches, including support for git worktree.
  * Well-exercised and robust integration tree support.
  Short-term we could add some convenience functions (e.g. for creating/merging
  drm-misc topic branches). Long-term we might or might not want to have this
  separated from drm-intel - that should be possible but a bit of work. Also,
  this way drm-misc would stay at it's current location while we figure things
  out. Longer term we might also want to look into adding other big drivers
  into an over drm integration.

Of course group maintainership needs an initial group. My experience from
drm-intel is that a bigger group of maintainer has benefits: It's clear that
part-time maintaining is ok too, with maintainers focusing on their area of
interest/expertise and only helping out in other places when there's a gap (due
to e.g. vacations). Anyway, here's my thoughts for the starting group:
Archit, Jani, Thierry & me as existing maintainers of drm-misc/bridge/panel,
Alex&Rob as maintainers of big drivers and engaged in core drm stuff,
Daniel Stone so that he has no more excuses to stall on arm drm ci.

I think if this goes well we can extend it to more driver maintainers, e.g.
Patrick would like to just push gma500 patches to some tree and not fiddle with
pull requests all the time himself.

Thoughts? Glaring ommisssions? Other topics we should discuss before we get
started? Should we do a MAINTAINERS change right away, or leave things as-is
until we're confident this will work and makes sense?

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch