[PATCH libdrm] Add basic CONTRIBUTING file

[PATCH libdrm] Add basic CONTRIBUTING file

[Daniel Vetter]

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-rights
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=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@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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Daniel Stone]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] Add basic CONTRIBUTING file

[Daniel Vetter]

On Wed, Aug 22, 2018 at 12:55 PM, Daniel Stone <daniel@fooishbar.org> wrote:
> 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' ... ?

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.

> 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?

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
-- 
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

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

[Eric Engestrom]

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-rights
> 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

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
"

> +
> +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.

> +
> +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@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] Add basic CONTRIBUTING file

[Daniel Vetter]

On Wed, Aug 22, 2018 at 1:07 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Wed, Aug 22, 2018 at 12:55 PM, Daniel Stone <daniel@fooishbar.org> wrote:
>> 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' ... ?
>
> 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.

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

>
>> 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?
>
> 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
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
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

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

[Daniel Vetter]

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-rights
>> 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
>
> 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.

> "
>
>> +
>> +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@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] Add basic CONTRIBUTING file

[Eric Engestrom]

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-rights
> >> 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
> >
> > 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=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@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[PATCH libdrm] Add basic CONTRIBUTING file

[Daniel Vetter]

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 E.

v7: Use --local in git config (Eric E.)

Cc: Dave Airlie <airlied@gmail.com>
Cc: Michel Dänzer <michel@daenzer.net>
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-rights
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..96f1e4fb0108
--- /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 --local 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=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@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

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH libdrm] Add basic CONTRIBUTING file

[Dave Airlie]

On Mon, 3 Sep 2018 at 18:47, Daniel Vetter <daniel.vetter@ffwll.ch> 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.

Fine with me,

Acked-by: Dave Airlie <airlied@redhat.com>

Dave.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx