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

2018-09-04 Thread 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  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 
> > 
> > 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
___
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

2018-09-04 Thread Eric Engestrom
On Tuesday, 2018-09-04 16:24:44 +1000, Dave Airlie wrote:
> On Mon, 3 Sep 2018 at 18:47, 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.
> 
> Fine with me,
> 
> Acked-by: Dave Airlie 
> 
> 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 :)
___
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

2018-09-04 Thread Dave Airlie
On Mon, 3 Sep 2018 at 18:47, 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.

Fine with me,

Acked-by: Dave Airlie 

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

2018-09-03 Thread 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 
Cc: Michel Dänzer 
Cc: Emil Velikov 
Cc: Marek Olšák 
Cc: Rob Clark 
Cc: Eric Engestrom 
Reviewed-by: Rob Clark  (v4)
Reviewed-by: Eric Engestrom  (v6)
Acked-by: Emil Velikov  (v6)
Acked-by: Marek Olšák  (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 
---
 CONTRIBUTING | 105 +++
 1 file changed, 105 insertions(+)
 create mode 100644 CONTRIBUTING

diff --git a/CONTRIBUTING b/CONTRIBUTING
new file mode 100644
index ..96f1e4fb0108
--- /dev/null
+++ b/CONTRIBUTING
@@ -0,0 +1,105 @@
+Contributing to libdrm
+==
+
+Submitting Patches
+--
+
+Patches should be sent to dri-de...@lists.freedesktop.org, using git
+send-email. For patches only touching driver specific code one of the driver
+mailing lists (like amd-...@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:
+

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

2018-08-22 Thread 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
>  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 
> >> Cc: Marek Olšák 
> >> Cc: Rob Clark 
> >> Cc: Eric Engestrom 
> >> Reviewed-by: Rob Clark  (v4)
> >> Reviewed-by: Eric Engestrom  (v6)
> >> Acked-by: Emil Velikov  (v6)
> >> Acked-by: Marek Olšák  (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 
> >> ---
> >>  CONTRIBUTING | 105 +++
> >>  1 file changed, 105 insertions(+)
> >>  create mode 100644 CONTRIBUTING
> >>
> >> diff --git a/CONTRIBUTING b/CONTRIBUTING
> >> new file mode 100644
> >> index ..6cd09dd069bb
> >> --- /dev/null
> >> +++ b/CONTRIBUTING
> >> @@ -0,0 +1,105 @@
> >> +Contributing to libdrm
> >> +==
> >> +
> >> +Submitting Patches
> >> +--
> >> +
> >> +Patches should be sent to dri-de...@lists.freedesktop.org, using git
> >> +send-email. For patches only touching driver specific code one of the 
> >> driver
> >> +mailing lists (like amd-...@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-de...@lists.freedesktop.org
> >
> > You can still override it when sending your patch by passing `--to`:
> >   $ git send-email -1 --to amd-...@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:
> >> +
> 

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

2018-08-22 Thread Daniel Vetter
On Wed, Aug 22, 2018 at 1:08 PM, Eric Engestrom
 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 
>> Cc: Marek Olšák 
>> Cc: Rob Clark 
>> Cc: Eric Engestrom 
>> Reviewed-by: Rob Clark  (v4)
>> Reviewed-by: Eric Engestrom  (v6)
>> Acked-by: Emil Velikov  (v6)
>> Acked-by: Marek Olšák  (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 
>> ---
>>  CONTRIBUTING | 105 +++
>>  1 file changed, 105 insertions(+)
>>  create mode 100644 CONTRIBUTING
>>
>> diff --git a/CONTRIBUTING b/CONTRIBUTING
>> new file mode 100644
>> index ..6cd09dd069bb
>> --- /dev/null
>> +++ b/CONTRIBUTING
>> @@ -0,0 +1,105 @@
>> +Contributing to libdrm
>> +==
>> +
>> +Submitting Patches
>> +--
>> +
>> +Patches should be sent to dri-de...@lists.freedesktop.org, using git
>> +send-email. For patches only touching driver specific code one of the driver
>> +mailing lists (like amd-...@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-de...@lists.freedesktop.org
>
> You can still override it when sending your patch by passing `--to`:
>   $ git send-email -1 --to amd-...@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 

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

2018-08-22 Thread Daniel Vetter
On Wed, Aug 22, 2018 at 1:07 PM, Daniel Vetter  wrote:
> On Wed, Aug 22, 2018 at 12:55 PM, Daniel Stone  wrote:
>> On Wed, 22 Aug 2018 at 11:51, Daniel Vetter  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

2018-08-22 Thread 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 
> Cc: Marek Olšák 
> Cc: Rob Clark 
> Cc: Eric Engestrom 
> Reviewed-by: Rob Clark  (v4)
> Reviewed-by: Eric Engestrom  (v6)
> Acked-by: Emil Velikov  (v6)
> Acked-by: Marek Olšák  (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 
> ---
>  CONTRIBUTING | 105 +++
>  1 file changed, 105 insertions(+)
>  create mode 100644 CONTRIBUTING
> 
> diff --git a/CONTRIBUTING b/CONTRIBUTING
> new file mode 100644
> index ..6cd09dd069bb
> --- /dev/null
> +++ b/CONTRIBUTING
> @@ -0,0 +1,105 @@
> +Contributing to libdrm
> +==
> +
> +Submitting Patches
> +--
> +
> +Patches should be sent to dri-de...@lists.freedesktop.org, using git
> +send-email. For patches only touching driver specific code one of the driver
> +mailing lists (like amd-...@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-de...@lists.freedesktop.org

You can still override it when sending your patch by passing `--to`:
  $ git send-email -1 --to amd-...@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 

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

2018-08-22 Thread Daniel Vetter
On Wed, Aug 22, 2018 at 12:55 PM, Daniel Stone  wrote:
> On Wed, 22 Aug 2018 at 11:51, Daniel Vetter  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

2018-08-22 Thread Daniel Stone
On Wed, 22 Aug 2018 at 11:51, Daniel Vetter  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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

2018-08-22 Thread 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 
Cc: Marek Olšák 
Cc: Rob Clark 
Cc: Eric Engestrom 
Reviewed-by: Rob Clark  (v4)
Reviewed-by: Eric Engestrom  (v6)
Acked-by: Emil Velikov  (v6)
Acked-by: Marek Olšák  (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 
---
 CONTRIBUTING | 105 +++
 1 file changed, 105 insertions(+)
 create mode 100644 CONTRIBUTING

diff --git a/CONTRIBUTING b/CONTRIBUTING
new file mode 100644
index ..6cd09dd069bb
--- /dev/null
+++ b/CONTRIBUTING
@@ -0,0 +1,105 @@
+Contributing to libdrm
+==
+
+Submitting Patches
+--
+
+Patches should be sent to dri-de...@lists.freedesktop.org, using git
+send-email. For patches only touching driver specific code one of the driver
+mailing lists (like amd-...@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