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
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 luckbr1...@gmail.comwrote: 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
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 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
Re: GSoC Temporary commit access accounts
+1 @ Bertrand's idea On Thu, Jul 21, 2011 at 11:24 AM, 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 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
On 7/21/2011 2:24 AM, Bertrand Delacretaz wrote: Hi, On Thu, Jul 21, 2011 at 8:44 AM, Luciano Resendeluckbr1...@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
On 21 July 2011 10: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 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
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
On 21 July 2011 21:55, Benson Margulies bimargul...@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
On Thu, Jul 21, 2011 at 4:58 PM, Ross Gardler rgard...@opendirective.com wrote: On 21 July 2011 21:55, Benson Margulies bimargul...@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
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
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
On Thu, Jul 21, 2011 at 16:55, Benson Margulies bimargul...@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
