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: + +http://git-scm.com/documentation + +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" + +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!
On Wed, 22 Aug 2018 at 11:51, Daniel Vetter daniel.vetter@ffwll.ch wrote:
+See the gitlab project owners for contact details of the libdrm maintainers.
Think this should be 'See MAINTAINERS' ... ?
The rest looks good to me, though I would encourage linking to Patchwork so people can find patches from others, as well as making sure their own patch hasn't disappeared into the void.
Is there a document somewhere that describes how to use Patchwork & git-pw you could link to?
Cheers, Daniel
On Wed, Aug 22, 2018 at 12:55 PM, Daniel Stone daniel@fooishbar.org wrote:
Hm right. Originally it was, but then I got a bit confused with how this should work with gitlab. Having explicit MAINTAINERS is probably good still. Will fix.
There's no libdrm pw afaik. It's terribly lossy I think and spread all over the place, e.g. driver stuff tends to only show up on driver lists. Given that I'm just trying to describe status quo I don't think it makes sense to point at patchwork. -Daniel
On Wed, Aug 22, 2018 at 1:07 PM, Daniel Vetter daniel.vetter@ffwll.ch wrote:
On 2nd thought 2 seconds later: Won't fix, since we don't yet have the MAINTAINERS file. Atm the gitlab owners list is about the best thing. Once we have MAINTAINERS (I think Emil volunteered to find volunteers) we can adjust this. -Daniel
On Wednesday, 2018-08-22 12:51:39 +0200, Daniel Vetter wrote:
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 "
I would also recommend adding `--local` here to avoid people accidentally running this outside their repo and setting it globally.
On Wed, Aug 22, 2018 at 1:08 PM, Eric Engestrom eric.engestrom@intel.com wrote:
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 idea, will fix. -Daniel
dri-devel@lists.freedesktop.org
-
Daniel Stone -
Daniel Vetter -
Eric Engestrom