summer of code - next steps
It appears that 2 (or 3) tomcat related projects have been accepted.. - reverse proxy - jsp compilation speed - JSTL tag plugins (Unless this belongs to the jakarta taglib folks) How should code be accepted for these? - Create a new sandbox? - Place on SF then have the mentor commit as needed - Full commit for the student - Other This was talked about on the other mailing lists. For those using svn - it seems a temporary account can be given to svn without needing to provide a shell account. Since we are using cvs - thats not possible. Thoughts? -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Summer of code - next steps?
For those interested in Summer of code what do we need to do next? Is having the Wiki up to date enough? And we sit back while participants submit their proposals and Google chooses whom will get the stipend, while the folks listed on the Wiki mentor? http://code.google.com/soc_application.html -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Summer of code - next steps?
Tim Funk wrote: For those interested in Summer of code what do we need to do next? Is having the Wiki up to date enough? And we sit back while participants submit their proposals and Google chooses whom will get the stipend, while the folks listed on the Wiki mentor? http://code.google.com/soc_application.html Very good questions :) I'm interested too. I added the JSTL tag plugins for Jasper as another project, BTW. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Summer of code - next steps?
I re-re-read the FAQ and here is what I interpret: Anyone may submit to Google a proposal (any meaning a student). Google will then take their favorite 200 and pass these along to the mentoring organizations. The mentoring organizations can give a thumbs up or down because they need to approve that the work was done at the end of the time period. Its up to the discretion of each project to incorporate the code produced by the student. But if the code is not worthy to be accepted, the student can still be paid (by Google) if the mentor says its OK. [I would imagine there could be cases where code is produced but not committed for a variety of reasons.] So it seems the wiki was a communication vehicle to let folks know what project mentoring organizatoins were interested in since it was up the mentoring organizations to say yes or no to whether they wish to mentor a specific proposal. I have no idea of the ramifications if multiple folks are interested in the same project and it they should submit competing or complementary proposals. I guess the google group dedicated to this has more information there. -Tim Remy Maucherat wrote: Tim Funk wrote: For those interested in Summer of code what do we need to do next? Is having the Wiki up to date enough? And we sit back while participants submit their proposals and Google chooses whom will get the stipend, while the folks listed on the Wiki mentor? http://code.google.com/soc_application.html Very good questions :) I'm interested too. I added the JSTL tag plugins for Jasper as another project, BTW. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: summer of code - next steps
Tim Funk wrote: It appears that 2 (or 3) tomcat related projects have been accepted.. - reverse proxy - jsp compilation speed As I understand it, the above two are a done deal. I'll mentor the second one. - JSTL tag plugins (Unless this belongs to the jakarta taglib folks) Oviously it's taglib related, but I don't think taglibs have business shipping Tomcat proprietary code. How should code be accepted for these? - Create a new sandbox? - Place on SF then have the mentor commit as needed SF CVS doesn't work well enough IMO. Maybe the ASF will have a repository that can be used as a staging area. - Full commit for the student I suspect it could happen fairly quickly. - Other This was talked about on the other mailing lists. For those using svn - it seems a temporary account can be given to svn without needing to provide a shell account. Since we are using cvs - thats not possible. That's what I understood (more or less). I propose we take the code in SVN, and put it in our CVS when it gets ready. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: summer of code - next steps
Hey, > > How should code be accepted for these? > > - Create a new sandbox? > > - Place on SF then have the mentor commit as needed > > SF CVS doesn't work well enough IMO. Maybe the ASF will have a > repository that can be used as a staging area. > > > - Full commit for the student > > I suspect it could happen fairly quickly. We've been planning to give the students commit access to just their section of code, or an entirely separate repository. Remy's suggestion of SVN first is good, because SVN allows configuring commit access to users on a directory level. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: summer of code - next steps
Would this work? Or request restricted access to only - jakarta-tomcat-jasper - jakarta-tomcat-catalina/webapps/balancer The user id id would be prefixed or suffixed with soc. This also assumes no binding voting rights. Thoughts? - Drop the soc from the userid ? - Let them be full committers ? - Other? Since tomcat seems to be one of the last ones in cvs - I am not sure how using svn will work with respect to this. Do we need a vote so we can make the appropriate requests to infrastructure? -Tim Yoav Shapira wrote: Hey, How should code be accepted for these? - Create a new sandbox? - Place on SF then have the mentor commit as needed SF CVS doesn't work well enough IMO. Maybe the ASF will have a repository that can be used as a staging area. - Full commit for the student I suspect it could happen fairly quickly. We've been planning to give the students commit access to just their section of code, or an entirely separate repository. Remy's suggestion of SVN first is good, because SVN allows configuring commit access to users on a directory level. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: summer of code - next steps
Hi, > Would this work? Or request restricted access to only > - jakarta-tomcat-jasper > - jakarta-tomcat-catalina/webapps/balancer > > The user id id would be prefixed or suffixed with soc. This also assumes > no > binding voting rights. > > Thoughts? > - Drop the soc from the userid ? > - Let them be full committers ? > - Other? > > Since tomcat seems to be one of the last ones in cvs - I am not sure how > using svn will work with respect to this. > > Do we need a vote so we can make the appropriate requests to > infrastructure? We're in a bit of a bind. I don't want to let them be full committers: that's a hard-earned privilege. Same thing for the @apache.org address, so I want to keep the soc prefix. But we use CVS, and I don't think CVS supports directory-specific commit privileges. We'd have to make a branch for them, assuming CVS supports branch-specific commit privileges? Yoav Shapira System Design and Management Fellow MIT Sloan School of Management / School of Engineering Cambridge, MA USA [EMAIL PROTECTED] / [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: summer of code - next steps
Thank-you for your e-mail. Please note that i will be away from the office starting Wednesday June 29th, returning Thursday July 7th, with no access to email. In my absence, kindly contact Cheri Dueck at [EMAIL PROTECTED] Kind Regards, Natasha Hasmani Senior Event Manager - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: summer of code - next steps
Thank-you for your e-mail. Please note that i will be away from the office starting Wednesday June 29th, returning Thursday July 7th, with no access to email. In my absence, kindly contact Cheri Dueck at [EMAIL PROTECTED] Kind Regards, Natasha Hasmani Senior Event Manager - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: summer of code - next steps
It would require 2 new entries in the avail document in CVSROOT - so while its possible - I'm not sure if infrastructure would wish to deal with that. -Tim Yoav Shapira wrote: Hi, Would this work? Or request restricted access to only - jakarta-tomcat-jasper - jakarta-tomcat-catalina/webapps/balancer The user id id would be prefixed or suffixed with soc. This also assumes no binding voting rights. Thoughts? - Drop the soc from the userid ? - Let them be full committers ? - Other? Since tomcat seems to be one of the last ones in cvs - I am not sure how using svn will work with respect to this. Do we need a vote so we can make the appropriate requests to infrastructure? We're in a bit of a bind. I don't want to let them be full committers: that's a hard-earned privilege. Same thing for the @apache.org address, so I want to keep the soc prefix. But we use CVS, and I don't think CVS supports directory-specific commit privileges. We'd have to make a branch for them, assuming CVS supports branch-specific commit privileges? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]