community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: Project Culture and Commit Rights
Date Fri, 11 Jan 2013 16:06:53 GMT
The problem with that is that we don't get
any of the benefits out of simplification
of our rulesets: namely more comprehensible
behavior out of the server when a commit
has been blocked and someone needs help,
and it doesn't imply that the org has made
any cultural shifts towards a more open infra,
which defeats a lot of the point of the exercise
from my POV.

Let me be clear tho, I have always argued that
projects have the exclusive right to control
access to their codebase.  However the means
by which that control is exercised depends on
many factors, and we shouldn't enshrine an
unexamined mode of technical operation into perpetuity
just because "we've always done it that way".

Relaxing ACL's simply represents a more practical,
and more modern, way of maximizing the utility
you get out of a centralized version control tool
like Subversion.  Projects shouldn't balk at
polite suggestions to modernize, even if we always
allow themselves the option of declining to participate.

> From: Bertrand Delacretaz <>
>Sent: Friday, January 11, 2013 3:43 AM
>Subject: Re: Project Culture and Commit Rights
>On Sat, Jan 5, 2013 at 4:35 PM, Benson Margulies <> wrote:
>> ...There's a weaker form of this idea that looks at two populations of
>> potential contributors: the members of the Apache Software Foundation
>> (members@) and all of the people who have been granted commit rights on all
>> of the projects (committers@). Projects that don't feel prepared to offer
>> commit-on-demand to the world at large might feel inclined to do so for
>> (one or both of) these groups...
>As the ASF aims to give PMCs as much freedom as possible, I'd favor a
>solution where PMCs can decide themselves who they give write
>permission to their code repositories.
>Basing this on groups, project A could say that it's friends with
>projects B and C, and as such allow all people who can write to B and
>C to write to A as well, based on group authorizations.
>We used to do that with Cocoon, where B and C were Lenya and Forrest -
>as sibling projects, we felt that those folks should be able to commit
>small fixes directly without asking, but they were expected to ask
>before making any substantial changes to our code.
>A PMC could then decide to give write access to all ASF members, all
>committers, etc. Letting PMCs make this decision avoids requiring the
>whole ASF (that's 150 projects today) to agree on this, which is in
>line with how we usually handle things - modularization vs. requiring
>everybody to agree.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message