On Wednesday, 2018-08-22 12:51:39 +0200, Daniel Vetter wrote: > I picked up a bunch of the pieces from wayland's version: > > https://gitlab.freedesktop.org/wayland/wayland/blob/master/CONTRIBUTING.md > > The weston one is fairly similar. Then I rather massively trimmed it > down since in reality libdrm is a bit a dumping ground with very few > real rules. The commit rights and CoC sections I've copied verbatim > from igt respectively drm-misc. Weston/Wayland only differ in their > pick of how many patches you need (10 instead of 5). I think for > libdrm this is supremely relevant, since most everyone will get their > commit rights by contributing already to the kernel or mesa and having > commit rights there already. > > Anyway, I figured this is good to get the rules documented, even if > there's mostly not many rules. > > Note: This references maintainers in a MAINTAINERS file, which needs > to be created first. > > Note: With the gitlab migration the entire commit rights process is > still a bit up in the air. But gitlab commit rights and roles are > hierarchical, so we can do libdrm-only maintainer/commiter roles > ("Owner" and "Developer" in gitlab-speak). This should avoid > conflating libdrm roles with mesa roles, useful for those pushing to > libdrm as primarily kernel contributors. > > v2: Comments from Emil: > - Recommend subject prefix. > - Fix copypaste fumbles, this isn't igt/wayland ... > > v3: Comments from Marek: > - libdrm moved to mesa, update the document. Atm the entire account > request situation is entirely not clear for gitlab and mesa > projects, so that's a bit up in the air. Also, should probably send > an announcement to dri-devel@, which didn't happen. > - amd folks don't submit their patches to dri-devel, document that. > Probably applies to other drivers too. > > v4: Comments from Rob: > - Also include kernel/userspace in the commit counts criteria, due to > libdrm's special role as a glue library. > > v5: Summarize the irc discussion on gitlab roles in the commit message > a bit. > > v6: Some grammer stuff from Eric. > > Cc: Emil Velikov <emil.velikov@xxxxxxxxxxxxx> > Cc: Marek Olšák <marek.olsak@xxxxxxx> > Cc: Rob Clark <robdclark@xxxxxxxxx> > Cc: Eric Engestrom <eric.engestrom@xxxxxxxxx> > Reviewed-by: Rob Clark <robdclark@xxxxxxxxx> (v4) > Reviewed-by: Eric Engestrom <eric.engestrom@xxxxxxxxx> (v6) > Acked-by: Emil Velikov <emil.l.velikov@xxxxxxxxx> (v6) > Acked-by: Marek Olšák <marek.olsak@xxxxxxx> (v5) > References: https://gitlab.freedesktop.org/wayland/weston/blob/master/CONTRIBUTING.md > References: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html#commit-rights > References: https://cgit.freedesktop.org/drm/igt-gpu-tools/tree/CONTRIBUTING#n54 > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> > --- > CONTRIBUTING | 105 +++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 105 insertions(+) > create mode 100644 CONTRIBUTING > > diff --git a/CONTRIBUTING b/CONTRIBUTING > new file mode 100644 > index 000000000000..6cd09dd069bb > --- /dev/null > +++ b/CONTRIBUTING > @@ -0,0 +1,105 @@ > +Contributing to libdrm > +====================== > + > +Submitting Patches > +------------------ > + > +Patches should be sent to dri-devel@xxxxxxxxxxxxxxxxxxxxx, using git > +send-email. For patches only touching driver specific code one of the driver > +mailing lists (like amd-gfx@xxxxxxxxxxxxxxxxxxxxx) is also appropriate. See git > +documentation for help: > + > +http://git-scm.com/documentation Actually, just thought about something we could add here: " You can set the default address by running: $ git config --local sendemail.to dri-devel@xxxxxxxxxxxxxxxxxxxxx You can still override it when sending your patch by passing `--to`: $ git send-email -1 --to amd-gfx@xxxxxxxxxxxxxxxxxxxxx " > + > +Since dri-devel is a very busy mailing list please use --subject-prefix="PATCH > +libdrm" to make it easier to find libdrm patches. This is best done by running > + > + git config format.subjectprefix "PATCH libdrm" I would also recommend adding `--local` here to avoid people accidentally running this outside their repo and setting it globally. > + > +The first line of a commit message should contain a prefix indicating what part > +is affected by the patch followed by one sentence that describes the change. For > +examples: > + > + amdgpu: Use uint32_t i in amdgpu_find_bo_by_cpu_mapping > + > +The body of the commit message should describe what the patch changes and why, > +and also note any particular side effects. For a recommended reading on > +writing commit messages, see: > + > +http://who-t.blogspot.de/2009/12/on-commit-messages.html > + > +Your patches should also include a Signed-off-by line with your name and email > +address. If you're not the patch's original author, you should also gather > +S-o-b's by them (and/or whomever gave the patch to you.) The significance of > +this is that it certifies that you created the patch, that it was created under > +an appropriate open source license, or provided to you under those terms. This > +lets us indicate a chain of responsibility for the copyright status of the code. > +For more details: > + > +https://developercertificate.org/ > + > +We won't reject patches that lack S-o-b, but it is strongly recommended. > + > +Review and Merging > +------------------ > + > +Patches should have at least one positive review (Reviewed-by: tag) or > +indication of approval (Acked-by: tag) before merging. For any code shared > +between drivers this is mandatory. > + > +Please note that kernel/userspace API header files have special rules, see > +include/drm/README. > + > +Coding style in the project loosely follows the CodingStyle of the linux kernel: > + > +https://www.kernel.org/doc/html/latest/process/coding-style.html?highlight=coding%20style > + > +Commit Rights > +------------- > + > +Commit rights will be granted to anyone who requests them and fulfills the > +below criteria: > + > +- Submitted a few (5-10 as a rule of thumb) non-trivial (not just simple > + spelling fixes and whitespace adjustment) patches that have been merged > + already. Since libdrm is just a glue library between the kernel and userspace > + drivers, merged patches to those components also count towards the commit > + criteria. > + > +- Are actively participating on discussions about their work (on the mailing > + list or IRC). This should not be interpreted as a requirement to review other > + peoples patches but just make sure that patch submission isn't one-way > + communication. Cross-review is still highly encouraged. > + > +- Will be regularly contributing further patches. This includes regular > + contributors to other parts of the open source graphics stack who only > + do the oddball rare patch within libdrm itself. > + > +- Agrees to use their commit rights in accordance with the documented merge > + criteria, tools, and processes. > + > +To apply for commit rights ("Developer" role in gitlab) send a mail to > +dri-devel@xxxxxxxxxxxxxxxxxxxxx and please ping the maintainers if your request > +is stuck. > + > +Committers are encouraged to request their commit rights get removed when they > +no longer contribute to the project. Commit rights will be reinstated when they > +come back to the project. > + > +Maintainers and committers should encourage contributors to request commit > +rights, as especially junior contributors tend to underestimate their skills. > + > +Code of Conduct > +--------------- > + > +Please be aware the fd.o Code of Conduct also applies to libdrm: > + > +https://www.freedesktop.org/wiki/CodeOfConduct/ > + > +See the gitlab project owners for contact details of the libdrm maintainers. > + > +Abuse of commit rights, like engaging in commit fights or willfully pushing > +patches that violate the documented merge criteria, will also be handled through > +the Code of Conduct enforcement process. > + > +Happy hacking! > -- > 2.18.0 > > _______________________________________________ > mesa-dev mailing list > mesa-dev@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
