[Intel-gfx] [PATCH] drm-misc: Document small drivers expectations
Sean Paul
seanpaul at chromium.org
Tue Jan 31 19:31:32 UTC 2017
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
More information about the dri-devel
mailing list