On Thu, Jul 21, 2011 at 05:24, Bertrand Delacretaz
<bdelacre...@apache.org> wrote:
> Hi,
>
> On Thu, Jul 21, 2011 at 8:44 AM, Luciano Resende <luckbr1...@gmail.com> wrote:
>> It looks like various Apache projects are voting GSoC students as
>> "partial committers". As Apache does not have a formal process for
>> handling this type of account requests, regular accounts are created
>> for these students, with an Apache e-mail alias, and access is given
>> to general committer areas in SVN (e.g. committer area in svn, etc)
>> and then respective PMCs provides write access to particular areas in
>> SVN, such as a sandbox or a collaboration area. If the student fails
>> the GSoC programm, or is not elected as regular committer during or
>> after the program, there is no process for disabling/deleting these
>> accounts. This is very problematic and can cause multiple issues....
And in a *successful* case, we have a committer.
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.
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*.
I categorize communities in two ways:
* inclusive
* exclusive
If you invite people to your repository, then you're being inclusive.
You're bringing them in. You're helping them to participate in the
community. You're making them part of the standard commit/review
cycle.
If you push people away. If you say "no. you cannot commit to ASF. go
to github. go to google code. go to sourceforge. ANYWHERE but our
repository". Well... that is exclusive. And that is destructive. You
will alienate that committer. You are not making any attempt to bring
them into the community. You are forcing them into a second-class
category.
This is a problem with a long history. Groups did not understand the
value of version control. As a result, they have historically withheld
commit access under the misguided notion that some n00b might destroy
"their work". That just isn't reality. Commit privileges should be
available for the asking. Commit to *trunk* is an entirely different
question, and absolute deserves all of those historical barriers.
I see *way* too many people imposing barriers to commit, when there is
zero rational reason for it. No damage can be done.
>...
> One suggestion would be to add those accounts to a special LDAP group
> named "trainee" or something. Once GSoC ends, someone (GSoC admins or
> comdev PMC) would need to request infra to disable all of them. If a
> student is voted in as a committer in the meantime, their PMC chair
> would just remove them from the "trainee" group.
This is a fabulous idea! I'd totally sign up for this.
Cheers,
-g
