[Mesa-dev] [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs

Daniel Vetter daniel at ffwll.ch
Wed Apr 25 13:42:24 UTC 2018


On Wed, Apr 25, 2018 at 01:27:20PM +0100, Emil Velikov wrote:
> On 24 April 2018 at 20:14, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> > On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> >> On 13 April 2018 at 11:00, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> >>> This tries to align with the X.org communities's long-standing
> >>> tradition of trying to be an inclusive community and handing out
> >>> commit rights fairly freely.
> >>>
> >>> We also tend to not revoke commit rights for people no longer
> >>> regularly active in a given project, as long as they're still part of
> >>> the larger community.
> >>>
> >>> Finally make sure that commit rights, like anything happening on fd.o
> >>> infrastructre, is subject to the fd.o's Code of Conduct.
> >>>
> >>> v2: Point at MAINTAINERS for contact info (Daniel S.)
> >>>
> >>> v3:
> >>> - Make it clear that commit rights are voluntary and that committers
> >>>   need to acknowledge positively when they're nominated by someone
> >>>   else (Keith).
> >>> - Encourage committers to drop their commit rights when they're no
> >>>   longer active, and make it clear they'll get readded (Keith).
> >>> - Add a line that maintainers and committers should actively nominate
> >>>   new committers (me).
> >>>
> >>> v4: Typo (Petri).
> >>>
> >>> v5: Typo (Sean).
> >>>
> >>> v6: Wording clarifications and spelling (Jani).
> >>>
> >>> v7: Require an explicit commitment to the documented merge criteria
> >>> and rules, instead of just the implied one through the Code of Conduct
> >>> threat (Jani).
> >>>
> >>> Acked-by: Alex Deucher <alexander.deucher at amd.com>
> >>> Acked-by: Arkadiusz Hiler <arkadiusz.hiler at intel.com>
> >>> Acked-by: Daniel Stone <daniel at fooishbar.org>
> >>> Acked-by: Eric Anholt <eric at anholt.net>
> >>> Acked-by: Gustavo Padovan <gustavo at padovan.org>
> >>> Acked-by: Petri Latvala <petri.latvala at intel.com>
> >>> Cc: Alex Deucher <alexander.deucher at amd.com>
> >>> Cc: Arkadiusz Hiler <arkadiusz.hiler at intel.com>
> >>> Cc: Ben Widawsky <ben at bwidawsk.net>
> >>> Cc: Daniel Stone <daniel at fooishbar.org>
> >>> Cc: Dave Airlie <airlied at gmail.com>
> >>> Cc: Eric Anholt <eric at anholt.net>
> >>> Cc: Gustavo Padovan <gustavo at padovan.org>
> >>> Cc: Jani Nikula <jani.nikula at intel.com>
> >>> Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> >>> Cc: Keith Packard <keithp at keithp.com>
> >>> Cc: Kenneth Graunke <kenneth at whitecape.org>
> >>> Cc: Kristian H. Kristensen <hoegsberg at google.com>
> >>> Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> >>> Cc: Petri Latvala <petri.latvala at intel.com>
> >>> Cc: Rodrigo Vivi <rodrigo.vivi at intel.com>
> >>> Cc: Sean Paul <seanpaul at chromium.org>
> >>> Reviewed-by: Keith Packard <keithp at keithp.com>
> >>> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> >>> ---
> >>> If you wonder about the wide distribution list for an igt patch: I'd
> >>> like to start a discussions about x.org community norms around commit
> >>> rights at large, at least for all the shared repos. I plan to propose
> >>> the same text for drm-misc and libdrm too, and hopefully others like
> >>> mesa/xserver/wayland would follow.
> >>>
> >> I think the idea is pretty good, simply highlighting some bits.
> >>
> >> What you've outlined in this patch has been in practise for many years:
> >>  a) undocumented, applicable to most xorg projects [1]
> >>  b) documented, mesa
> >
> > Hm, I chatted with a few mesa devs about this, and I wasn't aware
> > there's explicit documentation for mesa. Where is it? I'd very much
> > want to align as much as we can.
> >
> See the "Developer git Access" section in [1]. FWIW I prefer the
> wording used in this patch and the CoC reference is a big plus.
> 
> HTH
> Emil
> 
> [1] https://www.mesa3d.org/repository.html

Ah missed this indeed. One thing to note wrt mesa is that this text here
relies heavily on _documented_ merge criteria. When I discussed it with
mesa we realized that the documented merge criteria do not really match
the actual criteria:

https://www.mesa3d.org/submittingpatches.html

E.g. for many drivers review is mandatory I think, same for core code. And
Intel folks require that you go through their CI too.

So the bigger part in adopting this for mesa would be in updating the
merge criteria doc to reflect reality.

Anyway, I'm happy that even the few terse lines match what I'm proposing
here (minus lots of details), I think we're good to go.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the mesa-dev mailing list