community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luciano Resende <>
Subject Re: GSoC & Temporary commit access accounts
Date Sat, 23 Jul 2011 18:23:20 GMT
On Thu, Jul 21, 2011 at 5:34 PM, Greg Stein <> wrote:
> On Thu, Jul 21, 2011 at 16:55, Benson Margulies <> wrote:
>>> Personally I feel that GSoC students should earn commit access just
>>> like anyone else.
>> I have a lot of sympathy for Greg's position. Treating 'committer' as
>> a single monolithic category drives people away.
> Right. It is necessary to distinguish between "commit access [to a
> branch]" and "commit access [to trunk]". I fully concur that access to
> trunk follows the same pattern as regular committers. GSoC students
> have no elevated rights.
> However, I think providing a GSoC student with commit to a branch is
> an easy decision, and that it should be the default policy. (for the
> reasons listed in my previous note)

That's what really bothers me, as you mentioned in a previous e-mail
on this thread, it's really just coded powered by a powerful SCM. To
me, either you trust the GSoC student to have write access to the
project code, or you don't. The distinction about branch versus trunk
shouldn't really exists, otherwise it really means you and the project
community does not trust the GSoC student and to me, if he commit to a
branch, or to git hub fork, or google code is mostly the same.

> [ next part strays from the GSoC discussion ]
>> should have to. I'd be happy to see the foundation endorse the idea
>> that a PMC can choose to grant commit karma to branches, in a trial
>> basis, to people who have submitted a suitable cla. That would not
>> given them nexus karma, web-site-editing karma, or dogma karma.
> The Subversion PMC has an operating rule that basic states, "any
> individual PMC member may grant commit access to a non-trunk area, to
> a developer with an ICLA on file". There is a subjective level to
> this: does it clearly make sense (say, a branch), or might it be a
> little controversial (say, the directory for the 'svn' command-line
> tool). For the latter, we encourage the Member to float the idea on
> private@ first. But we don't have a strict written policy here; good
> judgement is always a great replacement for more rules :-)
> I would very much encourage other PMCs to adopt similar policies.
> Again, with version control, the phrase "damage control" almost
> doesn't apply.

+1, the projects I have been following more close, they request an
ICLA on file for the students when the summer project starts
independent of any committership status. If we introduce continue the
process of access to svn areas to students, an ICLA should be a MUST
as for any other contributors.

Luciano Resende

View raw message