Daniel Vetter | 4d87c2e | 2018-08-15 19:04:45 +0200 | [diff] [blame] | 1 | Contributing to libdrm |
| 2 | ====================== |
| 3 | |
| 4 | Submitting Patches |
| 5 | ------------------ |
| 6 | |
| 7 | Patches should be sent to dri-devel@lists.freedesktop.org, using git |
| 8 | send-email. For patches only touching driver specific code one of the driver |
| 9 | mailing lists (like amd-gfx@lists.freedesktop.org) is also appropriate. See git |
| 10 | documentation for help: |
| 11 | |
| 12 | http://git-scm.com/documentation |
| 13 | |
| 14 | Since dri-devel is a very busy mailing list please use --subject-prefix="PATCH |
| 15 | libdrm" to make it easier to find libdrm patches. This is best done by running |
| 16 | |
| 17 | git config --local format.subjectprefix "PATCH libdrm" |
| 18 | |
| 19 | The first line of a commit message should contain a prefix indicating what part |
| 20 | is affected by the patch followed by one sentence that describes the change. For |
| 21 | examples: |
| 22 | |
| 23 | amdgpu: Use uint32_t i in amdgpu_find_bo_by_cpu_mapping |
| 24 | |
| 25 | The body of the commit message should describe what the patch changes and why, |
| 26 | and also note any particular side effects. For a recommended reading on |
| 27 | writing commit messages, see: |
| 28 | |
| 29 | http://who-t.blogspot.de/2009/12/on-commit-messages.html |
| 30 | |
| 31 | Your patches should also include a Signed-off-by line with your name and email |
| 32 | address. If you're not the patch's original author, you should also gather |
| 33 | S-o-b's by them (and/or whomever gave the patch to you.) The significance of |
| 34 | this is that it certifies that you created the patch, that it was created under |
| 35 | an appropriate open source license, or provided to you under those terms. This |
| 36 | lets us indicate a chain of responsibility for the copyright status of the code. |
| 37 | For more details: |
| 38 | |
| 39 | https://developercertificate.org/ |
| 40 | |
| 41 | We won't reject patches that lack S-o-b, but it is strongly recommended. |
| 42 | |
| 43 | Review and Merging |
| 44 | ------------------ |
| 45 | |
| 46 | Patches should have at least one positive review (Reviewed-by: tag) or |
| 47 | indication of approval (Acked-by: tag) before merging. For any code shared |
| 48 | between drivers this is mandatory. |
| 49 | |
| 50 | Please note that kernel/userspace API header files have special rules, see |
| 51 | include/drm/README. |
| 52 | |
| 53 | Coding style in the project loosely follows the CodingStyle of the linux kernel: |
| 54 | |
| 55 | https://www.kernel.org/doc/html/latest/process/coding-style.html?highlight=coding%20style |
| 56 | |
| 57 | Commit Rights |
| 58 | ------------- |
| 59 | |
| 60 | Commit rights will be granted to anyone who requests them and fulfills the |
| 61 | below 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 | |
| 81 | To apply for commit rights ("Developer" role in gitlab) send a mail to |
| 82 | dri-devel@lists.freedesktop.org and please ping the maintainers if your request |
| 83 | is stuck. |
| 84 | |
| 85 | Committers are encouraged to request their commit rights get removed when they |
| 86 | no longer contribute to the project. Commit rights will be reinstated when they |
| 87 | come back to the project. |
| 88 | |
| 89 | Maintainers and committers should encourage contributors to request commit |
| 90 | rights, as especially junior contributors tend to underestimate their skills. |
| 91 | |
| 92 | Code of Conduct |
| 93 | --------------- |
| 94 | |
| 95 | Please be aware the fd.o Code of Conduct also applies to libdrm: |
| 96 | |
| 97 | https://www.freedesktop.org/wiki/CodeOfConduct/ |
| 98 | |
| 99 | See the gitlab project owners for contact details of the libdrm maintainers. |
| 100 | |
| 101 | Abuse of commit rights, like engaging in commit fights or willfully pushing |
| 102 | patches that violate the documented merge criteria, will also be handled through |
| 103 | the Code of Conduct enforcement process. |
| 104 | |
| 105 | Happy hacking! |