Re: [maintainer-tools PATCH] doc: how to become a drm-intel committer

[Daniel Vetter]

On Thu, Mar 15, 2018 at 4:32 PM, Jani Nikula  wrote:
> On Thu, 15 Mar 2018, Daniel Vetter  wrote:
>> On Wed, Mar 14, 2018 at 05:11:02PM +0200, Jani Nikula wrote:
>>> Until now, the drm-intel commit access have been handed out ad hoc,
>>> without transparency, consistency, or fairness. With pressure to add
>>> more committers, this is no longer tenable, if it ever was. Document the
>>> requirements and expectations around becoming a drm-intel committer.
>>>
>>> The Linux kernel operates in a model where, by and large, only
>>> maintainers commit patches. Maintainer teams are no longer rare, but the
>>> drm-intel and drm-misc maintainer/committer model is definitely an
>>> outlier.
>>>
>>> The drm-intel maintainers believe that a reasonable level of experience
>>> and track record of working on the driver, as well as actively engaging
>>> in the community upstream, are necessary before becoming a
>>> committer. While the requirements outlined here may seem strict in
>>> contrast with many projects, they are extremely liberal by kernel
>>> standards.
>>>
>>> Finally, no rules are carved in stone. We fully expect the requirements
>>> to be adjusted later. However, it will be much easier to start strict
>>> and relax the requirements later than the other way round.
>>>
>>> Cc: Gustavo Padovan 
>>> Cc: Maarten Lankhorst 
>>> Cc: Sean Paul 
>>> Cc: Dave Airlie 
>>> Cc: dim-to...@lists.freedesktop.org
>>> Cc: dri-devel@lists.freedesktop.org
>>> Cc: intel-...@lists.freedesktop.org
>>> Signed-off-by: Jani Nikula 
>>> Signed-off-by: Joonas Lahtinen 
>>> Signed-off-by: Rodrigo Vivi 
>>
>> I've chatted for a few hours with Joonas, and I think before we can
>> discuss the proposed document here itself, we first need to reach some
>> agreement on why we even have commit rights. I think there's a very wide
>> range of answers to that questions, and of course with different goals you
>> end up with completely different rules about how to handle commit rights.
>>
>> Joonas suggested we first discuss this internally, perhaps with the
>> maintainers, Kimmo and me.
>
> Fine. I would rather have discussed this transparently out in the
> open. That was, after all, the purpose of sending this out.

This was more or less Joonas' requests after our long discussion (he
did take a quick look at my reply before I sent it out). We can also
have the discussion here, I do have the draft still lying around
somewhere.
-Daniel
-- 
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: [maintainer-tools PATCH] doc: how to become a drm-intel committer

[Jani Nikula]

On Thu, 15 Mar 2018, Daniel Vetter  wrote:
> On Wed, Mar 14, 2018 at 05:11:02PM +0200, Jani Nikula wrote:
>> Until now, the drm-intel commit access have been handed out ad hoc,
>> without transparency, consistency, or fairness. With pressure to add
>> more committers, this is no longer tenable, if it ever was. Document the
>> requirements and expectations around becoming a drm-intel committer.
>> 
>> The Linux kernel operates in a model where, by and large, only
>> maintainers commit patches. Maintainer teams are no longer rare, but the
>> drm-intel and drm-misc maintainer/committer model is definitely an
>> outlier.
>> 
>> The drm-intel maintainers believe that a reasonable level of experience
>> and track record of working on the driver, as well as actively engaging
>> in the community upstream, are necessary before becoming a
>> committer. While the requirements outlined here may seem strict in
>> contrast with many projects, they are extremely liberal by kernel
>> standards.
>> 
>> Finally, no rules are carved in stone. We fully expect the requirements
>> to be adjusted later. However, it will be much easier to start strict
>> and relax the requirements later than the other way round.
>> 
>> Cc: Gustavo Padovan 
>> Cc: Maarten Lankhorst 
>> Cc: Sean Paul 
>> Cc: Dave Airlie 
>> Cc: dim-to...@lists.freedesktop.org
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: intel-...@lists.freedesktop.org
>> Signed-off-by: Jani Nikula 
>> Signed-off-by: Joonas Lahtinen 
>> Signed-off-by: Rodrigo Vivi 
>
> I've chatted for a few hours with Joonas, and I think before we can
> discuss the proposed document here itself, we first need to reach some
> agreement on why we even have commit rights. I think there's a very wide
> range of answers to that questions, and of course with different goals you
> end up with completely different rules about how to handle commit rights.
>
> Joonas suggested we first discuss this internally, perhaps with the
> maintainers, Kimmo and me.

Fine. I would rather have discussed this transparently out in the
open. That was, after all, the purpose of sending this out.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [maintainer-tools PATCH] doc: how to become a drm-intel committer

[Daniel Vetter]

On Wed, Mar 14, 2018 at 05:11:02PM +0200, Jani Nikula wrote:
> Until now, the drm-intel commit access have been handed out ad hoc,
> without transparency, consistency, or fairness. With pressure to add
> more committers, this is no longer tenable, if it ever was. Document the
> requirements and expectations around becoming a drm-intel committer.
> 
> The Linux kernel operates in a model where, by and large, only
> maintainers commit patches. Maintainer teams are no longer rare, but the
> drm-intel and drm-misc maintainer/committer model is definitely an
> outlier.
> 
> The drm-intel maintainers believe that a reasonable level of experience
> and track record of working on the driver, as well as actively engaging
> in the community upstream, are necessary before becoming a
> committer. While the requirements outlined here may seem strict in
> contrast with many projects, they are extremely liberal by kernel
> standards.
> 
> Finally, no rules are carved in stone. We fully expect the requirements
> to be adjusted later. However, it will be much easier to start strict
> and relax the requirements later than the other way round.
> 
> Cc: Gustavo Padovan 
> Cc: Maarten Lankhorst 
> Cc: Sean Paul 
> Cc: Dave Airlie 
> Cc: dim-to...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Signed-off-by: Jani Nikula 
> Signed-off-by: Joonas Lahtinen 
> Signed-off-by: Rodrigo Vivi 

I've chatted for a few hours with Joonas, and I think before we can
discuss the proposed document here itself, we first need to reach some
agreement on why we even have commit rights. I think there's a very wide
range of answers to that questions, and of course with different goals you
end up with completely different rules about how to handle commit rights.

Joonas suggested we first discuss this internally, perhaps with the
maintainers, Kimmo and me.
-Daniel

> 
> ---
> 
> We encourage the drm-misc maintainers to consider and document your
> requirements for committers. While there's certain appeal to aligning on
> the rules between drm-misc and drm-intel, we don't think they
> necessarily have to be the same.
> ---
>  commit-access.rst | 143 
> ++
>  index.rst |   1 +
>  2 files changed, 144 insertions(+)
>  create mode 100644 commit-access.rst
> 
> diff --git a/commit-access.rst b/commit-access.rst
> new file mode 100644
> index ..dbc50f2b5bd3
> --- /dev/null
> +++ b/commit-access.rst
> @@ -0,0 +1,143 @@
> +===
> + Commit Access
> +===
> +
> +The drm-misc and drm-intel repositories operate in a maintainer/committer 
> model
> +with a large pool committers who can push patches in accordance with the 
> stated
> +merge criteria, and maintainers handling pull requests, topic branches, 
> merges,
> +and so on.
> +
> +This document outlines the requirements for becoming a committer.
> +
> +drm-misc
> +
> +
> +TBD.
> +
> +drm-intel
> +-
> +
> +Requirements
> +
> +
> +The baseline requirements for becoming a drm-intel committer are:
> +
> +- Comfortable with the open collaboration model we have.
> +
> +- Enough experience to gauge reasonably well how much review a patch needs, 
> and
> +  when pushing a patch, whether it needs acks from domain experts or
> +  maintainers.
> +
> +- Strong presence in the project communication channels (intel-gfx mailing 
> list
> +  and #intel-gfx IRC channel) for topics in their area of expertise.
> +
> +Since everyone is different and has different focus in their work, there are 
> no
> +hard and fast rules, but just indicators and some judgement.
> +
> +Positive indicators are:
> +
> +- Decent amount of non-trivial patches merged in the past year (25+ patches,
> +  excluding simple code movement, typo fixes and similar patches).
> +
> +- Decent amount of in-depth review, again 25+ in the past year as the 
> threshold.
> +
> +- Lots of experience and commit rights in related open-source projects, like
> +  Mesa, or kernel trees like drm-misc, since the processes are very similar. 
> 2+
> +  years as the threshold here, and this is also fulfilled after 2+ years of
> +  working in the virtual upstream team (product tree hacking doesn't count).
> +
> +- Already merged a complex feature, e.g. spanning multiple subsystems or even
> +  involving userspace.
> +
> +- Active member on freedesktop.org bugzilla. A developer that besides 
> submitting
> +  patches to fix bugs is also engaged on bugs discussion giving constructive
> +  comments helping to drive the bug entry to a solution. Hence keeping bug 
> list
> +  active, clean, and under control.
> +
> +Contra-indicators are:
> +
> +- Not around on IRC (taking timezones into account of course).
> +
> +- Mostly simple 

[maintainer-tools PATCH] doc: how to become a drm-intel committer

[Jani Nikula]

Until now, the drm-intel commit access have been handed out ad hoc,
without transparency, consistency, or fairness. With pressure to add
more committers, this is no longer tenable, if it ever was. Document the
requirements and expectations around becoming a drm-intel committer.

The Linux kernel operates in a model where, by and large, only
maintainers commit patches. Maintainer teams are no longer rare, but the
drm-intel and drm-misc maintainer/committer model is definitely an
outlier.

The drm-intel maintainers believe that a reasonable level of experience
and track record of working on the driver, as well as actively engaging
in the community upstream, are necessary before becoming a
committer. While the requirements outlined here may seem strict in
contrast with many projects, they are extremely liberal by kernel
standards.

Finally, no rules are carved in stone. We fully expect the requirements
to be adjusted later. However, it will be much easier to start strict
and relax the requirements later than the other way round.

Cc: Gustavo Padovan 
Cc: Maarten Lankhorst 
Cc: Sean Paul 
Cc: Dave Airlie 
Cc: dim-to...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Jani Nikula 
Signed-off-by: Joonas Lahtinen 
Signed-off-by: Rodrigo Vivi 

---

We encourage the drm-misc maintainers to consider and document your
requirements for committers. While there's certain appeal to aligning on
the rules between drm-misc and drm-intel, we don't think they
necessarily have to be the same.
---
 commit-access.rst | 143 ++
 index.rst |   1 +
 2 files changed, 144 insertions(+)
 create mode 100644 commit-access.rst

diff --git a/commit-access.rst b/commit-access.rst
new file mode 100644
index ..dbc50f2b5bd3
--- /dev/null
+++ b/commit-access.rst
@@ -0,0 +1,143 @@
+===
+ Commit Access
+===
+
+The drm-misc and drm-intel repositories operate in a maintainer/committer model
+with a large pool committers who can push patches in accordance with the stated
+merge criteria, and maintainers handling pull requests, topic branches, merges,
+and so on.
+
+This document outlines the requirements for becoming a committer.
+
+drm-misc
+
+
+TBD.
+
+drm-intel
+-
+
+Requirements
+
+
+The baseline requirements for becoming a drm-intel committer are:
+
+- Comfortable with the open collaboration model we have.
+
+- Enough experience to gauge reasonably well how much review a patch needs, and
+  when pushing a patch, whether it needs acks from domain experts or
+  maintainers.
+
+- Strong presence in the project communication channels (intel-gfx mailing list
+  and #intel-gfx IRC channel) for topics in their area of expertise.
+
+Since everyone is different and has different focus in their work, there are no
+hard and fast rules, but just indicators and some judgement.
+
+Positive indicators are:
+
+- Decent amount of non-trivial patches merged in the past year (25+ patches,
+  excluding simple code movement, typo fixes and similar patches).
+
+- Decent amount of in-depth review, again 25+ in the past year as the 
threshold.
+
+- Lots of experience and commit rights in related open-source projects, like
+  Mesa, or kernel trees like drm-misc, since the processes are very similar. 2+
+  years as the threshold here, and this is also fulfilled after 2+ years of
+  working in the virtual upstream team (product tree hacking doesn't count).
+
+- Already merged a complex feature, e.g. spanning multiple subsystems or even
+  involving userspace.
+
+- Active member on freedesktop.org bugzilla. A developer that besides 
submitting
+  patches to fix bugs is also engaged on bugs discussion giving constructive
+  comments helping to drive the bug entry to a solution. Hence keeping bug list
+  active, clean, and under control.
+
+Contra-indicators are:
+
+- Not around on IRC (taking timezones into account of course).
+
+- Mostly simple patches and rubber-stamping reviews not resulting in in-depth
+  discussions.
+
+- No complete feature patch set merged yet.
+
+As a rule of thumb, commit rights will be granted when most positive indicators
+are fulfilled and no negative indicators present. The current project
+maintainers assess whether a candidate meets the requirements, and make the
+decisions about commit rights.
+
+Nomination
+~~
+
+Any developer, who already have demonstrated some of positive requirements, can
+be nominated at any time by anyone: maintainers, committers, managers, peers,
+and even self nomination are accepted.
+
+Nomination process is simply sending an email to the drm-intel
+maintainers. Please nominate one person per email, and Cc: the
+nominee. Nominations are processed by