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@xxxxxxxxx> 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@xxxxxxxxxxxxx> > >> Cc: Marek Olšák <marek.olsak@xxxxxxx> > >> Cc: Rob Clark <robdclark@xxxxxxxxx> > >> Cc: Eric Engestrom <eric.engestrom@xxxxxxxxx> > >> Reviewed-by: Rob Clark <robdclark@xxxxxxxxx> (v4) > >> Reviewed-by: Eric Engestrom <eric.engestrom@xxxxxxxxx> (v6) > >> Acked-by: Emil Velikov <emil.l.velikov@xxxxxxxxx> (v6) > >> Acked-by: Marek Olšák <marek.olsak@xxxxxxx> (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@xxxxxxxxx> > >> --- > >> 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@xxxxxxxxxxxxxxxxxxxxx, using git > >> +send-email. For patches only touching driver specific code one of the driver > >> +mailing lists (like amd-gfx@xxxxxxxxxxxxxxxxxxxxx) 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@xxxxxxxxxxxxxxxxxxxxx > > > > You can still override it when sending your patch by passing `--to`: > > $ git send-email -1 --to amd-gfx@xxxxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxx > >> 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
