Re: Project Culture and Commit Rights
On Sat, Jan 5, 2013 at 4:35 PM, Benson Margulies bimargul...@gmail.com 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. -Bertrand
Re: Project Culture and Commit Rights
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 bdelacre...@apache.org To: dev@community.apache.org 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 bimargul...@gmail.com 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. -Bertrand
Re: Project Culture and Commit Rights
Benson Margulies: Anyone can read http://www.apache.org/dev/open-access-svn.html to see a summary of the central idea that started this discussion: that the default authorization scheme for Subversion at Apache should be to grant technical permission to commit to all committers across the Foundation. I'm not currently active in any Apache project but have been and was very annoyed to be forced to use Subversion. Therefor just for the record: The whole discussion would be meaningless if the ASF would switch to Git. (I'm not sure about the progress in this regard.) With Git, everybody can add commits to every Git repository on the Internet. One would just not be able to push them. But I can just push to my own Github account and send an email asking for a pull. Regards, Thomas Koch, http://www.koch.ro
Re: Project Culture and Commit Rights
On Thu, Jan 10, 2013 at 3:58 PM, Thomas Koch tho...@koch.ro wrote: Benson Margulies: Anyone can read http://www.apache.org/dev/open-access-svn.html to see a summary of the central idea that started this discussion: that the default authorization scheme for Subversion at Apache should be to grant technical permission to commit to all committers across the Foundation. I'm not currently active in any Apache project but have been and was very annoyed to be forced to use Subversion. Apache now support git, but I disagree as to the implication. Apache requires there to be a single, reference, repository, from which releases derive. An enumerated list of people has permission to push to that repository, and this discussion has implications for the access control on that. Therefor just for the record: The whole discussion would be meaningless if the ASF would switch to Git. (I'm not sure about the progress in this regard.) With Git, everybody can add commits to every Git repository on the Internet. One would just not be able to push them. But I can just push to my own Github account and send an email asking for a pull. Regards, Thomas Koch, http://www.koch.ro
Re: Project Culture and Commit Rights
There is nothing wrong with Subversion except for preference and difficulty in making branches. I disagree that Benson's topic is directly influenced by such a lower-rung choice as a version control system. The same discussion would be necessary if Apache were completely on Git; who can push directly? Who can't? There's also nothing wrong with the patch-on-JIRA workflow, and you end up with something similar to the Linux kernel. The tool isn't the issue here, and I disagree with any attempt to reframe it that way. -- Jed Smith j...@jedsmith.org
RE: Project Culture and Commit Rights
-Original Message- From: Jed Smith [mailto:j...@jedsmith.org] Sent: 10 January 2013 21:27 Subject: Re: Project Culture and Commit Rights ... The tool isn't the issue here, and I disagree with any attempt to reframe it that way. +1 Ross
Re: Project Culture and Commit Rights
On Sat, Jan 5, 2013 at 10:20 AM, janI j...@apache.org wrote: On 5 January 2013 19:14, Marvin Humphrey mar...@rectangular.com wrote: Mature, popular projects tend to receive more contributions than they can handle; competent review becomes the scarce resource. I question whether an RTC project would really spend a lot of time cleaning up after newbie rule-breakers, though. If I may, mature projects might sometimes benefit from new thinkers, at least that can cause quite some discussions (I talk here from personal experience). Challenging orthodoxy is important, but relaxed committership is unsuitable as a mechanism for driving discussion. Apache is a home for consensus-driven development. If an individual abuses their Apache committership to commit something controversial to the mainline, they should be blacklisted. (Regardless of seniority!) A crucial assumption underlying relaxed committership is that the overwhelming majority of contributors won't do something antisocial like that -- and thus it's wasteful to force good citizens to work outside of the version control system. That said, it's beneficial to have people doing branch development within view of the rest of the community, so that people can follow the evolution of ideas via commit emails and gradual changes to the repository. However, ideas which are introduced via branch commits are no different from ideas which are introduced via email proposals: establishing community consensus -- lazy or explicit -- for disruptive changes is still mandatory, and the project's dev list is still the appropriate forum. My initial comment was limited to RTC projects for the sake of simplicity, but CTR projects shouldn't have problems either so long as they communicate that committership comes with constraints -- as per the sample policy from Benson's original post: Commit rights to this project are granted upon request. However, committers must read, understand, and comply with our policies. When you start out, you may want to ask for review, or commit to a branch, and get feedback from the community. Outside of Apache, the Jenkins project couches its liberal committership policy similarly: https://wiki.jenkins-ci.org/display/JENKINS/Governance+Document#GovernanceDocument-Corecommitters One is not required to have a proven history of contributions before granted the committership, but that doesn’t mean other core committers will never revert your changes. Marvin Humphrey
Re: Project Culture and Commit Rights
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 robw...@apache.org wrote: On Sat, Jan 5, 2013 at 10:35 AM, Benson Margulies bimargul...@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
