On Wednesday, 2018-08-22 13:10:42 +0200, Daniel Vetter wrote:
On Wed, Aug 22, 2018 at 1:08 PM, Eric Engestrom eric.engestrom@intel.com wrote:
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@collabora.com Cc: Marek Olšák marek.olsak@amd.com Cc: Rob Clark robdclark@gmail.com Cc: Eric Engestrom eric.engestrom@intel.com Reviewed-by: Rob Clark robdclark@gmail.com (v4) Reviewed-by: Eric Engestrom eric.engestrom@intel.com (v6) Acked-by: Emil Velikov emil.l.velikov@gmail.com (v6) Acked-by: Marek Olšák marek.olsak@amd.com (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-... References: https://cgit.freedesktop.org/drm/igt-gpu-tools/tree/CONTRIBUTING#n54 Signed-off-by: Daniel Vetter daniel.vetter@intel.com
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@lists.freedesktop.org, using git +send-email. For patches only touching driver specific code one of the driver +mailing lists (like amd-gfx@lists.freedesktop.org) is also appropriate. See git +documentation for help:
Actually, just thought about something we could add here:
" You can set the default address by running: $ git config --local sendemail.to dri-devel@lists.freedesktop.org
You can still override it when sending your patch by passing `--to`: $ git send-email -1 --to amd-gfx@lists.freedesktop.org
Uh, this sounds dangerous. We already have plenty fun when people forget --suppress-cc=all when sending around internal patches. And then it's usually just individuals, not lists.
This is practically begging for leaks.
Good point, didn't think about that.
"
+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.
Good idea, will fix. -Daniel
+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=c...
+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@lists.freedesktop.org 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev