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

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

[Eric Engestrom]

On Tuesday, 2018-09-04 16:24:44 +1000, Dave Airlie wrote:
> 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.

I think this has gathered enough acks and rbs, you can just push it now
and if there's anything that should be adjusted we can do that as
a follow up :)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Daniel Vetter]

On Tue, Sep 04, 2018 at 10:02:40AM +0100, Eric Engestrom wrote:
> On Tuesday, 2018-09-04 16:24:44 +1000, Dave Airlie wrote:
> > 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.
> 
> I think this has gathered enough acks and rbs, you can just push it now
> and if there's anything that should be adjusted we can do that as
> a follow up :)

And pushed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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