This page collects arguments for and against running our Subversion service in a manner that permits committers the technical
ability (but not the social privilege) to make commits against any part of the https://svn.apache.org/repos/asf repository.

Upsides

Simplifies administration of SVN ACL

Allow more cross-collaboration into participating projects.

Changes the culture from a set of technically-closed communities to a set of mostly-open ones.

Downsides

PMCs no longer control who has commit privileges (technically untrue, they are simply being asked to use blacklists instead of whitelists)

Increases leverage for abusive behavior, though this is mitigated by the relative ease by which bad commits can be reverted via reverse-merging,
or, for more invasive changes, plastering over them by deleting the entire tree and copying the last known good revision to HEAD. This only
starts getting complicated when good commits start being comingled with bad ones.

1 hacked account can damage all of /repos/asf (disregard for basic tenet of security: provide access only to those who require it and only to the bare minimum of what they need)

May lead to confusion about the distinction between technical and social privileges.

No single usable accounting of who on a PMC has commit - impact on non SVN-related resources for PMC and foundation (example: http://people.apache.org/committer-index.html) (somebody move this to a Q&A section please? if committer-index requires a list of who has commit where, then such a list will be maintained)

Increases workload on PMCs and volunteer committers

Creates a precedent where the foundation imposes its will on PMCs for no clearly defined or overwhelming reason. (also technically untrue as allowances will be made for grandfathering projects)

Participating Projects

Alternate proposal 1

Each project that is using svn shall have a top-level 'sandbox' directory where any committer may make branches of trunk (or of other branches). Members/Committers will be encouraged to participate in any ASF project via this sandbox area until such time as they are offered direct commit access to the rest of the project's svn tree.

Each project will additionally have a sandbox-commits@project.apache.org svn commit mailing list that anyone may join.

It would be wonderful from an infra standpoint, if this alternate proposal gains traction, that we could "standardize" and
"templatize" our authz rules. The authorization file is already preprocessed by a script before it becomes live, so this
is something that could still lead to some simplification of our rulesets.

Alternative Proposal 2: slow-pedal this idea and focus on social aspects (bimargulies)

The proposal here rests on two foundations:

Streamline administration

Push projects towards a more open view of participation

Changing the authz scheme can give projects a push. However, we have many other possible means of
encouraging projects to adopt a more open approach. SCM authz is a tool that the foundation provides
to help projects manage themselves. The thesis here is that many projects could benefit from a shift in
attitude toward authz and even commit rights. However, 'many' is not all. I've been talking to someone
who might bring a project to the incubator. This project builds software that has very strict assurance
requirements. If they were to come, they would probably feel the need to manage a tight ACL. In discussions,
it seems to me that existing projects that are far along the sequence towards, 'a stable product that
evolves very cautiously' are less likely to adopt an open ACL.

In any case, the argument about the ACL versus culture cuts both ways. Right now, with no change to the
LDAP-based ACL, any project could adopt the following policy:

Commit Access is granted upon request and acceptance of an ICLA. If you request and receive
commit access, you are expected to read, understand, and comply with the project's policies.
If you abuse this, we will remove your access.

(Of course, this could be weakened to mention Foundation membership or committer status on other projects.)
In any case, the eager would-be contributor with an existing ICLA would merely need to wait for the PMC chair
to type a command in response to a request. Is this really much of a barrier? I submit that the cultural posture
that accompanies the tight ACL on many projects today is a much stronger barrier.

Thus, my alternative proposal has two aspects. First, to focus attention via the Community Development PMC on
exploring more open project cultures. Second, to look for ways to ease administration on the assumption that
(some) projects will still maintain ACLs.

I offer a few thoughts on that:

As per the 'Alternative Proposal' above, design a standard authz template for a project that wishes to
maintain an ACL. It's not necessary for all projects to have a sandbox, I think. If the authz calls out
a sandbox pathname with '@committers=rw', then the project decides whether to have that sandbox by deciding
whether to run 'svn mkdir' on the pathname. If they never create it, it's not there. If they do create it, it has access.

The incubator seems to me to be an authz accident waiting to happen. Maybe the solution here is simply
to adopt the 'all committers' model for the incubator, or maybe we could have an LDAP group after all,
so that fat-fingered IPMC chairs are not making many tiny edits?

In other words, could we significantly reduce the amount of template editing that goes on without
clear-cutting all the existing ACLs?