1Contributing to libdrm 2====================== 3 4Submitting Patches 5------------------ 6 7Patches should be sent to dri-devel@lists.freedesktop.org, using git 8send-email. For patches only touching driver specific code one of the driver 9mailing lists (like amd-gfx@lists.freedesktop.org) is also appropriate. See git 10documentation for help: 11 12http://git-scm.com/documentation 13 14Since dri-devel is a very busy mailing list please use --subject-prefix="PATCH 15libdrm" to make it easier to find libdrm patches. This is best done by running 16 17 git config --local format.subjectprefix "PATCH libdrm" 18 19The first line of a commit message should contain a prefix indicating what part 20is affected by the patch followed by one sentence that describes the change. For 21examples: 22 23 amdgpu: Use uint32_t i in amdgpu_find_bo_by_cpu_mapping 24 25The body of the commit message should describe what the patch changes and why, 26and also note any particular side effects. For a recommended reading on 27writing commit messages, see: 28 29http://who-t.blogspot.de/2009/12/on-commit-messages.html 30 31Your patches should also include a Signed-off-by line with your name and email 32address. If you're not the patch's original author, you should also gather 33S-o-b's by them (and/or whomever gave the patch to you.) The significance of 34this is that it certifies that you created the patch, that it was created under 35an appropriate open source license, or provided to you under those terms. This 36lets us indicate a chain of responsibility for the copyright status of the code. 37For more details: 38 39https://developercertificate.org/ 40 41We won't reject patches that lack S-o-b, but it is strongly recommended. 42 43Review and Merging 44------------------ 45 46Patches should have at least one positive review (Reviewed-by: tag) or 47indication of approval (Acked-by: tag) before merging. For any code shared 48between drivers this is mandatory. 49 50Please note that kernel/userspace API header files have special rules, see 51include/drm/README. 52 53Coding style in the project loosely follows the CodingStyle of the linux kernel: 54 55https://www.kernel.org/doc/html/latest/process/coding-style.html?highlight=coding%20style 56 57Commit Rights 58------------- 59 60Commit rights will be granted to anyone who requests them and fulfills the 61below criteria: 62 63- Submitted a few (5-10 as a rule of thumb) non-trivial (not just simple 64 spelling fixes and whitespace adjustment) patches that have been merged 65 already. Since libdrm is just a glue library between the kernel and userspace 66 drivers, merged patches to those components also count towards the commit 67 criteria. 68 69- Are actively participating on discussions about their work (on the mailing 70 list or IRC). This should not be interpreted as a requirement to review other 71 peoples patches but just make sure that patch submission isn't one-way 72 communication. Cross-review is still highly encouraged. 73 74- Will be regularly contributing further patches. This includes regular 75 contributors to other parts of the open source graphics stack who only 76 do the oddball rare patch within libdrm itself. 77 78- Agrees to use their commit rights in accordance with the documented merge 79 criteria, tools, and processes. 80 81To apply for commit rights ("Developer" role in gitlab) send a mail to 82dri-devel@lists.freedesktop.org and please ping the maintainers if your request 83is stuck. 84 85Committers are encouraged to request their commit rights get removed when they 86no longer contribute to the project. Commit rights will be reinstated when they 87come back to the project. 88 89Maintainers and committers should encourage contributors to request commit 90rights, as especially junior contributors tend to underestimate their skills. 91 92Code of Conduct 93--------------- 94 95Please be aware the fd.o Code of Conduct also applies to libdrm: 96 97https://www.freedesktop.org/wiki/CodeOfConduct/ 98 99See the gitlab project owners for contact details of the libdrm maintainers. 100 101Abuse of commit rights, like engaging in commit fights or willfully pushing 102patches that violate the documented merge criteria, will also be handled through 103the Code of Conduct enforcement process. 104 105Happy hacking! 106