| Message ID | 20180314151102.16798-1-jani.nikula@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 <gustavo@padovan.org> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > Cc: Sean Paul <seanpaul@chromium.org> > Cc: Dave Airlie <airlied@gmail.com> > Cc: dim-tools@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Cc: intel-gfx@lists.freedesktop.org > Signed-off-by: Jani Nikula <jani.nikula@intel.com> > Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> 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 000000000000..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 the maintainers on a first come, first > +served basis, as nominations are received. > + > +Nomination is not a guarantee of the commit rights. In case a nomination is > +rejected, the maintainers will give constructive feedback on what areas the > +nominee should try to work on. > + > +When there are several nominees at the same time, the ramp-up time on the tools > +and processes, and the support bandwidth limit the amount of rights that can be > +distributed at once. Maintainers are responsible for collecting all the > +candidates in a list that will be sorted out following some criteria: > + > +- More recent activity. It is easier to absorb and ramp-up a committer that is > + currently active on i915 with pending patches to get merged. > + > +- More positive indicators. > + > +- Fewer contra-indicators. > + > +After the nomination has been processed and a decision has been made about > +giving or postponing giving out the commit rights to the nominee, there will be > +a reply from the maintainers to the the nominated person only. > + > +In case the nominee is accepted as a committer and accepts the new role, the > +nominee will need to request a freedesktop.org account according to > +https://www.freedesktop.org/wiki/AccountRequests/, and the drm-intel maintainers > +will ack adding the account with drm-intel access on the account request bug. If > +the nominee already has a freedesktop.org account, the drm-intel maintainers > +will file the access request bug. > + > +Revocation > +~~~~~~~~~~ > + > +- Self abdicate. Anyone at any time can explicitly request to be removed from > + the list of drm-intel committers. > + > +- Long period of inactivity on DRM projects and community. It is very common to > + have people changing jobs and not contributing anymore to DRM related > + projects. So, in order to keep the list clean and under control, after one > + year of inactivity, commit rights can be withdrawn with or without > + notification. > + > +- Repeatedly breaking the rules on pushing patches. Everyone makes mistakes, > + especially when ramping up and getting used to the maintainer tools. However, > + commit rights could be revoked when a committer has been repeatedly observed, > + and notified, of: > + > + - Pushing patches without review (or acks from maintainers or domain experts > + when required). > + > + - Pushing patches that had a clear rejection from maintainers or other > + committers or unresolved review comments. > + > + - Pushing patches without proper tags or links. > + > + - Pushing patches to other branches than drm-intel-next-queued. > + > + - Pushing patches without using dim tools. > + > + - Pushing patches that didn’t pass CI. > + > +- Freedesktop.org Code of Conduct violations may lead to temporary or permanent > + account or commit rights suspension according to freedesktop.org umbrella > + rules. > diff --git a/index.rst b/index.rst > index d2142a7898f8..2db033161196 100644 > --- a/index.rst > +++ b/index.rst > @@ -23,6 +23,7 @@ Contents: > :maxdepth: 2 > > repositories > + commit-access > drm-misc > drm-intel > dim > -- > 2.11.0 > > _______________________________________________ > dim-tools mailing list > dim-tools@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dim-tools
On Thu, 15 Mar 2018, Daniel Vetter <daniel@ffwll.ch> 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 <gustavo@padovan.org> >> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> >> Cc: Sean Paul <seanpaul@chromium.org> >> Cc: Dave Airlie <airlied@gmail.com> >> Cc: dim-tools@lists.freedesktop.org >> Cc: dri-devel@lists.freedesktop.org >> Cc: intel-gfx@lists.freedesktop.org >> Signed-off-by: Jani Nikula <jani.nikula@intel.com> >> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> >> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > 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.
On Thu, Mar 15, 2018 at 4:32 PM, Jani Nikula <jani.nikula@intel.com> wrote: > On Thu, 15 Mar 2018, Daniel Vetter <daniel@ffwll.ch> 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 <gustavo@padovan.org> >>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> >>> Cc: Sean Paul <seanpaul@chromium.org> >>> Cc: Dave Airlie <airlied@gmail.com> >>> Cc: dim-tools@lists.freedesktop.org >>> Cc: dri-devel@lists.freedesktop.org >>> Cc: intel-gfx@lists.freedesktop.org >>> Signed-off-by: Jani Nikula <jani.nikula@intel.com> >>> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> >>> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> >> >> 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
diff --git a/commit-access.rst b/commit-access.rst new file mode 100644 index 000000000000..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 the maintainers on a first come, first +served basis, as nominations are received. + +Nomination is not a guarantee of the commit rights. In case a nomination is +rejected, the maintainers will give constructive feedback on what areas the +nominee should try to work on. + +When there are several nominees at the same time, the ramp-up time on the tools +and processes, and the support bandwidth limit the amount of rights that can be +distributed at once. Maintainers are responsible for collecting all the +candidates in a list that will be sorted out following some criteria: + +- More recent activity. It is easier to absorb and ramp-up a committer that is + currently active on i915 with pending patches to get merged. + +- More positive indicators. + +- Fewer contra-indicators. + +After the nomination has been processed and a decision has been made about +giving or postponing giving out the commit rights to the nominee, there will be +a reply from the maintainers to the the nominated person only. + +In case the nominee is accepted as a committer and accepts the new role, the +nominee will need to request a freedesktop.org account according to +https://www.freedesktop.org/wiki/AccountRequests/, and the drm-intel maintainers +will ack adding the account with drm-intel access on the account request bug. If +the nominee already has a freedesktop.org account, the drm-intel maintainers +will file the access request bug. + +Revocation +~~~~~~~~~~ + +- Self abdicate. Anyone at any time can explicitly request to be removed from + the list of drm-intel committers. + +- Long period of inactivity on DRM projects and community. It is very common to + have people changing jobs and not contributing anymore to DRM related + projects. So, in order to keep the list clean and under control, after one + year of inactivity, commit rights can be withdrawn with or without + notification. + +- Repeatedly breaking the rules on pushing patches. Everyone makes mistakes, + especially when ramping up and getting used to the maintainer tools. However, + commit rights could be revoked when a committer has been repeatedly observed, + and notified, of: + + - Pushing patches without review (or acks from maintainers or domain experts + when required). + + - Pushing patches that had a clear rejection from maintainers or other + committers or unresolved review comments. + + - Pushing patches without proper tags or links. + + - Pushing patches to other branches than drm-intel-next-queued. + + - Pushing patches without using dim tools. + + - Pushing patches that didn’t pass CI. + +- Freedesktop.org Code of Conduct violations may lead to temporary or permanent + account or commit rights suspension according to freedesktop.org umbrella + rules. diff --git a/index.rst b/index.rst index d2142a7898f8..2db033161196 100644 --- a/index.rst +++ b/index.rst @@ -23,6 +23,7 @@ Contents: :maxdepth: 2 repositories + commit-access drm-misc drm-intel dim