community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From janI <j...@apache.org>
Subject Re: Project Culture and Commit Rights
Date Sat, 05 Jan 2013 18:15:48 GMT
I personally like the idea of giving committer right on request. I do not
like the fact that is has to be earned...we are volunteers not workers !

However I fully understand PMCs that are concerned about uncontrolled
commits, so I see the "right on request" go hand in hand with a way of
"removing right". PMC should be able to, with reason and warning, to "ban"
a committer, and that should be effective for all ASF. I also think that
people with commit rights who are inactive for a longer period of time (I
am not sure how long that should be, but no longer than a year) should
automatically have revoked the right (with the option that they can request
it again).

ICLA is a must.

I know from other projects (outside) ASF that they talk about committers
and committer-interest, the latter group is controlled/reviewed by an old
committer. With that, committers save time to commit patches, and new
people feel welcome.

but that is just my personal opion.
Jan Iversen.


On 5 January 2013 19:05, Benson Margulies <bimargulies@gmail.com> wrote:

> ICLAs are still an absolute requirement. So, imagine an Apache project with
> a policy like:
>
>    Commit rights are granted on request to people with an Apache ICLA on
> file ...
>
>
>
>
> On Sat, Jan 5, 2013 at 1:02 PM, Rob Weir <robweir@apache.org> wrote:
>
> > On Sat, Jan 5, 2013 at 10:35 AM, Benson Margulies <bimargulies@gmail.com
> >
> > wrote:
> >
> > .
> > .
> > .
> > >
> > > The question at hand here is, 'is this really a good idea? Would
> project
> > > grow and thrive better if they set a lower bar to grant commit rights?'
> > >
> >
> > How does the iCLA fit into any change?  Personally I would not mind
> > commit rights on request, but I still see the value for a project to
> > have iCLA's on file for all those who have such rights. This is to
> > protect our users.
> >
> > -Rob
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message