[Intel-gfx] [PATCH] drm-misc: Document small drivers expectations

[Sean Paul]

On Tue, Jan 31, 2017 at 07:01:44PM +0100, Daniel Vetter wrote:
> 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.

Did we decide on whether we're using a topic branch to start out? Also, are you
on the hook for pull requests?

Sean

> 
> v2: Spelling fixes (Anholt).
> 
> Cc: Boris Brezillon <boris.brezillon at free-electrons.com>
> Cc: Eric Anholt <eric at anholt.net>
> Cc: Sean Paul <seanpaul at chromium.org>
> Cc: Gerd Hoffmann <kraxel at redhat.com>
> Cc: Mark Yao <mark.yao at rock-chips.com>
> Cc: Shawn Guo <shawnguo at kernel.org>
> Acked-by: Sean Paul <seanpaul at chromium.org>
> Acked-by: Gerd Hoffmann <kraxel at redhat.com>
> Acked-by: Boris Brezillon <boris.brezillon at free-electrons.com>
> Acked-by: Eric Anholt <eric at anholt.net>
> Signed-off-by: Daniel Vetter <daniel.vetter at 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
>  =======
>  
> -- 
> 2.11.0
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Sean Paul, Software Engineer, Google / Chromium OS