SVN Commit Access Guidelines

Discussion created by slushpupie Champion on May 29, 2009
Latest reply on Sep 22, 2009 by niess

Ill start this off with a discussion on how we think we should give svn access to the community.


A few thoughts on my mind:


Copyright/ownership: Jive had people sign a form giving ownership of the contributed code to them, essentially. This made sense for splitting the license between commercial and GPL, but that has gone away now.  But the idea is still useful; look at the Linux kernel for an example.  With so many contributors, they couldn't change from GPLv2 to GPLv3 if they wanted to (they cant get the consent of all the owners) How are other projects handling this? How do *we* want to handle this? Im pretty sure that as of today all users with access have signed such an agreement with Jive Software, so we at least have a clear starting point. Does Jive still want legal ownership over the code? Or with this move is that changing?


Vetting: I dont like the idea of giving access to any random person with a patch to apply.  Debian created a community of developers that handles this well most of the time (it has its share of kinks too).  The idea is to become a developer, you must first be "mentored" by an existing developer until you meet certain requirements.  I personally feel that Debian's idea is good, but their current implementation is too clumbersome for new developers. Since we are a smaller group, we can make the rules a little easier.  My first thought was

  1. Get assigned a mentor
  2. Submit patches to the mentor that close N issues (where N = 2-5??)
  3. Mentor (and others) review patches, make commits on behalf of dev-in-training

After those steps are complete, (and the above ownership issues addressed) svn commit access is granted. I dont think its good to open up svn access to just anyone, but the bar needs to be lowered a little.


It might also be worth looking into using ACL's in the svn trees-  For example; after getting svn access, you only get access to trunk.  You need to be vetted further (elected? appointed?) to put changes into tagged releases/branches/etc.  Ive not used svn acls before, so I dont know how hard that would be to manage.


I think all people with svn commit access should be indicated in some way in the forums.  Maybe this is what the KeyContributor badge is for.  Can a person have more than one badge in the forums? Like having badges for dev-in-training, developer, issue-reporter, etc