On Thu, Jul 21, 2011 at 05:58:49AM -0400, Greg Stein wrote:
> There was a Git GSoC student that was working on improving the
> conversion speed from SVN to Git. He started a project, and one of
> those components was to use one of Subversion's wire protocols to haul
> over a repository to the client, then write it locally to an svn
> dumpfile. This Git student approached the Apache Subversion community
> with this tool concept... we thought it was awesome. We gave that
> student partial commit privileges (ie. only that tool area), and then
> he worked on the tool during the summer.
>
> That tool is now being shipped as part of Apache Subversion 1.7.
>
> Here was a student for Git, of all things, but needed something from
> Apache. We welcomed him, we made him a part of the community, and then
> he built a tool.
But we didn't give him commit access just because he was a gsoc student.
We gave him commit access because he had a non-trivial project brewing.
And because it made more sense to maintain his tool in our tree than
in git's because it is linking to Subversion libraries.
Note that he kept committing in both communities during gsoc.
He is still active in git today. I recently met his former gsoc mentor
from the git side and we had a nice chat.
> Personally: I say any PMC that makes their students second-class (e.g
> "commit your code to github, not *OUR* repository") is ridiculous. We
> have version control. There is absolutely NO possible damage that a
> committer can do. The PMC can always unwind the work before a release
> (of course, the committer could be constrained to a branch, outside of
> manipulating the release).
>
> My opinion is that social barriers have no place here. Given that we
> have version control, there is never going to be a problem. On the
> outside case, with *crazy* people(!), you may need to remove commit.
> But no committer can ever do permanent damage.
>
> On the other side: by treating them as second class citizens ("not our
> repository!"), then you can do permanent damage to *them*.
Finding the right point when to offer commit is a balancing act.
Another one of my gsoc students never got commit access.
He had originally planned a larger project to work on that would have
warranted a branch but it collided too much with wc-ng development
which was still at an early stage (this was in 2009).
So he kept sending small but very useful patches for wc-ng and other
areas instead. They always got reviewed and committed after several
iterations. He got attention from the community and the result of his
work directly went to the trunk. Hyrum ended up co-mentoring him by
getting involved in his patches.
When gsoc was over he sent a private good-bye email to me and Hyrum
thanking us for everything and sent a picture he had made as a token
of gratitude. I was sad to see him go but don't think giving him
commit would have made him stick around. The summer was over and he
wanted to (or had to) move on.
