On Wed, Apr 25, 2018 at 01:27:20PM +0100, Emil Velikov wrote: > On 24 April 2018 at 20:14, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > > On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote: > >> On 13 April 2018 at 11:00, Daniel Vetter <daniel.vetter@xxxxxxxx> 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@xxxxxxx> > >>> Acked-by: Arkadiusz Hiler <arkadiusz.hiler@xxxxxxxxx> > >>> Acked-by: Daniel Stone <daniel@xxxxxxxxxxxxx> > >>> Acked-by: Eric Anholt <eric@xxxxxxxxxx> > >>> Acked-by: Gustavo Padovan <gustavo@xxxxxxxxxxx> > >>> Acked-by: Petri Latvala <petri.latvala@xxxxxxxxx> > >>> Cc: Alex Deucher <alexander.deucher@xxxxxxx> > >>> Cc: Arkadiusz Hiler <arkadiusz.hiler@xxxxxxxxx> > >>> Cc: Ben Widawsky <ben@xxxxxxxxxxxx> > >>> Cc: Daniel Stone <daniel@xxxxxxxxxxxxx> > >>> Cc: Dave Airlie <airlied@xxxxxxxxx> > >>> Cc: Eric Anholt <eric@xxxxxxxxxx> > >>> Cc: Gustavo Padovan <gustavo@xxxxxxxxxxx> > >>> Cc: Jani Nikula <jani.nikula@xxxxxxxxx> > >>> Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > >>> Cc: Keith Packard <keithp@xxxxxxxxxx> > >>> Cc: Kenneth Graunke <kenneth@xxxxxxxxxxxxx> > >>> Cc: Kristian H. Kristensen <hoegsberg@xxxxxxxxxx> > >>> Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> > >>> Cc: Petri Latvala <petri.latvala@xxxxxxxxx> > >>> Cc: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > >>> Cc: Sean Paul <seanpaul@xxxxxxxxxxxx> > >>> Reviewed-by: Keith Packard <keithp@xxxxxxxxxx> > >>> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> > >>> --- > >>> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
