You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@community.apache.org by Luciano Resende <lu...@gmail.com> on 2011/07/21 08:44:28 UTC
GSoC & Temporary commit access accounts
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.
As the PMC overseeing the GSoC program at Apache, I'd like to see a
set of recommendations, guidelines and if necessary processes on how
to handle these cases. Having said that, I believe students are and
should be treated as any other community contributor, that have design
discussions on the project mailing list, and provides patch towards
earning trust and committership status as a community recognition of
his contributions.
What are your thoughts on what should be the official recommendation,
and based on that we can discuss required processes.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: GSoC & Temporary commit access accounts
Posted by Stefan Sperling <st...@apache.org>.
On Thu, Jul 21, 2011 at 01:19:14AM -0700, Ted Dunning wrote:
> I completely agree with this.
>
> Mahout has worked on just this basis quite well.
At Subversion we did this, too, during the last two years (we have
no gsoc student this year). It has been working extremely well.
In some cases gsoc students already had commit access because of
prior work they did on the project.
I personally think it is not a good idea to hand out commit access to
gsoc students just because they're gsoc students. This is not how open
source works in reality. gsoc is a training program for open source
developers and should mirror the real experience.
Submitting patches also forces students to build their work in pieces
which can be reviewed. It helps them with organising their commits
when they attain commit access later.
gsoc students can be expected to learn about git/mercurial if they really
need local commits (or wait until Greg finishes 'svn checkpoint' :)
I've recommended mercurial patch queues to students I've mentored:
http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html
> I haven't observed a need for any "partial committer" status. I certainly
> don't see any need to issue apache.org email addresses to students.
To prevent unnecessary overloading of this term, I'd like to point out
that in Subversion a "partial committer" is someone who is granted
access to a particular subdirectory or a branch.
http://subversion.apache.org/docs/community-guide/roles.html#partial-commit-access
This has nothing to do with gsoc. The access is usually never revoked.
Re: GSoC & Temporary commit access accounts
Posted by Ted Dunning <te...@gmail.com>.
I completely agree with this.
Mahout has worked on just this basis quite well.
Where it is deemed important for students to be allowed to commit changes,
we have used github as a temporary work area, but all changes committed to
the project code have been committed by actual committers with the
concurrence of the rest of the committers. We watch to make sure that
temporary work areas do not involve inadvertent inclusion of code not
produced by the students.
I haven't observed a need for any "partial committer" status. I certainly
don't see any need to issue apache.org email addresses to students.
On Wed, Jul 20, 2011 at 11:44 PM, Luciano Resende <lu...@gmail.com>wrote:
> As the PMC overseeing the GSoC program at Apache, I'd like to see a
> set of recommendations, guidelines and if necessary processes on how
> to handle these cases. Having said that, I believe students are and
> should be treated as any other community contributor, that have design
> discussions on the project mailing list, and provides patch towards
> earning trust and committership status as a community recognition of
> his contributions.
>
> What are your thoughts on what should be the official recommendation,
> and based on that we can discuss required processes.
>
Re: GSoC & Temporary commit access accounts
Posted by Luciano Resende <lu...@gmail.com>.
On Fri, Jul 22, 2011 at 1:03 AM, ant elder <an...@gmail.com> wrote:
> On Thu, Jul 21, 2011 at 7:44 AM, Luciano Resende <lu...@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.
>>
>
> Can there be more details about "very problematic and can cause
> multiple issues"?
>
> From what i understand this issue is raised because there was a GSoC
> project having a mentor who wasn't a committer on the ASF project.
> Isn't an answer then to just have a GSoC admin validation step to make
> sure each ASF project is aware of and ACKs the GSoC projects and
> mentors assigned to them?
>
> ...ant
>
The main problem is that there is no process and no control. The issue
you mentioned is one that we caught (and I believe we don't know how
to handle at the moment). But because any account request from PMCs
are treated equally, there might be other cases that we are not aware
yet.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: GSoC & Temporary commit access accounts
Posted by ant elder <an...@gmail.com>.
On Thu, Jul 21, 2011 at 7:44 AM, Luciano Resende <lu...@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.
>
Can there be more details about "very problematic and can cause
multiple issues"?
>From what i understand this issue is raised because there was a GSoC
project having a mentor who wasn't a committer on the ASF project.
Isn't an answer then to just have a GSoC admin validation step to make
sure each ASF project is aware of and ACKs the GSoC projects and
mentors assigned to them?
...ant
Re: GSoC & Temporary commit access accounts
Posted by Mohammad Nour El-Din <no...@gmail.com>.
+1 @ Bertrand's idea
On Thu, Jul 21, 2011 at 11:24 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Hi,
>
> On Thu, Jul 21, 2011 at 8:44 AM, Luciano Resende <lu...@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....
>
> I'd say those are temporary accounts rather than partial, and from the
> GSoC point of view I think it's good to have them.
>
> As you say the issue is making sure those accounts are disabled once
> GSoC ends, as we would do when a trainee leaves you company.
>
> 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.
>
> -Bertrand
>
--
Thanks
- Mohammad Nour
Author of (WebSphere Application Server Community Edition 2.0 User Guide)
http://www.redbooks.ibm.com/abstracts/sg247585.html
- LinkedIn: http://www.linkedin.com/in/mnour
- Blog: http://tadabborat.blogspot.com
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
"Writing clean code is what you must do in order to call yourself a
professional. There is no reasonable excuse for doing anything less
than your best."
- Clean Code: A Handbook of Agile Software Craftsmanship
"Stay hungry, stay foolish."
- Steve Jobs
Re: GSoC & Temporary commit access accounts
Posted by Kathey Marsden <km...@sbcglobal.net>.
On 7/21/2011 2:24 AM, Bertrand Delacretaz wrote:
> Hi,
>
> On Thu, Jul 21, 2011 at 8:44 AM, Luciano Resende<lu...@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....
> I'd say those are temporary accounts rather than partial, and from the
> GSoC point of view I think it's good to have them.
>
> As you say the issue is making sure those accounts are disabled once
> GSoC ends, as we would do when a trainee leaves you company.
>
> 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.
Would they therefore not be in committers with access to the
committers private area? If that is the case, it might clarify their
status in everyone's view.
Personally, for google summer of code and for all development, I tend to
think a normal small incremental patch review commit model into trunk is
best, avoiding large code merges that are not easy to review, well
tested or well understood by the community. This of course really
reduces the scope of what students can submit in a summer but means it
will make it into production and they will learn what it takes to
produce production code. Leading up to that point, I understand the
need for prototyping. Is that what these branches and the these
temporary accounts are about, a place to build a prototype? I am also
curious. Are these temporary accounts given to others outside of GSOC
who want to work on a project in the community?
Thanks
Kathey
Re: GSoC & Temporary commit access accounts
Posted by Stefan Sperling <st...@apache.org>.
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.
Re: GSoC & Temporary commit access accounts
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Jul 21, 2011 at 05:24, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Hi,
>
> On Thu, Jul 21, 2011 at 8:44 AM, Luciano Resende <lu...@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
Re: GSoC & Temporary commit access accounts
Posted by Benson Margulies <bi...@gmail.com>.
On Thu, Jul 21, 2011 at 4:58 PM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 21 July 2011 21:55, Benson Margulies <bi...@gmail.com> 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.
>
> (I'll ignore the fact that you have cut the part of my message in
> which I say we shouldn't force my opinion on people)
Ross, I apologize. I wasn't trying to represent this as your view, I
was just trying to shrink the size of the email.
>
>> A typical problem case is someone who sets out to undertake a big,
>> complex, contribution.
>
> That is not a GSoC case. So is irrelevant to this discussion (but is
> certainly relevant to giving commit access in general).
I was originally going to write, "Students are not precisely this
case, but if it was culturally acceptable in general to grant commit
access on branches to people before granting full committer status,
that policy could be used to justify granting it to students." I guess
I should have.
>
> Ross
>
Re: GSoC & Temporary commit access accounts
Posted by Ross Gardler <rg...@opendirective.com>.
On 21 July 2011 21:55, Benson Margulies <bi...@gmail.com> 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.
(I'll ignore the fact that you have cut the part of my message in
which I say we shouldn't force my opinion on people)
> A typical problem case is someone who sets out to undertake a big,
> complex, contribution.
That is not a GSoC case. So is irrelevant to this discussion (but is
certainly relevant to giving commit access in general).
Ross
Re: GSoC & Temporary commit access accounts
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Jul 22, 2011 at 10:30 AM, Edward J. Yoon <ed...@apache.org> wrote:
> Sorry this is other question but, one of my students asked about
> "anyone can jump in and volunteer to be a committer."[1] ..........
>
> What's the exact policy on this?
That would be a question for general@incubator.apache.org
-Bertrand
>
> 1. http://markmail.org/thread/jb63zsbenmanr3fs
Re: GSoC & Temporary commit access accounts
Posted by "Edward J. Yoon" <ed...@apache.org>.
Sorry this is other question but, one of my students asked about
"anyone can jump in and volunteer to be a committer."[1] ..........
What's the exact policy on this?
1. http://markmail.org/thread/jb63zsbenmanr3fs
Thanks,
Ed
On Fri, Jul 22, 2011 at 5:03 PM, ant elder <an...@gmail.com> wrote:
> On Fri, Jul 22, 2011 at 1:34 AM, Greg Stein <gs...@gmail.com> wrote:
>> On Thu, Jul 21, 2011 at 16:55, Benson Margulies <bi...@gmail.com> 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)
>>
>> [ 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.
>>
>> Cheers,
>> -g
>>
>
> I agree with Greg and the others in favour of keeping it easy to get
> write access, and i really like the Subversion PMC approach.
>
> I don't understand the mindset that commit access should be hard to
> get or something that must be worked hard to earn. Most project i
> watch don't find it that easy to attract new developers so when one
> does turn up i think its better to be open and welcoming and not be
> like "thanks but earn you place first" which is more likely to just
> discourage them.
>
> ...ant
>
--
Best Regards, Edward J. Yoon
@eddieyoon
Re: GSoC & Temporary commit access accounts
Posted by ant elder <an...@gmail.com>.
On Fri, Jul 22, 2011 at 1:34 AM, Greg Stein <gs...@gmail.com> wrote:
> On Thu, Jul 21, 2011 at 16:55, Benson Margulies <bi...@gmail.com> 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)
>
> [ 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.
>
> Cheers,
> -g
>
I agree with Greg and the others in favour of keeping it easy to get
write access, and i really like the Subversion PMC approach.
I don't understand the mindset that commit access should be hard to
get or something that must be worked hard to earn. Most project i
watch don't find it that easy to attract new developers so when one
does turn up i think its better to be open and welcoming and not be
like "thanks but earn you place first" which is more likely to just
discourage them.
...ant
Re: GSoC & Temporary commit access accounts
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Jul 21, 2011 at 5:34 PM, Greg Stein <gs...@gmail.com> wrote:
> On Thu, Jul 21, 2011 at 16:55, Benson Margulies <bi...@gmail.com> 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
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: GSoC & Temporary commit access accounts
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Jul 21, 2011 at 16:55, Benson Margulies <bi...@gmail.com> 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)
[ 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.
Cheers,
-g
Re: GSoC & Temporary commit access accounts
Posted by Benson Margulies <bi...@gmail.com>.
>
> 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.
A typical problem case is someone who sets out to undertake a big,
complex, contribution. Without at least svn commit access to a branch,
the overhead can get so onerous to drive people away. yes, the mentor
can be a human mirror and push stuff into a branch. That's a lot of
extra work. I've seen it happen. Yes, various tricks with git
mitigate. On the other hand, having the code in svn in a branch allows
the PMC to supervise the contribution much more easily. When I first
turned up at Apache, I deferred work on the main project I had in mind
for months and pecked away at small bugs to earn committer status. Not
everyone has that much patience, and not everyone, in my opinion,
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.
Re: GSoC & Temporary commit access accounts
Posted by Raymond Feng <en...@gmail.com>.
I agree with Luciano that GSoC students should practice working with open source project as other contributors do. IMO, most of existing open source projects don't grant write access to the contributors right away. Going through the patch process is a typical approach for contributors to engage with the community. By my own experience, it usually gives me a sense of achievement if the patches are reviewed and applied.
Some SCM tools make the patching process even more simpler. For example, github allows the developers to clone the repository and request to merge their changes in the streamlined fashion. It would be attractive if ASF provides some infrastructure toward simpler collaborations.
Thanks,
Raymond
________________________________________________________________
Raymond Feng
rfeng@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
________________________________________________________________
On Jul 23, 2011, at 11:15 AM, Luciano Resende wrote:
> On Thu, Jul 21, 2011 at 1:44 PM, Ross Gardler
> <rg...@opendirective.com> wrote:
>> On 21 July 2011 10:24, Bertrand Delacretaz <bd...@apache.org> wrote:
>>> Hi,
>>>
>>> On Thu, Jul 21, 2011 at 8:44 AM, Luciano Resende <lu...@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....
>>>
>>> I'd say those are temporary accounts rather than partial, and from the
>>> GSoC point of view I think it's good to have them.
>>
>> As long as we ensure they are really temporary I agree.
>>
>> Personally I feel that GSoC students should earn commit access just
>> like anyone else. However, being a mentor is a time consuming task and
>> we have to balance mentoring effort against the payback they get. We
>> can also argue that the evaluation process is, when done right, is
>> almost as rigorous as the process of becoming a committer.
>>
>> I think it is important to ensure mentors and PMCs get to choose the
>> way they work with GSoC students. Personally I will still require
>> students to submit regular patches but I don't feel we should dictate
>> that practice.
>>
>
> That's my view as well, one of the ideas is that the GSoC will give
> the student experience working on open source, and I don't believe the
> regular open source experience is to give write access to source
> repository for every initial contributor. Having said that, I have
> seen others say that they want to provide write access to the
> students, but then this access should be restricted to a branch or to
> a isolated code, to me, this still isolates and don't foster
> integration with the project community that will be paying much more
> attention and reviewing contributions to the trunk. In the past, most
> of the students I mentored ended upping getting committership on the
> projects they participated after a initial period of patches
> contributions and community interaction.
>
> Having said that, I'm yet to really receive any complaints and
> requests from the GSoC Students where they say they are not being
> productive by providing patches, etc... So i tend to think this is a
> way for the mentors to avoid having to review and apply patches.
>
>>> 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.
>>
>> +1
>>
>
> +1, I think that, for those projects that want to provide these
> accounts for the GSoC students, this is a good process with the
> addition that they shouldn't have access to committer area as
> suggested by Kathey.
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
Re: GSoC & Temporary commit access accounts
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Jul 21, 2011 at 1:44 PM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 21 July 2011 10:24, Bertrand Delacretaz <bd...@apache.org> wrote:
>> Hi,
>>
>> On Thu, Jul 21, 2011 at 8:44 AM, Luciano Resende <lu...@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....
>>
>> I'd say those are temporary accounts rather than partial, and from the
>> GSoC point of view I think it's good to have them.
>
> As long as we ensure they are really temporary I agree.
>
> Personally I feel that GSoC students should earn commit access just
> like anyone else. However, being a mentor is a time consuming task and
> we have to balance mentoring effort against the payback they get. We
> can also argue that the evaluation process is, when done right, is
> almost as rigorous as the process of becoming a committer.
>
> I think it is important to ensure mentors and PMCs get to choose the
> way they work with GSoC students. Personally I will still require
> students to submit regular patches but I don't feel we should dictate
> that practice.
>
That's my view as well, one of the ideas is that the GSoC will give
the student experience working on open source, and I don't believe the
regular open source experience is to give write access to source
repository for every initial contributor. Having said that, I have
seen others say that they want to provide write access to the
students, but then this access should be restricted to a branch or to
a isolated code, to me, this still isolates and don't foster
integration with the project community that will be paying much more
attention and reviewing contributions to the trunk. In the past, most
of the students I mentored ended upping getting committership on the
projects they participated after a initial period of patches
contributions and community interaction.
Having said that, I'm yet to really receive any complaints and
requests from the GSoC Students where they say they are not being
productive by providing patches, etc... So i tend to think this is a
way for the mentors to avoid having to review and apply patches.
>> 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.
>
> +1
>
+1, I think that, for those projects that want to provide these
accounts for the GSoC students, this is a good process with the
addition that they shouldn't have access to committer area as
suggested by Kathey.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: GSoC & Temporary commit access accounts
Posted by Ross Gardler <rg...@opendirective.com>.
On 21 July 2011 10:24, Bertrand Delacretaz <bd...@apache.org> wrote:
> Hi,
>
> On Thu, Jul 21, 2011 at 8:44 AM, Luciano Resende <lu...@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....
>
> I'd say those are temporary accounts rather than partial, and from the
> GSoC point of view I think it's good to have them.
As long as we ensure they are really temporary I agree.
Personally I feel that GSoC students should earn commit access just
like anyone else. However, being a mentor is a time consuming task and
we have to balance mentoring effort against the payback they get. We
can also argue that the evaluation process is, when done right, is
almost as rigorous as the process of becoming a committer.
I think it is important to ensure mentors and PMCs get to choose the
way they work with GSoC students. Personally I will still require
students to submit regular patches but I don't feel we should dictate
that practice.
> 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.
+1
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
Re: GSoC & Temporary commit access accounts
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Thu, Jul 21, 2011 at 8:44 AM, Luciano Resende <lu...@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....
I'd say those are temporary accounts rather than partial, and from the
GSoC point of view I think it's good to have them.
As you say the issue is making sure those accounts are disabled once
GSoC ends, as we would do when a trainee leaves you company.
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.
-Bertrand