For the experiement we have right now Eric (with vc4) and Sean Paul (with rockchip and zte) volunteering, and Gerd (entire pile of qemu drivers) and Boris (atmel) are also considering to participate. I think that's enough to get started and figure things out as we go.
I tried to summarize the main points from the rfc discussions into a short chapter.
v2: Spelling fixes (Anholt).
Cc: Boris Brezillon boris.brezillon@free-electrons.com Cc: Eric Anholt eric@anholt.net Cc: Sean Paul seanpaul@chromium.org Cc: Gerd Hoffmann kraxel@redhat.com Cc: Mark Yao mark.yao@rock-chips.com Cc: Shawn Guo shawnguo@kernel.org Acked-by: Sean Paul seanpaul@chromium.org Acked-by: Gerd Hoffmann kraxel@redhat.com Acked-by: Boris Brezillon boris.brezillon@free-electrons.com Acked-by: Eric Anholt eric@anholt.net Signed-off-by: Daniel Vetter daniel.vetter@intel.com --- drm-misc.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
diff --git a/drm-misc.rst b/drm-misc.rst index 3d711ec60047..7f7233cf3c61 100644 --- a/drm-misc.rst +++ b/drm-misc.rst @@ -93,6 +93,36 @@ Right now the only hard merge criteria are: * See also the extensive `committer guidelines for drm-intel <drm-intel.html#committer-guidelines>`_.
+Small Drivers +============= + +Small drivers, where a full tree is overkill, can be maintained in drm-misc. For +now it's just an experiment with a few drivers to figure out a working process. +Slightly different rules apply: + +* Small is measured in patches merged per kernel release. The occasional big + patch series is still acceptable if it's not a common thing (e.g. new hw + enabling once a year), and if the series is really big (more than 20 patches) + it should probably be managed through a topic branch in drm-misc and with a + separate pull request to drm maintainer. dim_ supports this with the + create-branch command. + +* Group maintainership is assumed, i.e. all regular contributors (not just + the primary maintainer) will get commit rights. + +* Since even a broken driver is more useful than no driver minimal review + standards are a lot lower. The default should be some notes about what could + be improved in follow-up work and accepting patches by default. Maintainer + group for drivers can agree on stricter rules, especially when they have a + bigger user base that shouldn't suffer from regressions. + +* Minimal peer-review is also expected for drivers with just one contributor, + but obviously then only focuses on best practices for the interaction with drm + core and helpers. Plus a bit looking for common patterns in dealing with the + hardware, since display IP all has to handle the same issues in the end. In + most cases this will just along the lines of "Looks good, Ack". drm-misc + maintainers will help out with getting that review market going. + Tooling =======