Google Summer of Code
Hi all, The Google Summer of Code program is starting up. If you are interested please see http://community.apache.org/gsoc.html for more information on becoming a mentor and/or submitting a project idea. Does anyone have a cool project idea for GSoC? Jarek
Re: Google Summer of Code
Student applications are starting today. We should get projects listed on http://wiki.apache.org/general/SummerOfCode2009 Student applications are starting today. So, if you're able to mentor a project, please got your project description posted. --kevan
Re: Google Summer of Code
I think these would be very good features. david jencks On Mar 19, 2009, at 5:33 AM, Juergen Weber wrote: Jarek Gawor-2 wrote: If we can come up with some interesting project ideas, I would be happy to mentor a student or two. A unique feature for Geronimo would be the ability to override every each single JEE deployment descriptor setting with geronimo- application.xml (same as you can right now do only with geronimo-ra.xml). The JEE idea of a deployer role who changes JEE descriptors and builds applications is not practical. In practice, companies have a process that requires developers to produce ready to run applications, which are then given to IT operations (who usually adapt some property files with server names and port numbers and so on, they never change web.xml). So it would be cool if developers could furnish an application.ear together with a geronimo-application.xml (that IT operations would adapt (with a really nice and shining wysiwyg editor for geronimo-application.xml) Still better, if you could edit geronimo-application.xml via the console. I once opened JIRAs for this: https://issues.apache.org/jira/browse/GERONIMO-3954 https://issues.apache.org/jira/browse/GERONIMO-4376 And, I am sure there are lots of other interesting improvement requests in JIRA ... Thanks, Juergen -- View this message in context: http://www.nabble.com/Google-Summer-of-Code-tp22580117s134p22599207.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: Google Summer of Code
A couple more ideas to me these are research projects in that I don't know how to do them yet (although I have some ideas) 1. Integrate JSecurity (whatever it ends up being called) as a security system choice. I'm not sure how this would relate to jacc and jaspi support. 2. Integrate Jetspeed. I suspect getting jetspeed to run in geronimo would be pretty easy: more interesting would be a deployer that fits into our deployer framework. Some work has been done on this a long time ago but I'm not sure how far it got and jetspeed has moved on also. thanks david jencks On Mar 18, 2009, at 7:12 AM, Kevan Miller wrote: All, the ASF is enrolling as a mentoring organization for the Google Summer of Code. Is there interest in the Geronimo community for mentoring a student(s), this year? This would be a good place to discuss potential project ideas. See http://wiki.apache.org/general/SummerOfCode2009 for details. --kevan
Re: Google Summer of Code
FYI. Let's finalize some ideas and get them recorded on the Project Ideas page.. --kevan On Mar 19, 2009, at 5:52 PM, Luciano Resende wrote: Dear PMC, It's now official, Google has announced that The Apache Software Foundation was selected as one of the participating organization in the GSoC 2009 program. This is an excellent opportunity for Apache, as it allows projects to build/increase its community, it also help students to learn about open source, about Apache Software Foundation and how to do things the Apache Way. Please start advertising the program and discussing project ideas with your project community. Then add your project ideas to the ASF GSoC 2009 Official Project Ideas page [1], as this is going to be the most visible place for students. Per GSoC 2009 timeline, Students should officially start applying for these ideas on March 23. ASF Members and committers can volunteer to be mentors in the GSoC 2009 program (see [2] for more details about being a mentor). We invite all mentors and GSoC interested parties to subscribe to the code-awa...@a.o mailing list [3] to coordinate work between mentors, ask questions and get updates related to GSoC 2009 program. Please, feel free to forward this announce to any appropriate dev@ or users@ lists so your larger community can hear about the GSoC 2009 program. [1] http://wiki.apache.org/general/SummerOfCode2009 [2] http://wiki.apache.org/general/SummerOfCodeMentor [3] mailto:code-awards-subscr...@apache.org
Re: Google Summer of Code
Jarek Gawor-2 wrote: If we can come up with some interesting project ideas, I would be happy to mentor a student or two. A unique feature for Geronimo would be the ability to override every each single JEE deployment descriptor setting with geronimo-application.xml (same as you can right now do only with geronimo-ra.xml). The JEE idea of a deployer role who changes JEE descriptors and builds applications is not practical. In practice, companies have a process that requires developers to produce ready to run applications, which are then given to IT operations (who usually adapt some property files with server names and port numbers and so on, they never change web.xml). So it would be cool if developers could furnish an application.ear together with a geronimo-application.xml (that IT operations would adapt (with a really nice and shining wysiwyg editor for geronimo-application.xml) Still better, if you could edit geronimo-application.xml via the console. I once opened JIRAs for this: https://issues.apache.org/jira/browse/GERONIMO-3954 https://issues.apache.org/jira/browse/GERONIMO-4376 And, I am sure there are lots of other interesting improvement requests in JIRA ... Thanks, Juergen -- View this message in context: http://www.nabble.com/Google-Summer-of-Code-tp22580117s134p22599207.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: Google Summer of Code
Two proposals for this program: 1, To make a glassfish -- geronimo migration tool 2, To test a bunch of most popular JEE apps like nexus, sugarCRM... on Geronimo. a, If there are incompatibility problem in these Apps. Report or contribute the fix back to the App project. b, If being able to install a App with some deployment tuning. To make a deployment guide about how to deploy this App to geronimo. On Thu, Mar 19, 2009 at 8:33 PM, Juergen Weber webe...@gmail.com wrote: Jarek Gawor-2 wrote: If we can come up with some interesting project ideas, I would be happy to mentor a student or two. A unique feature for Geronimo would be the ability to override every each single JEE deployment descriptor setting with geronimo-application.xml (same as you can right now do only with geronimo-ra.xml). The JEE idea of a deployer role who changes JEE descriptors and builds applications is not practical. In practice, companies have a process that requires developers to produce ready to run applications, which are then given to IT operations (who usually adapt some property files with server names and port numbers and so on, they never change web.xml). So it would be cool if developers could furnish an application.ear together with a geronimo-application.xml (that IT operations would adapt (with a really nice and shining wysiwyg editor for geronimo-application.xml) Still better, if you could edit geronimo-application.xml via the console. I once opened JIRAs for this: https://issues.apache.org/jira/browse/GERONIMO-3954 https://issues.apache.org/jira/browse/GERONIMO-4376 And, I am sure there are lots of other interesting improvement requests in JIRA ... Thanks, Juergen -- View this message in context: http://www.nabble.com/Google-Summer-of-Code-tp22580117s134p22599207.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. -- Shawn
Re: Google Summer of Code
One proposal : Update the quartz plugin to the 2.1+ Geronimo https://issues.apache.org/jira/browse/GERONIMO-4140 Ivan 2009/3/20 Shawn Jiang genspr...@gmail.com Two proposals for this program: 1, To make a glassfish -- geronimo migration tool 2, To test a bunch of most popular JEE apps like nexus, sugarCRM... on Geronimo. a, If there are incompatibility problem in these Apps. Report or contribute the fix back to the App project. b, If being able to install a App with some deployment tuning. To make a deployment guide about how to deploy this App to geronimo. On Thu, Mar 19, 2009 at 8:33 PM, Juergen Weber webe...@gmail.com wrote: Jarek Gawor-2 wrote: If we can come up with some interesting project ideas, I would be happy to mentor a student or two. A unique feature for Geronimo would be the ability to override every each single JEE deployment descriptor setting with geronimo-application.xml (same as you can right now do only with geronimo-ra.xml). The JEE idea of a deployer role who changes JEE descriptors and builds applications is not practical. In practice, companies have a process that requires developers to produce ready to run applications, which are then given to IT operations (who usually adapt some property files with server names and port numbers and so on, they never change web.xml). So it would be cool if developers could furnish an application.ear together with a geronimo-application.xml (that IT operations would adapt (with a really nice and shining wysiwyg editor for geronimo-application.xml) Still better, if you could edit geronimo-application.xml via the console. I once opened JIRAs for this: https://issues.apache.org/jira/browse/GERONIMO-3954 https://issues.apache.org/jira/browse/GERONIMO-4376 And, I am sure there are lots of other interesting improvement requests in JIRA ... Thanks, Juergen -- View this message in context: http://www.nabble.com/Google-Summer-of-Code-tp22580117s134p22599207.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. -- Shawn -- Ivan
Google Summer of Code
All, the ASF is enrolling as a mentoring organization for the Google Summer of Code. Is there interest in the Geronimo community for mentoring a student(s), this year? This would be a good place to discuss potential project ideas. See http://wiki.apache.org/general/SummerOfCode2009 for details. --kevan
Re: Google Summer of Code
If we can come up with some interesting project ideas, I would be happy to mentor a student or two. One idea I can think of is adding/enabling WS-Security support in Geronimo for CXF and/or Axis2. Jarek On Wed, Mar 18, 2009 at 10:12 AM, Kevan Miller kevan.mil...@gmail.com wrote: All, the ASF is enrolling as a mentoring organization for the Google Summer of Code. Is there interest in the Geronimo community for mentoring a student(s), this year? This would be a good place to discuss potential project ideas. See http://wiki.apache.org/general/SummerOfCode2009 for details. --kevan
Google Summer of Code Results
All, Adriano's proposal to work on Geronimo was accepted by the Google Summer of Code. So on the one hand, I'd like to welcome him to the list, and please join me in helping him get up to speed for his work in the program. On the other hand, I know there were a number of SoC proposals for Geronimo, and only one was accepted. To everyone else who submitted a proposal: Thanks! I hope you'll get involved in the project even if Google isn't underwriting your efforts. We still have a heap of work to do for v1.0, and the more people get involved, the easier it will be. I'm going to start a new thread to start talking about how to attack the Geronimo DConfigBeans, which is the first item on Adriano's proposal. Thanks, Aaron
Re: Google Summer of Code
On Wed, 22 Jun 2005, Alan D. Cabrera wrote: Could we put him in the sandbox? That seems like a sensible compromise. I assume we'll want to investigate assigning separate commit privs to the sandbox compared to Geronimo proper? I've been assured that we could also do the same for a branch instead of a subdirectory, which I'd be fine with too. Aaron
Re: Google Summer of Code
Aaron Mulder wrote, On 6/23/2005 7:44 PM: On Wed, 22 Jun 2005, Alan D. Cabrera wrote: Could we put him in the sandbox? That seems like a sensible compromise. I assume we'll want to investigate assigning separate commit privs to the sandbox compared to Geronimo proper? I've been assured that we could also do the same for a branch instead of a subdirectory, which I'd be fine with too. It's not really a branch. The sandbox seems more appropriate. Regards, Alan
Google Summer of Code
All, I volunteered to be a mentor for the Google Summer of Code, and there were a number of applications for Geronimo. I'm hopeful that at least one of them will be accepted. If that happens, we need to decide how to treat the student for the duration of the project (in terms of committership). This is kind of a special case in that the program is only a little over 2 months long, which means normally we probably wouldn't have made the person a committer in that time frame. But given that one of the goals is to teach the person how to contribute to open source, it seems to me like we wouldn't be doing them justice if we didn't give them commit for at least part of the project. I'd propose that if this goes through, we put the student on an accelerated plan where we have them contribute their initial work via patches, review and provide feedback, and then if all goes well offer them commit within the first 2-4 weeks. We will then need to evaluate their situation at the end of the program (both their contributions and their availability to work with us in the future) and decide whether to end their commit status or not (without any prejudice if we do decide to end it for whatever reason). So I'd love to get everyone's feedback on whether this seems OK. I specifically want this to be a special case -- I don't want to apply this to anyone else. I understand that there are a lot of people in the community who work hard and contribute and have not been offered commit, and I don't want to offend anyone or make anyone feel underappreciated, but I do personally feel like mentoring a student to be a future open source developer under the terms of this program requires more than simply asking them to submit patches. Let me know! Thanks, Aaron
Re: Google Summer of Code
Aaron, Thanks for stepping up and accepting this. My only .02 on this is you have to be careful about this accellerated role, and here is why... In open source, there is no age limit. In fact I believe one of the main/lead Firefox committers was in his early teens...so committership should not be offered just because someone becomes an intern. Due to the fact we have no barrier to entry, including age, nothing prevents a person from becoming a committer on thier own merits. Anyone can contribute and play in the sandbox. My point really is that we have a community that everyone deserves to enter the geronimo team by hard work, and to accellerate someone due to internship kind of breaks the rules and may cause some alienation in the community...especially those who have spent time helping out and have not been offered committership. I think the point of being a mentor is to help walk a person through the process and how things are done...show the open source way and hopefully have some cool code to show for it at the end of the day. But that should be done without causing community heartburn. Here is an idea... What about an Apache Summer of Code ACL for SVN? This allows the intern to not be an actual committer, but allows them to get the SVN feel on an opensource project. It would offer a good balance for being a mentor without causing bad feelings for those who have contributed and have not been offered committership. What do you think? Jeff Aaron Mulder wrote: All, I volunteered to be a mentor for the Google Summer of Code, and there were a number of applications for Geronimo. I'm hopeful that at least one of them will be accepted. If that happens, we need to decide how to treat the student for the duration of the project (in terms of committership). This is kind of a special case in that the program is only a little over 2 months long, which means normally we probably wouldn't have made the person a committer in that time frame. But given that one of the goals is to teach the person how to contribute to open source, it seems to me like we wouldn't be doing them justice if we didn't give them commit for at least part of the project. I'd propose that if this goes through, we put the student on an accelerated plan where we have them contribute their initial work via patches, review and provide feedback, and then if all goes well offer them commit within the first 2-4 weeks. We will then need to evaluate their situation at the end of the program (both their contributions and their availability to work with us in the future) and decide whether to end their commit status or not (without any prejudice if we do decide to end it for whatever reason). So I'd love to get everyone's feedback on whether this seems OK. I specifically want this to be a special case -- I don't want to apply this to anyone else. I understand that there are a lot of people in the community who work hard and contribute and have not been offered commit, and I don't want to offend anyone or make anyone feel underappreciated, but I do personally feel like mentoring a student to be a future open source developer under the terms of this program requires more than simply asking them to submit patches. Let me know! Thanks, Aaron
Re: Google Summer of Code
Jeff, I'm open to the approach you recommend. But I still believe that to really teach someone about open source, they need to hold commit on something, and be able to break the build and get yelled at, and so on. If we want to make it clear this is a non-traditional path, we could decide to automatically remove commit privileges at the end of the project. I'd prefer that we give them the experience and then take it away, rather than convince them that the sole function of an open source developer is to maintain their own source tree and submit patches. I guess I'm trying to cram a 1-year experience into a 2-month microcosm. But I also agree that we shouldn't frame this as the standard practice for interns. Anyone else out there have an opinion? Thanks, Aaron On Wed, 22 Jun 2005, Jeff Genender wrote: Aaron, Thanks for stepping up and accepting this. My only .02 on this is you have to be careful about this accellerated role, and here is why... In open source, there is no age limit. In fact I believe one of the main/lead Firefox committers was in his early teens...so committership should not be offered just because someone becomes an intern. Due to the fact we have no barrier to entry, including age, nothing prevents a person from becoming a committer on thier own merits. Anyone can contribute and play in the sandbox. My point really is that we have a community that everyone deserves to enter the geronimo team by hard work, and to accellerate someone due to internship kind of breaks the rules and may cause some alienation in the community...especially those who have spent time helping out and have not been offered committership. I think the point of being a mentor is to help walk a person through the process and how things are done...show the open source way and hopefully have some cool code to show for it at the end of the day. But that should be done without causing community heartburn. Here is an idea... What about an Apache Summer of Code ACL for SVN? This allows the intern to not be an actual committer, but allows them to get the SVN feel on an opensource project. It would offer a good balance for being a mentor without causing bad feelings for those who have contributed and have not been offered committership. What do you think? Jeff Aaron Mulder wrote: All, I volunteered to be a mentor for the Google Summer of Code, and there were a number of applications for Geronimo. I'm hopeful that at least one of them will be accepted. If that happens, we need to decide how to treat the student for the duration of the project (in terms of committership). This is kind of a special case in that the program is only a little over 2 months long, which means normally we probably wouldn't have made the person a committer in that time frame. But given that one of the goals is to teach the person how to contribute to open source, it seems to me like we wouldn't be doing them justice if we didn't give them commit for at least part of the project. I'd propose that if this goes through, we put the student on an accelerated plan where we have them contribute their initial work via patches, review and provide feedback, and then if all goes well offer them commit within the first 2-4 weeks. We will then need to evaluate their situation at the end of the program (both their contributions and their availability to work with us in the future) and decide whether to end their commit status or not (without any prejudice if we do decide to end it for whatever reason). So I'd love to get everyone's feedback on whether this seems OK. I specifically want this to be a special case -- I don't want to apply this to anyone else. I understand that there are a lot of people in the community who work hard and contribute and have not been offered commit, and I don't want to offend anyone or make anyone feel underappreciated, but I do personally feel like mentoring a student to be a future open source developer under the terms of this program requires more than simply asking them to submit patches. Let me know! Thanks, Aaron
Re: Google Summer of Code
Could we put him in the sandbox? Regards, Alan Aaron Mulder wrote, On 6/22/2005 1:37 PM: Jeff, I'm open to the approach you recommend. But I still believe that to really teach someone about open source, they need to hold commit on something, and be able to break the build and get yelled at, and so on. If we want to make it clear this is a non-traditional path, we could decide to automatically remove commit privileges at the end of the project. I'd prefer that we give them the experience and then take it away, rather than convince them that the sole function of an open source developer is to maintain their own source tree and submit patches. I guess I'm trying to cram a 1-year experience into a 2-month microcosm. But I also agree that we shouldn't frame this as the standard practice for interns. Anyone else out there have an opinion? Thanks, Aaron On Wed, 22 Jun 2005, Jeff Genender wrote: Aaron, Thanks for stepping up and accepting this. My only .02 on this is you have to be careful about this accellerated role, and here is why... In open source, there is no age limit. In fact I believe one of the main/lead Firefox committers was in his early teens...so committership should not be offered just because someone becomes an intern. Due to the fact we have no barrier to entry, including age, nothing prevents a person from becoming a committer on thier own merits. Anyone can contribute and play in the sandbox. My point really is that we have a community that everyone deserves to enter the geronimo team by hard work, and to accellerate someone due to internship kind of breaks the rules and may cause some alienation in the community...especially those who have spent time helping out and have not been offered committership. I think the point of being a mentor is to help walk a person through the process and how things are done...show the open source way and hopefully have some cool code to show for it at the end of the day. But that should be done without causing community heartburn. Here is an idea... What about an Apache Summer of Code ACL for SVN? This allows the intern to not be an actual committer, but allows them to get the SVN feel on an opensource project. It would offer a good balance for being a mentor without causing bad feelings for those who have contributed and have not been offered committership. What do you think? Jeff Aaron Mulder wrote: All, I volunteered to be a mentor for the Google Summer of Code, and there were a number of applications for Geronimo. I'm hopeful that at least one of them will be accepted. If that happens, we need to decide how to treat the student for the duration of the project (in terms of committership). This is kind of a special case in that the program is only a little over 2 months long, which means normally we probably wouldn't have made the person a committer in that time frame. But given that one of the goals is to teach the person how to contribute to open source, it seems to me like we wouldn't be doing them justice if we didn't give them commit for at least part of the project. I'd propose that if this goes through, we put the student on an accelerated plan where we have them contribute their initial work via patches, review and provide feedback, and then if all goes well offer them commit within the first 2-4 weeks. We will then need to evaluate their situation at the end of the program (both their contributions and their availability to work with us in the future) and decide whether to end their commit status or not (without any prejudice if we do decide to end it for whatever reason). So I'd love to get everyone's feedback on whether this seems OK. I specifically want this to be a special case -- I don't want to apply this to anyone else. I understand that there are a lot of people in the community who work hard and contribute and have not been offered commit, and I don't want to offend anyone or make anyone feel underappreciated, but I do personally feel like mentoring a student to be a future open source developer under the terms of this program requires more than simply asking them to submit patches. Let me know! Thanks, Aaron
Re: Google Summer of Code
On Jun 22, 2005, at 4:37 PM, Aaron Mulder wrote: Jeff, I'm open to the approach you recommend. But I still believe that to really teach someone about open source, they need to hold commit on something, and be able to break the build and get yelled at, and so on. If we want to make it clear this is a non-traditional path, we could decide to automatically remove commit privileges at the end of the project. I'd prefer that we give them the experience and then take it away, rather than convince them that the sole function of an open source developer is to maintain their own source tree and submit patches. I guess I'm trying to cram a 1-year experience into a 2-month microcosm. But I also agree that we shouldn't frame this as the standard practice for interns. Anyone else out there have an opinion? Isn't the entire process you are describing what we'd want to do with any new community member who wishes to contribute via committing code? I'm all for the idea of mentoring, and like the Summer of Code idea if it helps students to engage with us. I also like the idea of getting willing contributors going in this way, no matter who they are, as long as the dedication and alignment is there - maybe that's what you are identifying with a student signing up for this, that they are accelerating their demonstration of commitment to working with the project and community. How can we quantify and recognize that commitment more generally? geir Thanks, Aaron On Wed, 22 Jun 2005, Jeff Genender wrote: Aaron, Thanks for stepping up and accepting this. My only .02 on this is you have to be careful about this accellerated role, and here is why... In open source, there is no age limit. In fact I believe one of the main/lead Firefox committers was in his early teens...so committership should not be offered just because someone becomes an intern. Due to the fact we have no barrier to entry, including age, nothing prevents a person from becoming a committer on thier own merits. Anyone can contribute and play in the sandbox. My point really is that we have a community that everyone deserves to enter the geronimo team by hard work, and to accellerate someone due to internship kind of breaks the rules and may cause some alienation in the community...especially those who have spent time helping out and have not been offered committership. I think the point of being a mentor is to help walk a person through the process and how things are done...show the open source way and hopefully have some cool code to show for it at the end of the day. But that should be done without causing community heartburn. Here is an idea... What about an Apache Summer of Code ACL for SVN? This allows the intern to not be an actual committer, but allows them to get the SVN feel on an opensource project. It would offer a good balance for being a mentor without causing bad feelings for those who have contributed and have not been offered committership. What do you think? Jeff Aaron Mulder wrote: All, I volunteered to be a mentor for the Google Summer of Code, and there were a number of applications for Geronimo. I'm hopeful that at least one of them will be accepted. If that happens, we need to decide how to treat the student for the duration of the project (in terms of committership). This is kind of a special case in that the program is only a little over 2 months long, which means normally we probably wouldn't have made the person a committer in that time frame. But given that one of the goals is to teach the person how to contribute to open source, it seems to me like we wouldn't be doing them justice if we didn't give them commit for at least part of the project. I'd propose that if this goes through, we put the student on an accelerated plan where we have them contribute their initial work via patches, review and provide feedback, and then if all goes well offer them commit within the first 2-4 weeks. We will then need to evaluate their situation at the end of the program (both their contributions and their availability to work with us in the future) and decide whether to end their commit status or not (without any prejudice if we do decide to end it for whatever reason). So I'd love to get everyone's feedback on whether this seems OK. I specifically want this to be a special case -- I don't want to apply this to anyone else. I understand that there are a lot of people in the community who work hard and contribute and have not been offered commit, and I don't want to offend anyone or make anyone feel underappreciated, but I do personally feel like mentoring a student to be a future open source developer under the terms of this program requires more than simply asking them to submit patches. Let me know! Thanks, Aaron -- Geir Magnusson Jr +1-203
