Re: GSoC & Temporary commit access accounts
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) [ 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
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 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 4:58 PM, Ross Gardler wrote: > On 21 July 2011 21: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. > > (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 21 July 2011 21: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. (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
> > 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 10:24, Bertrand Delacretaz wrote: > Hi, > > On Thu, Jul 21, 2011 at 8:44 AM, Luciano Resende 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
On 7/21/2011 2:24 AM, Bertrand Delacretaz wrote: Hi, On Thu, Jul 21, 2011 at 8:44 AM, Luciano Resende 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 Thu, Jul 21, 2011 at 05:24, Bertrand Delacretaz
wrote:
> Hi,
>
> On Thu, Jul 21, 2011 at 8:44 AM, Luciano Resende 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
+1 @ Bertrand's idea On Thu, Jul 21, 2011 at 11:24 AM, Bertrand Delacretaz wrote: > Hi, > > On Thu, Jul 21, 2011 at 8:44 AM, Luciano Resende 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
Hi, On Thu, Jul 21, 2011 at 8:44 AM, Luciano Resende 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
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 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. >
