In order to avoid mile-long emails I'm starting over.
I think our overall goal is to strengthen the geronimo community by bringing in new developers and code that we as well as they want to work on.
This process is likely to be more work for us than the new developers, since they already know their code very well, whereas we need to learn their code and more importantly mentor them into being part of the geronimo community. Therefore, we need to put together a process that involves the least work for us, and we need to commit the time needed to be good mentors. To me, this means that the new people need to be given commit access to at least their donated code, since we simply won't have time to review all the patches that are likely to result otherwise, and the svn structure needs to be set up for minimal nuisance/simplest builds. I think the last would be best with the new code going somewhere in the geronimo/trunk tree: although svn tricks are certainly possible to pull it in from elsewhere in apache svn, this would add some complexity for no gain I can see.
I also think it is important to publish a process for donations, so we don't spend weeks discussing this every time someone offers something, and so potential donors know what to expect and dont get the idea that we are playing favorites. If we run into problems, we can certainly update the process.
I'd like to reemphasize that bringing in new committers with their code is going to be a lot of work for the existing community. If we fail to integrate a donation a very large part of the responsibility rests with us for not having good enough community skills to work with the newcomers. It seems to me that discussions about limited commit access/ acls/ etc are fundamentally discussions about what happens if we fail. I wonder what would happen if we instead discussed how we will provide superb support and mentoring for our new members and left the questions of what to do if we fail to such time as it might be needed.
thanks david jencks
