Apache Logo
The Apache Way Contribute ASF Sponsors

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

Downsides

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:

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:

  1. 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.

  2. 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?