Re: community input on the GSoC
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
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
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
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 ([EMAIL PROTECTED])
- add a prefix to the address ([EMAIL PROTECTED])
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 [EMAIL PROTECTED] 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
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 ([EMAIL PROTECTED]) - add a prefix to the address ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED] 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
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 ([EMAIL PROTECTED]) - add a prefix to the address ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED] 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
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 ([EMAIL PROTECTED]) > - add a prefix to the address ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED] 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
On 7/6/05, Torsten Curdt <[EMAIL PROTECTED]> 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. > > > 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 ([EMAIL PROTECTED]) >- add a prefix to the address ([EMAIL PROTECTED]) > 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: Re: community input on the GSoC
Hi everyone, I am one of the lucky few GSOC'ers. Personally, I really don't mind any way of contribution, I am grateful for any way the community lets me contribute. Agreed, patches will be extra work, but will probably make the work noticed more than some messages in the SVN logs. About the "honor" of becoming a committer (be it temporary or not): I understand that the ASF is built on "Meritocracy", potential committers have to earn the right of being one. If you think about it, how many people who may want to become committers actually do? Now hold this number against 9000 application to the 410 GSOC spaces... I think being selected for GSOC in the first place is a great honor in itself, but I think it also does bring some merit with it which may, to some extend, contribute to potential committer karma. ... and therefore also to a temporary apache account? I do realize though that there is a fair deal of community experience involved in becoming a "real" committer, which of course I am striving for as well. So, Google pushing students into this community is circumventing the normal process, which goes against the community, but blocking their efforts may be frustrating to the students as well. Personally, I don't think anyone accepted to GSOC signed up only for the money (which gives everyone in the program a huge headache because of US tax regulations, but that is another story), but because they wanted to contribute and did not have the resources to do so before. Imagine you would be one of the GSOC'ers, wouldn't you be at least a little disappointed if the same organization which picked you for the project doesn't reciprocate in any way, however small? Sorry, I wanted to avoid making a case for my own kind. I just wanted to convey both sides of the story. ;) Best regards, Max Pfingsthorn -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Jorg Heymans Sent: Wednesday, July 06, 2005 12:37 To: dev@cocoon.apache.org Subject: Re: community input on the GSoC 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 ([EMAIL PROTECTED]) yes > - add a prefix to the address ([EMAIL PROTECTED]) 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
Re: community input on the GSoC
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 ([EMAIL PROTECTED]) yes > - add a prefix to the address ([EMAIL PROTECTED]) 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
