[Mesa-dev] [PATCH libdrm] Add basic CONTRIBUTING file

Wed Aug 22 11:15:57 UTC 2018

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 at 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 at collabora.com>
> >> Cc: Marek Olšák <marek.olsak at amd.com>
> >> Cc: Rob Clark <robdclark at gmail.com>
> >> Cc: Eric Engestrom <eric.engestrom at intel.com>
> >> Reviewed-by: Rob Clark <robdclark at gmail.com> (v4)
> >> Reviewed-by: Eric Engestrom <eric.engestrom at intel.com> (v6)
> >> Acked-by: Emil Velikov <emil.l.velikov at gmail.com> (v6)
> >> Acked-by: Marek Olšák <marek.olsak at 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-rights
> >> References: https://cgit.freedesktop.org/drm/igt-gpu-tools/tree/CONTRIBUTING#n54
> >> Signed-off-by: Daniel Vetter <daniel.vetter at 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 at lists.freedesktop.org, using git
> >> +send-email. For patches only touching driver specific code one of the driver
> >> +mailing lists (like amd-gfx at lists.freedesktop.org) 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 at lists.freedesktop.org
> >
> > You can still override it when sending your patch by passing `--to`:
> >   $ git send-email -1 --to amd-gfx at 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=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 at 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 at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev