community input on the GSoC

[Torsten Curdt <tc...@apache.org>]

Hi everyone!

I assume most of you have already heard about the
Google Summer of Code initiative [1]. A few students
would like to try helping out on some dedicated parts
of cocoon, mentored by some of our committers. If
they succeed Google will pay them some money.

Now there is a bit of a discussion on how to accept
these contributions from a work flow and infrastructure
perspective.

Some of us would like to give the students commit access
to a restricted area, others would like to show them
the usual OS way and just provide patches. Now there
are some implications that makes the decision a bit
more complicated.

On one hand having someone work full time on a
part of the project will of course generate
a lot of patches. Applying patches (and waiting
to have them applied) is not necessarily the
most fun thing to do ...it's a bottleneck
and requires additional effort from the mentors
...or committers in general.

On the other hand providing svn commit access
also means handing out an @apache.org address
(required for technical reasons) and (to some extend)
access to the apache infrastructure. Not everyone is
really excited about that. Less for security reasons,
but more how it could be perceived by the community.

Some of us fear that giving away an @apache.org
account (although it is restricted) might produce
feelings of disappointment in people who already
contributed to the community and who are on the
committer radar already.

Some fear it could be perceived we are giving away
this "honor" now for less (...although providing svn
access and the @apache.org address does *not* mean
the students magically become committers ...they'd
only get a *limited* and *temporary* access to a
separate part of our repository. There are no usual
committer privileges associated with this. No
voting rights, etc)

This post is especially directed to non-committers.
We would like to hear *your* opinion on this!
It's not a vote ...but we would just like to
hear community opinions on the following options:

 o work through patches
 o give them limited svn access
    - give them a full address (jdoe@apache.org)
    - add a prefix to the address (gsoc-jdoe@apache.org)

PLEASE!!! ...just be honest not afraid to state
your opinion.

Thanks!
--
Torsten

[1] http://code.google.com/summerofcode.html

Re: community input on the GSoC

[Niclas Hedhman <ni...@hedhman.org>]

On Friday 08 July 2005 13:52, Upayavira wrote:
> Actually, it is for two reasons. (1) because they need to run svnpasswd
> to set their password. (2) because, IIUC, mail when sent must come from
> a real email account (something to do with antispam).

1) Not really necessary :o) Convenient and necessary for the permanent people, 
but a temporary measure of 'handing a password down' is probably an 
acceptable price for involved parties.

2) This one is interesting though. The SVN I am administering uses the primary 
email address of each user as the username, and by default it works then...
Since the current svn-auth file is free from @ signs, that could work. Make 
sure they all have GMail accounts??

> More than that, I can't really say ('cos I don't understand enough).


:o) I know the feeling!


Cheers
Niclas

Re: community input on the GSoC

[Upayavira <uv...@odoko.co.uk>]

Antonio Gallardo wrote:
> Upayavira wrote:
> 
>> Niclas Hedhman wrote:
>>
>>> On Wednesday 06 July 2005 17:57, Torsten Curdt wrote:
>>>
>>>> o work through patches
>>>> o give them limited svn access
>>>>    - give them a full address (jdoe@apache.org)
>>>>    - add a prefix to the address (gsoc-jdoe@apache.org)
>>>
>>>
>>>
>>>
>>> There is no technical need to hand out a apache.org account, unless 
>>> infrastructure insist of doing this, and AFAIK the long-term target 
>>> is the exact opposite.
>>>
>>> So, why not check with infrastructure if they would support to set 
>>> SVN user accounts to john.doe@gsoc2005.google.com or something 
>>> similar, and someone trusted can just generate a password and send them.
>>>
>>> I think infra@ would be Ok, since it will be relatively easy to 
>>> "clean-up" later.
>>
>>
>>
>> Technical need is because of commit mails, not because of SVN itself. 
>> Account might not do much, but some kind of mail account must exist, 
>> IIUC.
> 
> 
> 
> Interesting. Please expand more the idea. :-) In special, why the commit 
> mails are the problem.

Actually, it is for two reasons. (1) because they need to run svnpasswd 
to set their password. (2) because, IIUC, mail when sent must come from 
a real email account (something to do with antispam).

More than that, I can't really say ('cos I don't understand enough).

Regards, Upayavira

Re: community input on the GSoC

[Antonio Gallardo <ag...@agssa.net>]

Upayavira wrote:

> Niclas Hedhman wrote:
>
>> On Wednesday 06 July 2005 17:57, Torsten Curdt wrote:
>>
>>> o work through patches
>>> o give them limited svn access
>>>    - give them a full address (jdoe@apache.org)
>>>    - add a prefix to the address (gsoc-jdoe@apache.org)
>>
>>
>>
>> There is no technical need to hand out a apache.org account, unless 
>> infrastructure insist of doing this, and AFAIK the long-term target 
>> is the exact opposite.
>>
>> So, why not check with infrastructure if they would support to set 
>> SVN user accounts to john.doe@gsoc2005.google.com or something 
>> similar, and someone trusted can just generate a password and send them.
>>
>> I think infra@ would be Ok, since it will be relatively easy to 
>> "clean-up" later.
>
>
> Technical need is because of commit mails, not because of SVN itself. 
> Account might not do much, but some kind of mail account must exist, 
> IIUC.


Interesting. Please expand more the idea. :-) In special, why the commit 
mails are the problem.

Best Regards,

Antonio Gallardo.

Re: community input on the GSoC

[Upayavira <uv...@odoko.co.uk>]

Niclas Hedhman wrote:
> On Wednesday 06 July 2005 17:57, Torsten Curdt wrote:
> 
>> o work through patches
>> o give them limited svn access
>>    - give them a full address (jdoe@apache.org)
>>    - add a prefix to the address (gsoc-jdoe@apache.org)
> 
> 
> There is no technical need to hand out a apache.org account, unless 
> infrastructure insist of doing this, and AFAIK the long-term target is the 
> exact opposite.
> 
> So, why not check with infrastructure if they would support to set SVN user 
> accounts to john.doe@gsoc2005.google.com or something similar, and someone 
> trusted can just generate a password and send them.
> 
> I think infra@ would be Ok, since it will be relatively easy to "clean-up" 
> later.

Technical need is because of commit mails, not because of SVN itself. 
Account might not do much, but some kind of mail account must exist, IIUC.

Upayavira

Re: community input on the GSoC

[Niclas Hedhman <ni...@hedhman.org>]

On Wednesday 06 July 2005 17:57, Torsten Curdt wrote:
>  o work through patches
>  o give them limited svn access
>     - give them a full address (jdoe@apache.org)
>     - add a prefix to the address (gsoc-jdoe@apache.org)

There is no technical need to hand out a apache.org account, unless 
infrastructure insist of doing this, and AFAIK the long-term target is the 
exact opposite.

So, why not check with infrastructure if they would support to set SVN user 
accounts to john.doe@gsoc2005.google.com or something similar, and someone 
trusted can just generate a password and send them.

I think infra@ would be Ok, since it will be relatively easy to "clean-up" 
later.


Just a thought.

Niclas

Re: community input on the GSoC

[Peter Hunsberger <pe...@gmail.com>]

On 7/6/05, Torsten Curdt <tc...@apache.org> wrote:
> Hi everyone!
> 
> I assume most of you have already heard about the
> Google Summer of Code initiative [1]. A few students
> would like to try helping out on some dedicated parts
> of cocoon, mentored by some of our committers. If
> they succeed Google will pay them some money.
> 

<snip/>

> 
> This post is especially directed to non-committers.
> We would like to hear *your* opinion on this!
> It's not a vote ...but we would just like to
> hear community opinions on the following options:
> 
>  o work through patches
>  o give them limited svn access
>    - give them a full address (jdoe@apache.org)
>    - add a prefix to the address (gsoc-jdoe@apache.org)
> 

Until policy changes here at work I'll never be on the "committer
radar" so to speak, however, FWIW I'd say absolutely give them limited
SVN access.  They may end up doing as much or more work then some of
the existing committers, and it should be as easy as possible for them
to make their contributions.  The easier it is for them to make
contributions to Cocoon the better the chance that some real progress
will be made.

No real opinion on the e-mail address, the prefix seems somewhat
reasonable, but maybe you'll want to keep some of these people as
committers even after the GSOC contribution period is done? It might
be nice if they didn't have their e-mail address change if this
happens...

-- 
Peter Hunsberger

Re: community input on the GSoC

[Joerg Heinicke <jo...@gmx.de>]

On 06.07.2005 12:36, Jorg Heymans wrote:

> Is having a separate branch per GSOC project an option? That way they
> can play all they like, all it would need is a few days of integration
> maybe at the end of the project. Repository permissions are clearer, and
> anyone interested in the progress would just need to check out the
> appropriate branch.

They only get access to a "directory per GSOC project" in the whiteboard.

Joerg

Re: community input on the GSoC

[David Crossley <cr...@apache.org>]

Jorg Heymans wrote:
> Torsten Curdt wrote:
> 
> > On the other hand providing svn commit access
> > also means handing out an @apache.org address
> > (required for technical reasons) and (to some extend)
> > access to the apache infrastructure. Not everyone is
> > really excited about that. Less for security reasons,
> > but more how it could be perceived by the community.
> > 
> > Some of us fear that giving away an @apache.org
> > account (although it is restricted) might produce
> > feelings of disappointment in people who already
> > contributed to the community and who are on the
> > committer radar already.
> 
> I don't see how this should affect people "on the committer radar". If
> you're on the "committer radar" you'll perfectly understand what GSOC is
> and does and what the goals of the project are and how it really can
> benefit cocoon.

Thanks for responding. I am very pleased that you see
it that way. Even for people who are not on that radar,
we need to ensure that they know that the process is still
the same, i.e. based on merit.

The discussion about what the Cocoon PMC look for
(every ASF project has similarities, but different)
when inviting new committers is something for another thread.
It would be good to make sure that the community knows that,
and also why there are often long delays between inviting
new committers.

-David

Re: community input on the GSoC

[Jorg Heymans <jh...@domek.be>]

Torsten Curdt wrote:

> 
> On the other hand providing svn commit access
> also means handing out an @apache.org address
> (required for technical reasons) and (to some extend)
> access to the apache infrastructure. Not everyone is
> really excited about that. Less for security reasons,
> but more how it could be perceived by the community.
> 
> Some of us fear that giving away an @apache.org
> account (although it is restricted) might produce
> feelings of disappointment in people who already
> contributed to the community and who are on the
> committer radar already.

I don't see how this should affect people "on the committer radar". If
you're on the "committer radar" you'll perfectly understand what GSOC is
and does and what the goals of the project are and how it really can
benefit cocoon.

> 
> Some fear it could be perceived we are giving away
> this "honor" now for less (...although providing svn
> access and the @apache.org address does *not* mean
> the students magically become committers ...they'd
> only get a *limited* and *temporary* access to a
> separate part of our repository. There are no usual
> committer privileges associated with this. No
> voting rights, etc)

I wouldn't rate contributing to cocoon via GSOC less than contributing
through normal patches. So IMO the "honor" (even though temporary) is
equally deserved here.

>  o give them limited svn access
yes
>     - give them a full address (jdoe@apache.org)
yes
>     - add a prefix to the address (gsoc-jdoe@apache.org)
don't see why but then again why not


Is having a separate branch per GSOC project an option? That way they
can play all they like, all it would need is a few days of integration
maybe at the end of the project. Repository permissions are clearer, and
anyone interested in the progress would just need to check out the
appropriate branch.


I'ld say we make it as easy as possible for these guys to get motivated
and to contribute in the most efficient way.


Regards
Jorg