Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Auto-conf meeting logs"
(New page: <pre> *** onnadi3 [i=82cf935f@gateway/web/cgi-irc/ircatwork.com/x-6b272e4f5f832da1] has joined #eclipse-soc *** Topic is: SOC 2007 @ Eclipse is on! http://code.google.com/soc - Get help wi...) |
|||
Line 1: | Line 1: | ||
+ | ===26 May 2007=== | ||
+ | <pre> | ||
+ | <onnadi3> Two things: | ||
+ | <lemmy> unfortunately I had no time to send out an agenda. | ||
+ | <onnadi3> 1. Weekly meeting times | ||
+ | <onnadi3> 2. Agenda for this coming month, or at least the next few weeks | ||
+ | <onnadi3> 3. Perhaps all get on the same page about hte project's objective | ||
+ | <onnadi3> (that's not 3, I know :-) ) | ||
+ | <rcjsuen> I'm not sure when Philippe will send out an email for weekly meetings. | ||
+ | <rcjsuen> Since the program starts on Monday is it? | ||
+ | <onnadi3> yup | ||
+ | <lemmy> About 1. I'll be back in Germany 11th of June which should | ||
+ | allow us for more flexible meeting times. | ||
+ | <rcjsuen> I can't do weekday meetings since I have a full-time (internship) job. | ||
+ | <lemmy> I'm rather busy through the week myself and would prefer | ||
+ | meetings on the weekend too. | ||
+ | <onnadi3> Alright. Should we perhaps stick with this time until we | ||
+ | find a better time? | ||
+ | <rcjsuen> Saturday mornings are no problem with me. | ||
+ | <lemmy> Sounds like a plan to me. | ||
+ | <onnadi3> Alrighty! Next up, 2. Agenda for this coming month, | ||
+ | <lemmy> We definitely need to setup SCM. | ||
+ | <lemmy> onnadi3: Have you started the Eclipse IP process already? | ||
+ | <onnadi3> I thought, the eclipse-dev folks were going to send out an | ||
+ | e-mail to all of us en masse | ||
+ | <lemmy> Lets check the soc bug again... | ||
+ | <rcjsuen> wizEpit: Hi wizEpit, don't think I've seen you around, are | ||
+ | you a student? | ||
+ | <rcjsuen> yeah, It's been a while, I don't really remember the details | ||
+ | <rcjsuen> Can always just use SF for now. | ||
+ | <rcjsuen> we all did so last yr anyway ;p | ||
+ | <lemmy> We should get the process started anyway. Don't you agree that | ||
+ | the code might end up in Eclipse? | ||
+ | <onnadi3> Yes yes yes | ||
+ | <rcjsuen> I'm not sure which project would consume it though. | ||
+ | <lemmy> It will be easier if the code is already at eclipse.org i guess. | ||
+ | <lemmy> Do you have a SF id ogechi? | ||
+ | <rcjsuen> lemmy: Right | ||
+ | <rcjsuen> I think I added him already | ||
+ | <onnadi3> No. But I have a google id and I have used Google's project | ||
+ | hosting before | ||
+ | <onnadi3> Its really easy | ||
+ | <rcjsuen> okay i guess not the n;p | ||
+ | <lemmy> I would prefer to use SF. Eclipse GSoC has a project set up already. | ||
+ | <lemmy> And GSoC doesn't require us to use their facilities. | ||
+ | <lemmy> http://sourceforge.net/projects/eclipse-incub | ||
+ | <onnadi3> lemmy: so all the past GSoC projects are held in SF under | ||
+ | one source tree? | ||
+ | <rcjsuen> not "all" | ||
+ | <rcjsuen> some...didn't ;p | ||
+ | <rcjsuen> http://eclipse-incub.cvs.sourceforge.net/eclipse-incub/ | ||
+ | <rcjsuen> by some i mean lots | ||
+ | <onnadi3> :-) | ||
+ | <rcjsuen> I don't know how strict pombreda is going to be this year though ;) | ||
+ | <rcjsuen> It's just easier for the populace to find GSOC code. | ||
+ | <rcjsuen> If they're all in one place, naturally. | ||
+ | <onnadi3> OK. THat makes sense. | ||
+ | <onnadi3> So once I get an SF id, I can e-mail rcjsuen to get added to | ||
+ | the incub project? | ||
+ | <lemmy> you can email either remy or me. | ||
+ | <lemmy> or both of us and see who acts fiirst. ;) | ||
+ | <rcjsuen> We all have admin rights actually. | ||
+ | <rcjsuen> You can just speak up here. | ||
+ | <rcjsuen> Someone with free time will do it. | ||
+ | <lemmy> What about CVS vs SVN? | ||
+ | <onnadi3> SVN, unless someones has a strong opposition to it... | ||
+ | <rcjsuen> You're supposed to use CVS. | ||
+ | <rcjsuen> lol | ||
+ | <onnadi3> oops | ||
+ | <lemmy> Says pombreda ? | ||
+ | <rcjsuen> Says pombreda alright. | ||
+ | <lemmy> Eclipse.org offers SVN, so does SF. | ||
+ | <onnadi3> I thought so , too | ||
+ | <rcjsuen> We picked CVS because of the lower barrier of entry. | ||
+ | <rcjsuen> That was my vote +1 for CVS. | ||
+ | <rcjsuen> Even though I would gladly -infinity to CVS. | ||
+ | <lemmy> Barrier for who? | ||
+ | <rcjsuen> Since I can't stand 1.x version numbers. | ||
+ | <rcjsuen> lemmy: Fora nyone | ||
+ | <lemmy> I'm fine with both and with pombreda opting for CVS lets use CVS then. | ||
+ | <onnadi3> <sigh> CVS it is, I guess :-) | ||
+ | <rcjsuen> Sorry | ||
+ | <lemmy> rcjsuen: No need to be sorry. CVS is fine for us. | ||
+ | <onnadi3> Except for creating directories *ahem* | ||
+ | <onnadi3> :-) | ||
+ | <lemmy> Who cares if a file history is broken. ;) | ||
+ | <onnadi3> :-) | ||
+ | <onnadi3> Well, now that that is settled, should we move into my goals | ||
+ | for the next meeting? | ||
+ | <lemmy> sure | ||
+ | <rcjsuen> sounds good | ||
+ | <onnadi3> I was thinking I'd draw out different scenarios in which the | ||
+ | plugin would be used | ||
+ | <onnadi3> e.g. | ||
+ | <onnadi3> 1. Let's say you dl the autoconf plugin then download the | ||
+ | C++ plugin, the autoconf plugin will automatically determine what the | ||
+ | C++ plugin needs and try to find them | ||
+ | <lemmy> onnadi3: the autoconf plugin refers to your plugin? | ||
+ | <onnadi3> Yeah | ||
+ | <lemmy> do you want the autoconf plugin to know about cdt? | ||
+ | <rcjsuen> That'd require some identical plug-in ID + version magic | ||
+ | <onnadi3> Well, I think it would be beneficial, from the user | ||
+ | standpoint, to have the autoconf plugin keep as large a db as feasible | ||
+ | of plugins and their requirements | ||
+ | <lemmy> actually I don't think autoconf should know about it consumers. | ||
+ | <onnadi3> that way, it looks like magic to the user | ||
+ | <onnadi3> Of course, we would also want to provide an API for the | ||
+ | autconf plugin so that newer plugins can make their requirements | ||
+ | autconfable | ||
+ | <lemmy> IMO autoconf should only provide the framework to discover | ||
+ | "services". consumers then provide autoconf with rules to discover | ||
+ | actual servies. | ||
+ | <rcjsuen> It'd be tough to maintain since I'm assuming those plug-ins | ||
+ | mark a lot of preferences stuff as internal. | ||
+ | <lemmy> remy: that's why i don't like the idea of shipping discovery | ||
+ | rules with autoconf | ||
+ | <lemmy> btw. autoconf is a working title? ;) | ||
+ | <rcjsuen> I guess | ||
+ | <onnadi3> Sounds fine to me :) | ||
+ | <onnadi3> Hmm, of course our main aim won't be collating all the | ||
+ | requirements for every single plugin, but I think it would be useful | ||
+ | to allow the capability so that the more common older plugins are | ||
+ | autoconfable | ||
+ | <lemmy> sure, provide a few exemplary rules like jdk, gcc, ... but | ||
+ | nothing specific. | ||
+ | <lemmy> It's a nice vision to allow for older plug-ins to benefit from | ||
+ | autoconf though. | ||
+ | <onnadi3> So, should we go through the other scenarios now or is that | ||
+ | something I should flesh out more during the week? | ||
+ | <lemmy> tbh lets try to get a strong and fairly generic framework | ||
+ | running before we concentrate on creating a big database. | ||
+ | <rcjsuen> Agreed. | ||
+ | <onnadi3> Agreed | ||
+ | <lemmy> A database is something that could live from contributions. | ||
+ | <rcjsuen> Very true, services / extensions. | ||
+ | <onnadi3> So another scenario would be when the C++ plugin has already | ||
+ | been installed and then the autoconf plugin is installed afterwards | ||
+ | <onnadi3> In that case, the user would have to click a button or | ||
+ | something to request that the C++ requirements be found | ||
+ | <onnadi3> I could do sketches of what this would look like during the week | ||
+ | <rcjsuen> yes, that seems reasonable | ||
+ | <rcjsuen> like if they installed a new JRE and it's the new JAVA_HOME | ||
+ | <rcjsuen> could possibly update that or whatever | ||
+ | <lemmy> It seems if I have a slightly different vision for autoconf. I | ||
+ | see it more like a fundamental service without a real UI. | ||
+ | <onnadi3> ah | ||
+ | <onnadi3> So perhaps we should focus on the service first, and then if | ||
+ | there's any time left, work on prettifying? | ||
+ | <rcjsuen> lemmy: You mean someone else will code the UI? | ||
+ | <lemmy> rcjsuen: I don't see the need for a UI. | ||
+ | <lemmy> CDT and JDT will use the autoconf facilities to discover their | ||
+ | dependencies. | ||
+ | <lemmy> We could provide patches for CDT and JDT. | ||
+ | <rcjsuen> If there's no UI then the user cannot intervene with the | ||
+ | autodetection. | ||
+ | <lemmy> Basically CDT and JDT use OSGi preference service to obtain a | ||
+ | service by some identifier. autoconf takes care of filling up the | ||
+ | preference. either at startup or on demand. | ||
+ | <lemmy> rcjsuen: since we can't be sure of the result of autoconf | ||
+ | anyway, a user will always have to verify the results. | ||
+ | <rcjsuen> That's true. | ||
+ | <lemmy> Something like: A new JAVA project gets created. JDT asks | ||
+ | preference for JDK, autoconf tries to discover JDK. JDT shows the | ||
+ | rules to the user in the project creation wizard. | ||
+ | <rcjsuen> Sounds reasonable. | ||
+ | <lemmy> One thing is missing in this however. | ||
+ | <onnadi3> Shouldn't it be: JDT is installed. autoconf discovers JDK. | ||
+ | JDT then shows the rules to the user during the installation process | ||
+ | <lemmy> Who provides the discovery rule. I think those should also | ||
+ | come from JDT. | ||
+ | <onnadi3> I'd originally thought this could be done by the community | ||
+ | as well, but I think that raises security concenrs | ||
+ | <lemmy> Generally speaking a consumer configures autoconf to discover | ||
+ | a given service id by a given rule. | ||
+ | <lemmy> onnadi3: About which installation process are you talking? | ||
+ | <onnadi3> the plugin "installation" process | ||
+ | <lemmy> onnadi3: I wouldn't care so much for the installation of JDT | ||
+ | or CDT. Discovering a certain service is something which is needed | ||
+ | when a new project gets created... | ||
+ | <onnadi3> lemmy: But won't the same rule suffice for any other Java | ||
+ | project (in the case of JDT)? | ||
+ | <lemmy> I don't get the question, sorry. | ||
+ | <onnadi3> So if you discovered, say, the JDK while starting one Java | ||
+ | project. Won't that same JDK suffice for any other Java project that | ||
+ | you start? | ||
+ | <lemmy> each project can depend on a different jdk. | ||
+ | <onnadi3> I see | ||
+ | <rcjsuen> yeah, there's a workspace setting, but projects can also | ||
+ | pick their own | ||
+ | <onnadi3> It just seems to me like it would be annoying to have to | ||
+ | have to select a JDK for every project since (I'm guessing) most | ||
+ | times, you'd want to use the same JDK | ||
+ | <onnadi3> However, you have an excellent point that people mihgt need | ||
+ | per project settings and so we need to provide that functionality | ||
+ | <lemmy> onnadi3: normally you manually add several jdks to your | ||
+ | workspace. each time you create a new project in that workspace, you | ||
+ | get to choose from that list. | ||
+ | <rcjsuen> Depends on the projects, PDEs have the Execution Environment concept. | ||
+ | <lemmy> true | ||
+ | <lemmy> but it's just another layer on top of jdks. | ||
+ | * lemmy feels the need for a whiteboard | ||
+ | <onnadi3> Ah. I think lemmy is right in that the autoconfplugin finds | ||
+ | all JDKs every time a new project is started (in case a new one was | ||
+ | installed since the last autodetect) and then the user has the choice | ||
+ | of picking a JDK from a list or using the default | ||
+ | <lemmy> onnadi3: Discovery could either be triggered from the new | ||
+ | project wizard or in the workspace wide "installed jdks" preference | ||
+ | page. | ||
+ | <rcjsuen> yeah | ||
+ | <rcjsuen> I guess wherever it has some kinda Viewer that calls like | ||
+ | getInstalledJREs() | ||
+ | <lemmy> This pretty much applies to CDT, PDT,... | ||
+ | <rcjsuen> it should do a rediscover | ||
+ | <lemmy> getInstalledJREs(boolean rediscover) ;) | ||
+ | <lemmy> discovery might be expensive | ||
+ | <onnadi3> yup | ||
+ | <lemmy> Unfortunately I don't see a way around touching JDT/CDT/... code. | ||
+ | <lemmy> Except maybe with some AOP magic. | ||
+ | <onnadi3> And, for instance, in the Ruby plugin, you don't have the | ||
+ | option of choosing runtimes. So if autodiscovery takes even a few | ||
+ | extra seconds, folk might get pissed off that this autocofn plugin is | ||
+ | slowin g their Eclipse | ||
+ | <lemmy> But I don't think we should go that road. It would rely on | ||
+ | internal stuff. | ||
+ | <lemmy> +down | ||
+ | <rcjsuen> yeah | ||
+ | <lemmy> Thinking about it... I guess its more like | ||
+ | getService(DiscoveryRule rule, ServiceID id) | ||
+ | <lemmy> and getService(ServiceID id) | ||
+ | <onnadi3> So for now, we stick with the original plan of filling a | ||
+ | table of services and then slowly converting other plugins to use the | ||
+ | autoconf API | ||
+ | <onnadi3> ? | ||
+ | <lemmy> onnadi3: I guess for the moment converting means providing patches. | ||
+ | <rcjsuen> heheh | ||
+ | <lemmy> But why not, that's the usual way anyway. | ||
+ | <onnadi3> yup. Unless the plugins allow their prefs to be publicly written | ||
+ | <onnadi3> But I don't know if lossa plugins do that | ||
+ | <lemmy> We would provide patches for the big players like JDT and CDT. | ||
+ | Others will write their own patches later. | ||
+ | <onnadi3> or if its good form anyway | ||
+ | <onnadi3> okay | ||
+ | <lemmy> onnadi3: you can't even be sure that plug-ins store their | ||
+ | prefs with the normal preference API. | ||
+ | <onnadi3> true that | ||
+ | <lemmy> Overwriting those "tables" would definitely mean accessing internal API. | ||
+ | <onnadi3> So it will have to be by patching the plugins themselves | ||
+ | <onnadi3> Which, hopefully, won't be immensely difficult :-) | ||
+ | <lemmy> onnadi3: Its tedious work anyway. Just adding a couple of | ||
+ | buttons and some calls to the autoconf api. | ||
+ | <onnadi3> Hmm, so maybe for our next meeting, I should make a skeleton | ||
+ | plugin and define the API? | ||
+ | <lemmy> I find it far more interesting designing the a generic discovery engine. | ||
+ | <onnadi3> Or I coul dinstead work on defining rules in DRools to see | ||
+ | how it works... | ||
+ | <lemmy> It would start with drools to get a feeling how the external | ||
+ | API needs to look like. | ||
+ | <onnadi3> lemmy: do you mean, designing the heuristics that will find | ||
+ | any binary given an ID or name? (per your previous comment) | ||
+ | <lemmy> Start with something simple. A list of possible locations for a JDK. | ||
+ | <onnadi3> Ah OK. So it comes down to: | ||
+ | <onnadi3> 1. Play with Drools and see how it works | ||
+ | <zx> the EE concept was moved to JDT remmy, no longer in PDE | ||
+ | <onnadi3> 2. Write heuristics for finding where the JDK lives ina system | ||
+ | <rcjsuen> zx: one less thing for you to worry about? | ||
+ | <lemmy> Familiarize yourself with PDE. Create the initial plug-in. Get | ||
+ | a working environment. :) | ||
+ | <rcjsuen> zx: you need to use like 'update classpath' to stop those | ||
+ | annoying warnings though | ||
+ | <onnadi3> lemmy: what do you mean by working environment? | ||
+ | <rcjsuen> get Eclipse setup and all that good stuff | ||
+ | <lemmy> zx: why not downwards in the direction of OSGi? | ||
+ | <zx> lemmy, well, EE is in the spec | ||
+ | <rcjsuen> lemmy: an interesting proposition | ||
+ | <zx> JDT provides the tooling around EE | ||
+ | <lemmy> onnadi3: configure your Eclipse for plug-in development... | ||
+ | <onnadi3> okey-dokey | ||
+ | <zx> need to start packing for my flight that leaves in 6 hours | ||
+ | <onnadi3> lemmy, rcjsuen: Whew! I think we got quite a bit hashed out | ||
+ | today. Thanks for your great ideas | ||
+ | <lemmy> If there is a compilable plug-in in the cvs repository next | ||
+ | Saturday that takes a collection of possible fs locations and returns | ||
+ | a collection of jdks... | ||
+ | <onnadi3> lemmy: gotcha :-) | ||
+ | <lemmy> No need for fancy API or UI yet. JUnit tests do great. | ||
+ | <rcjsuen> yay unit tests :) | ||
+ | <lemmy> And it's ok if they fail :) | ||
+ | <rcjsuen> So true. | ||
+ | <onnadi3> hahaha I'll make a few fail just for you :-) | ||
+ | <lemmy> which reminds me. I missed Wayne's test driven webcast. | ||
+ | <lemmy> Fortunately it's recorded somewhere. :) | ||
+ | <lemmy> onnadi3: are you fine with it if i send this chat log to the | ||
+ | soc-dev mailing list, so others get to know what we're up to? | ||
+ | <onnadi3> I'm all for it. Let 'em know we been working hard ;-) | ||
+ | </pre> | ||
+ | |||
+ | ===21 April 2007=== | ||
+ | |||
<pre> | <pre> | ||
*** onnadi3 [i=82cf935f@gateway/web/cgi-irc/ircatwork.com/x-6b272e4f5f832da1] has joined #eclipse-soc | *** onnadi3 [i=82cf935f@gateway/web/cgi-irc/ircatwork.com/x-6b272e4f5f832da1] has joined #eclipse-soc | ||
Line 403: | Line 701: | ||
<lemmy> have a nice day/weekend | <lemmy> have a nice day/weekend | ||
<onnadi3> bye bye | <onnadi3> bye bye | ||
− | |||
− | |||
</pre> | </pre> |
Revision as of 12:31, 27 May 2007
26 May 2007
<onnadi3> Two things: <lemmy> unfortunately I had no time to send out an agenda. <onnadi3> 1. Weekly meeting times <onnadi3> 2. Agenda for this coming month, or at least the next few weeks <onnadi3> 3. Perhaps all get on the same page about hte project's objective <onnadi3> (that's not 3, I know :-) ) <rcjsuen> I'm not sure when Philippe will send out an email for weekly meetings. <rcjsuen> Since the program starts on Monday is it? <onnadi3> yup <lemmy> About 1. I'll be back in Germany 11th of June which should allow us for more flexible meeting times. <rcjsuen> I can't do weekday meetings since I have a full-time (internship) job. <lemmy> I'm rather busy through the week myself and would prefer meetings on the weekend too. <onnadi3> Alright. Should we perhaps stick with this time until we find a better time? <rcjsuen> Saturday mornings are no problem with me. <lemmy> Sounds like a plan to me. <onnadi3> Alrighty! Next up, 2. Agenda for this coming month, <lemmy> We definitely need to setup SCM. <lemmy> onnadi3: Have you started the Eclipse IP process already? <onnadi3> I thought, the eclipse-dev folks were going to send out an e-mail to all of us en masse <lemmy> Lets check the soc bug again... <rcjsuen> wizEpit: Hi wizEpit, don't think I've seen you around, are you a student? <rcjsuen> yeah, It's been a while, I don't really remember the details <rcjsuen> Can always just use SF for now. <rcjsuen> we all did so last yr anyway ;p <lemmy> We should get the process started anyway. Don't you agree that the code might end up in Eclipse? <onnadi3> Yes yes yes <rcjsuen> I'm not sure which project would consume it though. <lemmy> It will be easier if the code is already at eclipse.org i guess. <lemmy> Do you have a SF id ogechi? <rcjsuen> lemmy: Right <rcjsuen> I think I added him already <onnadi3> No. But I have a google id and I have used Google's project hosting before <onnadi3> Its really easy <rcjsuen> okay i guess not the n;p <lemmy> I would prefer to use SF. Eclipse GSoC has a project set up already. <lemmy> And GSoC doesn't require us to use their facilities. <lemmy> http://sourceforge.net/projects/eclipse-incub <onnadi3> lemmy: so all the past GSoC projects are held in SF under one source tree? <rcjsuen> not "all" <rcjsuen> some...didn't ;p <rcjsuen> http://eclipse-incub.cvs.sourceforge.net/eclipse-incub/ <rcjsuen> by some i mean lots <onnadi3> :-) <rcjsuen> I don't know how strict pombreda is going to be this year though ;) <rcjsuen> It's just easier for the populace to find GSOC code. <rcjsuen> If they're all in one place, naturally. <onnadi3> OK. THat makes sense. <onnadi3> So once I get an SF id, I can e-mail rcjsuen to get added to the incub project? <lemmy> you can email either remy or me. <lemmy> or both of us and see who acts fiirst. ;) <rcjsuen> We all have admin rights actually. <rcjsuen> You can just speak up here. <rcjsuen> Someone with free time will do it. <lemmy> What about CVS vs SVN? <onnadi3> SVN, unless someones has a strong opposition to it... <rcjsuen> You're supposed to use CVS. <rcjsuen> lol <onnadi3> oops <lemmy> Says pombreda ? <rcjsuen> Says pombreda alright. <lemmy> Eclipse.org offers SVN, so does SF. <onnadi3> I thought so , too <rcjsuen> We picked CVS because of the lower barrier of entry. <rcjsuen> That was my vote +1 for CVS. <rcjsuen> Even though I would gladly -infinity to CVS. <lemmy> Barrier for who? <rcjsuen> Since I can't stand 1.x version numbers. <rcjsuen> lemmy: Fora nyone <lemmy> I'm fine with both and with pombreda opting for CVS lets use CVS then. <onnadi3> <sigh> CVS it is, I guess :-) <rcjsuen> Sorry <lemmy> rcjsuen: No need to be sorry. CVS is fine for us. <onnadi3> Except for creating directories *ahem* <onnadi3> :-) <lemmy> Who cares if a file history is broken. ;) <onnadi3> :-) <onnadi3> Well, now that that is settled, should we move into my goals for the next meeting? <lemmy> sure <rcjsuen> sounds good <onnadi3> I was thinking I'd draw out different scenarios in which the plugin would be used <onnadi3> e.g. <onnadi3> 1. Let's say you dl the autoconf plugin then download the C++ plugin, the autoconf plugin will automatically determine what the C++ plugin needs and try to find them <lemmy> onnadi3: the autoconf plugin refers to your plugin? <onnadi3> Yeah <lemmy> do you want the autoconf plugin to know about cdt? <rcjsuen> That'd require some identical plug-in ID + version magic <onnadi3> Well, I think it would be beneficial, from the user standpoint, to have the autoconf plugin keep as large a db as feasible of plugins and their requirements <lemmy> actually I don't think autoconf should know about it consumers. <onnadi3> that way, it looks like magic to the user <onnadi3> Of course, we would also want to provide an API for the autconf plugin so that newer plugins can make their requirements autconfable <lemmy> IMO autoconf should only provide the framework to discover "services". consumers then provide autoconf with rules to discover actual servies. <rcjsuen> It'd be tough to maintain since I'm assuming those plug-ins mark a lot of preferences stuff as internal. <lemmy> remy: that's why i don't like the idea of shipping discovery rules with autoconf <lemmy> btw. autoconf is a working title? ;) <rcjsuen> I guess <onnadi3> Sounds fine to me :) <onnadi3> Hmm, of course our main aim won't be collating all the requirements for every single plugin, but I think it would be useful to allow the capability so that the more common older plugins are autoconfable <lemmy> sure, provide a few exemplary rules like jdk, gcc, ... but nothing specific. <lemmy> It's a nice vision to allow for older plug-ins to benefit from autoconf though. <onnadi3> So, should we go through the other scenarios now or is that something I should flesh out more during the week? <lemmy> tbh lets try to get a strong and fairly generic framework running before we concentrate on creating a big database. <rcjsuen> Agreed. <onnadi3> Agreed <lemmy> A database is something that could live from contributions. <rcjsuen> Very true, services / extensions. <onnadi3> So another scenario would be when the C++ plugin has already been installed and then the autoconf plugin is installed afterwards <onnadi3> In that case, the user would have to click a button or something to request that the C++ requirements be found <onnadi3> I could do sketches of what this would look like during the week <rcjsuen> yes, that seems reasonable <rcjsuen> like if they installed a new JRE and it's the new JAVA_HOME <rcjsuen> could possibly update that or whatever <lemmy> It seems if I have a slightly different vision for autoconf. I see it more like a fundamental service without a real UI. <onnadi3> ah <onnadi3> So perhaps we should focus on the service first, and then if there's any time left, work on prettifying? <rcjsuen> lemmy: You mean someone else will code the UI? <lemmy> rcjsuen: I don't see the need for a UI. <lemmy> CDT and JDT will use the autoconf facilities to discover their dependencies. <lemmy> We could provide patches for CDT and JDT. <rcjsuen> If there's no UI then the user cannot intervene with the autodetection. <lemmy> Basically CDT and JDT use OSGi preference service to obtain a service by some identifier. autoconf takes care of filling up the preference. either at startup or on demand. <lemmy> rcjsuen: since we can't be sure of the result of autoconf anyway, a user will always have to verify the results. <rcjsuen> That's true. <lemmy> Something like: A new JAVA project gets created. JDT asks preference for JDK, autoconf tries to discover JDK. JDT shows the rules to the user in the project creation wizard. <rcjsuen> Sounds reasonable. <lemmy> One thing is missing in this however. <onnadi3> Shouldn't it be: JDT is installed. autoconf discovers JDK. JDT then shows the rules to the user during the installation process <lemmy> Who provides the discovery rule. I think those should also come from JDT. <onnadi3> I'd originally thought this could be done by the community as well, but I think that raises security concenrs <lemmy> Generally speaking a consumer configures autoconf to discover a given service id by a given rule. <lemmy> onnadi3: About which installation process are you talking? <onnadi3> the plugin "installation" process <lemmy> onnadi3: I wouldn't care so much for the installation of JDT or CDT. Discovering a certain service is something which is needed when a new project gets created... <onnadi3> lemmy: But won't the same rule suffice for any other Java project (in the case of JDT)? <lemmy> I don't get the question, sorry. <onnadi3> So if you discovered, say, the JDK while starting one Java project. Won't that same JDK suffice for any other Java project that you start? <lemmy> each project can depend on a different jdk. <onnadi3> I see <rcjsuen> yeah, there's a workspace setting, but projects can also pick their own <onnadi3> It just seems to me like it would be annoying to have to have to select a JDK for every project since (I'm guessing) most times, you'd want to use the same JDK <onnadi3> However, you have an excellent point that people mihgt need per project settings and so we need to provide that functionality <lemmy> onnadi3: normally you manually add several jdks to your workspace. each time you create a new project in that workspace, you get to choose from that list. <rcjsuen> Depends on the projects, PDEs have the Execution Environment concept. <lemmy> true <lemmy> but it's just another layer on top of jdks. * lemmy feels the need for a whiteboard <onnadi3> Ah. I think lemmy is right in that the autoconfplugin finds all JDKs every time a new project is started (in case a new one was installed since the last autodetect) and then the user has the choice of picking a JDK from a list or using the default <lemmy> onnadi3: Discovery could either be triggered from the new project wizard or in the workspace wide "installed jdks" preference page. <rcjsuen> yeah <rcjsuen> I guess wherever it has some kinda Viewer that calls like getInstalledJREs() <lemmy> This pretty much applies to CDT, PDT,... <rcjsuen> it should do a rediscover <lemmy> getInstalledJREs(boolean rediscover) ;) <lemmy> discovery might be expensive <onnadi3> yup <lemmy> Unfortunately I don't see a way around touching JDT/CDT/... code. <lemmy> Except maybe with some AOP magic. <onnadi3> And, for instance, in the Ruby plugin, you don't have the option of choosing runtimes. So if autodiscovery takes even a few extra seconds, folk might get pissed off that this autocofn plugin is slowin g their Eclipse <lemmy> But I don't think we should go that road. It would rely on internal stuff. <lemmy> +down <rcjsuen> yeah <lemmy> Thinking about it... I guess its more like getService(DiscoveryRule rule, ServiceID id) <lemmy> and getService(ServiceID id) <onnadi3> So for now, we stick with the original plan of filling a table of services and then slowly converting other plugins to use the autoconf API <onnadi3> ? <lemmy> onnadi3: I guess for the moment converting means providing patches. <rcjsuen> heheh <lemmy> But why not, that's the usual way anyway. <onnadi3> yup. Unless the plugins allow their prefs to be publicly written <onnadi3> But I don't know if lossa plugins do that <lemmy> We would provide patches for the big players like JDT and CDT. Others will write their own patches later. <onnadi3> or if its good form anyway <onnadi3> okay <lemmy> onnadi3: you can't even be sure that plug-ins store their prefs with the normal preference API. <onnadi3> true that <lemmy> Overwriting those "tables" would definitely mean accessing internal API. <onnadi3> So it will have to be by patching the plugins themselves <onnadi3> Which, hopefully, won't be immensely difficult :-) <lemmy> onnadi3: Its tedious work anyway. Just adding a couple of buttons and some calls to the autoconf api. <onnadi3> Hmm, so maybe for our next meeting, I should make a skeleton plugin and define the API? <lemmy> I find it far more interesting designing the a generic discovery engine. <onnadi3> Or I coul dinstead work on defining rules in DRools to see how it works... <lemmy> It would start with drools to get a feeling how the external API needs to look like. <onnadi3> lemmy: do you mean, designing the heuristics that will find any binary given an ID or name? (per your previous comment) <lemmy> Start with something simple. A list of possible locations for a JDK. <onnadi3> Ah OK. So it comes down to: <onnadi3> 1. Play with Drools and see how it works <zx> the EE concept was moved to JDT remmy, no longer in PDE <onnadi3> 2. Write heuristics for finding where the JDK lives ina system <rcjsuen> zx: one less thing for you to worry about? <lemmy> Familiarize yourself with PDE. Create the initial plug-in. Get a working environment. :) <rcjsuen> zx: you need to use like 'update classpath' to stop those annoying warnings though <onnadi3> lemmy: what do you mean by working environment? <rcjsuen> get Eclipse setup and all that good stuff <lemmy> zx: why not downwards in the direction of OSGi? <zx> lemmy, well, EE is in the spec <rcjsuen> lemmy: an interesting proposition <zx> JDT provides the tooling around EE <lemmy> onnadi3: configure your Eclipse for plug-in development... <onnadi3> okey-dokey <zx> need to start packing for my flight that leaves in 6 hours <onnadi3> lemmy, rcjsuen: Whew! I think we got quite a bit hashed out today. Thanks for your great ideas <lemmy> If there is a compilable plug-in in the cvs repository next Saturday that takes a collection of possible fs locations and returns a collection of jdks... <onnadi3> lemmy: gotcha :-) <lemmy> No need for fancy API or UI yet. JUnit tests do great. <rcjsuen> yay unit tests :) <lemmy> And it's ok if they fail :) <rcjsuen> So true. <onnadi3> hahaha I'll make a few fail just for you :-) <lemmy> which reminds me. I missed Wayne's test driven webcast. <lemmy> Fortunately it's recorded somewhere. :) <lemmy> onnadi3: are you fine with it if i send this chat log to the soc-dev mailing list, so others get to know what we're up to? <onnadi3> I'm all for it. Let 'em know we been working hard ;-)
21 April 2007
*** onnadi3 [i=82cf935f@gateway/web/cgi-irc/ircatwork.com/x-6b272e4f5f832da1] has joined #eclipse-soc *** Topic is: SOC 2007 @ Eclipse is on! http://code.google.com/soc - Get help with ~help - List of accepted applications: http://code.google.com/soc/eclipse/about.html - Find information here: http://wiki.eclipse.org/index.php/Google_Summer_of_Code_2007 - Be patient and stick around for an answer - Subscribe to the mailinglist https://dev.eclipse.org/mailman/listinfo/soc-dev *** Topic set by pombreda [Sun Apr 15 18:10:57 2007] *** onnadi3 faern arhan pombred1 benny`patchslut rcjsuen kynes soulreaper lemmy Pookzilla zx KOS-MOS ijuma *** Channel created on Sun Nov 26 00:42:43 2006 <onnadi3> rcjsuen, lemmy: sorry, people. I'd been waiting in #eclipse_soc ... <rcjsuen> onnadi3: oh, sorry I was not clear <lemmy> Hi Ogehi <lemmy> +c <onnadi3> Hello, Markus <onnadi3> rcjsuen: nah, its my fault. I've been here before :-) <onnadi3> What's been happening in SoC, today? <lemmy> do we have a log? <onnadi3> Ach, I'm using a web client that doesn't support logging... <onnadi3> Can you log? <lemmy> yep, i'll log our conversations. <onnadi3> Good. Thanks <onnadi3> rcjsuen, lemmy: Shall we get down to business? <lemmy> later i'll try to setup logging which redirects to html. <lemmy> onnadi3: sure :) <rcjsuen> Yes, I'm here. <onnadi3> Excellent! <lemmy> remy: you got my email with the proposed agenda? <onnadi3> Yup. <rcjsuen> lemmy: yeah <onnadi3> Quick question before we start: does Eclipse have a "find in files" function? <rcjsuen> in my INBOX <rcjsuen> too <lemmy> ok, wasn't sure if it got caught in the spam filter again. %) <rcjsuen> onnadi3: if you use the search it'll search all open projects, dunno about specifying specific files <rcjsuen> lemmy: wel-, i am sure everyone is busy (except me), let's get started? <onnadi3> rcjsuen: alrighty. Thanks <onnadi3> Sure, let's start <lemmy> do we consider the channel log our meetings minutes? <onnadi3> Sounds fine <rcjsuen> fine by me <lemmy> has either of you anything to add to the agenda? <onnadi3> Nope <rcjsuen> seems ok <rcjsuen> if something comes up i will say something <lemmy> ok, so lets get started with "project documentation". <lemmy> i guess the wiki is a good place to keep general text. <lemmy> but what about diagrams and such, do we wanna use UML? do we need it? <lemmy> Ogechi: are you familiar with UML? <rcjsuen> I've never used UML outside of school, so I am fine if we don't use it <rcjsuen> and that was for like...one term <onnadi3> lemmy: I know of it but haven't used it. It'll be useful if we get're building a boatload of classes <onnadi3> lemmy: I think we should start with prose first and get into UML as the need arises <lemmy> fine with me, lets try to limit the new things in this project. <lemmy> s/things/technology <rcjsuen> lemmy: agreed <onnadi3> agreed <lemmy> so for the project we will work with written text. <onnadi3> For documentation, we'll basically need inline comments, and perhaps a "how to hack" document, right? <onnadi3> lemmy: yup <rcjsuen> yes, the atter is extremey important <rcjsuen> there goes my keys again <lemmy> what do you guys understand under a "how to hack"? <rcjsuen> for there to be users, you need to have a good howto guide <rcjsuen> because we are a-- -azy and woud rather not try to figure out how to use a too- <onnadi3> "how-to-hack: A doc describing how a program was built to aid other developers in modifying it later" <onnadi3> rcjsuen: been typing too long? ;-) <rcjsuen> onnadi3: maybe, dunno, oh wel- <lemmy> to me this sound a little bit too generic. i'd like to narrow it down, so we all expect the same from it. <lemmy> i guess this tool isn't targetted on end users, hence an isv might be appropriate. <rcjsuen> true <onnadi3> what is an ISV? <rcjsuen> embedded in ec-ipse -ike what p-atform does? <rcjsuen> something software vendor i think it is <rcjsuen> independent maybe <onnadi3> For the "how to hack" what I had in mind was something like the documentation for TeX: sthg. that describes data structures used and mnotivation for it. Is this still, too generic <onnadi3> not in WEB, of course <lemmy> maybe we should divide it. we need documentation for people working with the code base and also for people using the codebase. <lemmy> for the latter the typical eclipse documentation for extensionpoints... would probably be the best. for the former i would choose uml. ;p <onnadi3> lemmy: by, people using the codebase, do you mean end-users? <lemmy> onnadi3: yep <lemmy> but i suppose such end-users would be developer too. <lemmy> +s <onnadi3> Yeah, so the "how to hack" will be targetted to developers, and the end-user docs can ba called the user manual <lemmy> makes sense to me <onnadi3> (good point about needing separte docs) <lemmy> anything to add in regards to doc? <rcjsuen> newp <onnadi3> The user manual will have the usual stuff like "how to install", how to use, how to uninstall etc. while the dev-docs will just describe how to extend the plugin etc. <lemmy> since the code will be bundled as plug-ins, we won't need a install/uninstall doc. this is descibed in the osgi/eclipse documentation. <lemmy> onnadi3: is this your first eclipse plug-in you write? <onnadi3> ahem...yeah <onnadi3> :-) <lemmy> no problem :) <rcjsuen> no worries, a lot of ppl last year never wrote a plug-in <lemmy> onnadi3: do you have eclipse open atm? <onnadi3> I'm opening it right now <lemmy> ok, i'll grab a new cup of coffee. <rcjsuen> That means he hasnt gone over to the dark side yet. <onnadi3> oh boy... :-) <lemmy> with the dark side being? <onnadi3> BTW, (while eclipse loads) are we going to hashout all the details of what will be in the docs, or just the general plan? <rcjsuen> if you have eclipse open all the time even when you don't really need it <onnadi3> (Eclipse is up!) <lemmy> for me the general plan is enough atm. <onnadi3> okey-dokey <rcjsuen> as the project (and its scope) is defined (and refined), the details will hash themselves out I think <lemmy> i just want to make sure, we agree on the same thing. :) <onnadi3> rcjsuen: glad to see the fire of your Eclipse youth is not out ;) <onnadi3> lemmy: alrighty <lemmy> onnadi3: if you open the help system, the "JDT plug-in developer guide" might be a good example of what i think would be good end-user doc. <lemmy> certainly not that big though <onnadi3> Ah. I see and understand <onnadi3> That's some pretty documentation <rcjsuen> imo one of the first things that should be done in the documentation phase is properly bui-ding a source plug-in + embedded docs as above <lemmy> btw. suppose we're all happy with the outcome of the project at the end of summer, could you imagine to continue working on the project? <onnadi3> "source plugin"? <rcjsuen> onnadi3: something that includes the java source code of the binary jar that you distribute <rcjsuen> lemmy: yes good question <onnadi3> Hell yeah, I'd continue. This is my first shot at real fame und fortune :) <rcjsuen> onnadi3: many students from the previous year, if you wi-- move on as we--, that is not an issue <lemmy> onnadi3: the question aims at the "internal" documentation. if you're still around to answer questions, we don't need a thoroughly doc. <lemmy> though it is desirable. <onnadi3> Very desirable. You never know when I might get run over by a bus <lemmy> lets hope not at all. ;o <onnadi3> So I think we're good for the user docs. For the dev docs, are y'all fine with something like the TeX docs? <lemmy> you mean something written in tex? i must confess, i don't know the tex documentation. <onnadi3> Oh no no. I mean, the documentation of TeX <lemmy> s/must/have to <onnadi3> http://tex.loria.fr/tex-source/tex-source.html <onnadi3> You'll need a dvi previewer to view it <onnadi3> Basically, I'm just thinking of documentation as detailed as that so that someone can easily understand the source <rcjsuen> if you can go a-- out, that wou-d be great <lemmy> i like detailed. ;) <onnadi3> Deal <onnadi3> So that'll be all the documentation we need for this project right? Are we ready to move on to the next poin in the agenda? <lemmy> what i usually miss the most in terms of project documentation, is the big picture and the major design. <rcjsuen> onnadi3: i think so <lemmy> i don't need a class that contains more javadoc than code. <lemmy> yep, enough for the documentation. ;) <lemmy> s/for the/with <lemmy> the next topic i'd like to see going into the project doc. ;) <lemmy> "Define some terms/Narrow down or extend the scope" <lemmy> i think we should try to come up with a clear understanding of what a service can and cannot be. <lemmy> this will most certainly influence the scope of the project. <lemmy> i could imagine using the wiki page (where i already created a section for it) ;) <lemmy> what is a service? what identifies a service... <lemmy> is the term service even approriate... <rcjsuen> maybe not <lemmy> the current use cases lead to something that i won't really call a service. <onnadi3> Well, a service can be anything that can be identified with URI...but for this Summer, my goal was only to write finders for services on the local machine <rcjsuen> lemmy: you want jdk autodetection, i don't think one woud really call a java runtime a esrvice <rcjsuen> service is something i shou-d be ab-e to restart through /etc/init.d <rcjsuen> and whatever that thing in Win32 is <lemmy> rcjsuen: or via the osgi console ;) <lemmy> maybe we should do the use cases before we define the term? <onnadi3> lemmy: perhaps. May we start with some from the proposal? <lemmy> sure :) <rcjsuen> markus: good idea <onnadi3> BTW, rcjsuen, do you have access to a copy of the proposal? <lemmy> should this be our homework assignment to write down the use cases on the wiki page? we could even ask other people to add theirs. <rcjsuen> markus: yes <onnadi3> Well, one case is like lemmy said, JDK, or gcc, or PERL detection <rcjsuen> lemmy: you need to change your name to start with a key that i dont -ose ha-fway <onnadi3> :-) <lemmy> rcjsuen: maybe you should get yourself a new keyboard instead. ;) <rcjsuen> it sounds -ike we are detecting binaries <rcjsuen> nuh-uh! :( <onnadi3> Well, the logic for detecting binaries is exactly the same needed to find a Webserver on port 80 <onnadi3> (well, kinna the same) <lemmy> onnadi3: lets collect use cases until the next meeting. then we choose some of them which make the most sense and compile the deliverables out of it? <onnadi3> lemmy: Could you please point me to the page you created? <lemmy> until then i think we should postpone the remaining technical agenda items. <lemmy> http://wiki.eclipse.org/index.php/An_auto-configuration_plugin_for_Eclipse <onnadi3> Alrighty! So, on to the organizational items, eh? <lemmy> rcjsuen: btw. i'll ask phillipe to grant you mentor rights in code.google.com. <lemmy> onnadi3: unless you have something technical to add. :) <onnadi3> lemmy: BTW, thanks for putting that page up <onnadi3> lemmy: nope, I'm ready to get orgnanized :) <lemmy> nah, don't mention it. that's what i'm here for. <lemmy> ok, "weekly status meetings". <lemmy> however, normally i prefer daily standup meetings, but this seems to be a problem timezone-wise. <lemmy> at least for me. you two live in the same tz. <onnadi3> oh we do? <onnadi3> rcjsuen: where are you? <onnadi3> *where do you live? <rcjsuen> onnadi3: canada <onnadi3> excellent <lemmy> onnadi3: and he's normally on irc 24/7 ;) <onnadi3> hehehe <onnadi3> I think we should have one weekly meeting, any weekday except Friday <lemmy> for the moment i'd suggest to use this timeslot for our weekly meetings?! <onnadi3> ahh... <lemmy> is it too early= <lemmy> ? <rcjsuen> ten am is fine with me <onnadi3> Could we push it back an hour or so. This waking up on a Saturday thing... :-D <rcjsuen> considering i wake up before seven sometimes <rcjsuen> yes, i just said i wake up before seven sometimes <onnadi3> Even in the summer?? <rcjsuen> yes <rcjsuen> rather, even on the weekends <onnadi3> <cringes> you're strong :) <lemmy> maybe we can move it to sunday then? <rcjsuen> sunday is sti-- a weekend ;p <lemmy> the nightclubs in india close around 1:30 <onnadi3> hahahahahhaa <lemmy> then i'm fine with 11:00am EST/8:30pm IST. <onnadi3> Alright. Saturdays, 11am EST/8:30pm IST starting from May 28? <lemmy> Sundays, 11am EST/8:30pm IST <rcjsuen> we are actua--y EDT, but okay ;p <rcjsuen> if we are fo--owing -ast yr-s schedu-e <onnadi3> Hmm, could we move it back to Saturday? 11am is kinna smack in the middle of church time <onnadi3> on Sundays, that is <rcjsuen> probab-y a week-y soc meeting on thursdays <onnadi3> rcjsuen: I second that <lemmy> rcjsuen: which time? <rcjsuen> lemmy: last year the whole group met on 1200 EDT and, er <rcjsuen> twenty-one hundred? <lemmy> yep <rcjsuen> Two meetings are held every Thursday: <rcjsuen> 1. 0900 PDT - 1200 EDT - 1600 UTC <rcjsuen> 2. 1600 PDT - 1900 EDT - 2300 UTC <rcjsuen> newp, nineteen hundred <rcjsuen> we had two to compensate time zone things <rcjsuen> (and commitments, of course, work/school/wahtever) <rcjsuen> dunno what is philippe's plan this yr <rcjsuen> hello my L key! <rcjsuen> oh nm its dead again ;( <onnadi3> aww <onnadi3> The Ls were nice :) <lemmy> I won't make 2300 utc for sure. <lemmy> 1600 will be hard too, considering that the day starts early in india. but i guess i don't have an option. <onnadi3> So, we'll be meeting on Thursdays and Saturdays, eh? <lemmy> rcjsuen: how long do those meetings usually last? * rcjsuen coughs. <rcjsuen> er, we-- <rcjsuen> we have doub-e the students this round ;p <rcjsuen> sometimes they go over an hr <lemmy> onnadi3: for saturday 10:30am EDT/8:00pm IST as a compromise? ;o <rcjsuen> anyway, this is un-ike-y to be set in stone <rcjsuen> since pom wou-d want to get a fee- for what students agree on this yr <onnadi3> lemmy: sure. (their clubs must be *really* good ;) ) <lemmy> onnadi3: it's better than being home alone. ;) <rcjsuen> lemmy: i'm home alone all the time <lemmy> rcjsuen: you're still young. <onnadi3> hahahahha * lemmy doesn't want to die alone. ;) <lemmy> so, saturdays 10:30am EDT/8:00pm IST it is? <rcjsuen> fine by me <onnadi3> fine by me <onnadi3> And this is starting from May 28? <lemmy> i don't mind if you have your breakfast while typing. ;) <lemmy> onnadi3: that depends on you. if it were for me, we could start right away. <onnadi3> lemmy: I'd love to start too but I'll be out of town three out of the coming four Saturdays <lemmy> just the saturdays or the whole week? <onnadi3> Just the weekends <onnadi3> So, I *could* work and send you updates by e-mail or whenever I catch you on IRC <rcjsuen> either would work <lemmy> rcjsuen: i suppose we won't start with the regular thursday meetings before the official gsoc beginning? <rcjsuen> un-ike-y <rcjsuen> the fact that not many ppl are here means something ;) <onnadi3> Cool, so I guess that's meeting schedules done with <onnadi3> Next up: deliverables? <lemmy> lets postpone it. currently everything is too vague to actually write it down. <rcjsuen> yes <lemmy> also for the milestones/road map <rcjsuen> yeep <onnadi3> On the topic of project housing, does Eclipse still use CVS for legacy reasons? <lemmy> eclipse.org offers svn as well as cvs. <rcjsuen> cvs works so we stick with cvs i spose <lemmy> onnadi3: you're familiar with svn? <onnadi3> Yup...and I love it <onnadi3> So, if we could use it instead of cvs... ;) <lemmy> I'm fine with svn too. If it is technically possible, we should you is. But first we need to talk about the license you want to choose for the code. <lemmy> this is important if we can or cannot use eclipse.org <lemmy> onnadi3: do you have a license model in mind? <rcjsuen> There is also the issue of 3rd party libs <rcjsuen> to factor into the equation, if any <onnadi3> um...I'm a big fan of "Do as you damned well please, just don't give it the same name as mine" <lemmy> rcjsuen: maybe you like to elaborate on this topic? <onnadi3> Is there a license for that? <rcjsuen> we--, licenses ilke those would probably be compatible with the ep <rcjsuen> epl <rcjsuen> onnadi3: for these super-lax licenses, you probaby want to -ook at mit or bsd <rcjsuen> http://www.opensource.org/osi3.0/licenses/bsd-license.php and http://www.opensource.org/osi3.0/licenses/mit-license.php <onnadi3> And those could still be added to the Eclipse source?? <lemmy> onnadi3: if we want to see the code included in eclipse someday, the easiest would be to choose epl. <lemmy> but there is also the possibility of cross-licensing <rcjsuen> they can be committed to cvs but afaik, no one _works_ on the code that is under a different license at eclipse.org <rcjsuen> like we distribute ant with eclipse, but of course, ant development is done by Apache <onnadi3> ah. Then I probably want EPL. <rcjsuen> yes, dual-tri-multi-licensing schemes work too, as lemmy points out <rcjsuen> last yr i dual-ed mine <onnadi3> what licenses didja use? <rcjsuen> but when it came time to throw it on eclipse, i just removed the dual references <rcjsuen> i used MIT/X11 with EPL <rcjsuen> but yes, the easiest way out is to pick epl <lemmy> just keep in mind that epl and gpl are incompatible. <lemmy> it won't be possible to use gpl 3rd party libraries. <onnadi3> alrighty <lemmy> for drools i've checked already and it's apache license. <lemmy> just in case we'll use it. <onnadi3> lemmy: what is in the apache license? <onnadi3> (and where did you pick up "for drools"? ;) ) <lemmy> http://www.apache.org/licenses/LICENSE-2.0.html <onnadi3> Sorry, I meant what were you referring to when you said "I've checked"? <lemmy> drools is a rules engine which might get useful. <lemmy> maybe it's overkill though <onnadi3> oh...ah...I thought you were using it as a turn of phrase :) <lemmy> hehe, no. <onnadi3> Alright, so I guess its sorted for now: Eclipse license...unless we really need a library with a different license <lemmy> personally i think epl makes sense since i see this code going into eclipse at some point. <rcjsuen> yes, I think some of the projects will find it handy <onnadi3> here here <lemmy> if we agree on epl, we should get the paperwork rolling. i'll probably take a couple of weeks to get it done. <onnadi3> Paperwork?? What do we need to do? <rcjsuen> lemmy: paperwork for <rcjsuen> ? <lemmy> new committer? <rcjsuen> lemmy: well, i guess ask pombred1/wayne to get the ball rolling <lemmy> rcjsuen: i don't think philippe plans to do it in a batch. <lemmy> http://www.eclipse.org/projects/dev_process/new-committer.php <rcjsuen> we--, i did not mean -iterally <ijuma> conan is the person to ask about drools btw <ijuma> he's in #eclipse <rcjsuen> batch per se in a way cuz we need to hand in the names when we recreate soc component <ijuma> (if there are questions that is) <lemmy> ijuma: great, good to know somebody personally. :-) <ijuma> it's Mark Proctor btw <ijuma> the lead developer <lemmy> perfect <onnadi3> Does new committer have anythign to do with the license we choose? <ijuma> lemmy: yeah, irc is cool :) <lemmy> _if_ ogechi chooses to use a rule engine after all. ;) <ijuma> well, irc is still cool anyway ;) <lemmy> onnadi3: indirectly... <rcjsuen> It has to do with <rcjsuen> "DO NOT commit non-EPLed code" <rcjsuen> :P <lemmy> onnadi3: to get a developer account at eclipse.org, you need to go through this new committer process. <onnadi3> Ah, I got it <lemmy> using eclipse.org infrastructre makes only sense if you choose epl as a license. <onnadi3> lemmy: Don't I have to "prove my mettle" by at least writing some code first? That way it'll feel more special :) <lemmy> onnadi3: "normally" it is like that. you need to gain "meritocracy points" to be elected as a committer. <lemmy> but for soc it is different. <lemmy> this bug might make things clearer https://bugs.eclipse.org/bugs/show_bug.cgi?id=143583 <lemmy> rcjsuen: correct me if i'm wrong, you know far more about this. <onnadi3> It does clear things up <lemmy> in #eclipse we have our first use case i suppose. ;) <onnadi3> in that case, I guess we've covered all possible ground today <lemmy> and it only took use 1,5h. ;) <rcjsuen> har <rcjsuen> but yes, the idea wou-d have been <onnadi3> We should probably try to meet up again to clear up the biz about deliverables etc. <rcjsuen> keep contributing till you drop <rcjsuen> but since it is a "new project <rcjsuen> new project has an initial set of committers <rcjsuen> so you guys will all be a subset of that set <rcjsuen> the other subset would be the mentors <lemmy> to wrap things up a litte... <lemmy> we'll have two different docs. end-user doc in the eclipse isv format and the internal doc like the tex doc <lemmy> until next week we'll write down use cases in the wiki <lemmy> the next irc status meeting will be on may 28 <lemmy> project will be licensed under epl <rcjsuen> kk <lemmy> regular status meetings will be on saturdays 10:30am EDT/8:00pm IST <onnadi3> So, I guess the conversation will continue asynchronously over the wiki...on the issue of use cases <lemmy> also we'll have general soc status meetings for which the final timing is still TBA <rcjsuen> yes <onnadi3> Sounds like a plan y'all <lemmy> onnadi3: you can add the wiki page to your watchlist. that way you'll receive emails once somebody modifies the page. <rcjsuen> wow that is friggin annoying <lemmy> one last thing. onnadi3 do you have a blog? <onnadi3> I don't have a blog <onnadi3> I thought the wiki was meant for updates on the status of the project etc.? <lemmy> idea is to create a blog for the three of us which we use to blog about the project. (eclipse has a vibrant blogging scene) <lemmy> http://planet.eclipse.org <onnadi3> Can't that be on the wiki page? It would fit nicely there <lemmy> it don't think it is technically possible to add a wiki page to the planet. <lemmy> also we'd not use it for technical discussion, much rather for PR instead. <lemmy> +but <lemmy> it's just an idea though. i don't wanna talk you into it.l <onnadi3> I'll see about that. I would like to put up general thoughts about the state of the project and all <lemmy> in general feel free to stop me/us if we rush things. :) <rcjsuen> :) <onnadi3> No problem. Things are sauntering by for now so I think I can handle it :) <lemmy> if you don't feel comfortable with something, just raise you voice. <onnadi3> NO PROBLEM <onnadi3> ;) <rcjsuen> He probably has a problem with my l key problem. <rcjsuen> Why speak of the devil here it is back online <rcjsuen> maybe for more than thirty seconds this time <lemmy> i think this is the most important point of this meeting. we mentors are meant to support you. we're not your boss. <onnadi3> That's good to know. Remy, Markus, thanks a lot for all your help <onnadi3> BTW, Remy, are you a he or a she? <onnadi3> (if you don't mind) <rcjsuen> np, -ooking forward to working with you in the coming months/weeks <lemmy> although we have a say in terms of payment. ;p <rcjsuen> I am a male. You can even get my mug shot here http://www.eclipsecon.org/2007/index.php?page=sub/&id=3829 <lemmy> wait a sec, let me find the brain pic... <rcjsuen> Markus and I go waaaaaaaaay back....to IRC ;P <lemmy> ah next time, it's stored on the usb drive. <onnadi3> :-) <onnadi3> Alright y'all...I think I shall mosey of now. I've got to please my current employer :) But I'll put up use cases as soon as I get em <rcjsuen> onnadi3: np, see you around <lemmy> have a nice day/weekend <onnadi3> bye bye