Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Auto-conf meeting logs"
Line 295: | Line 295: | ||
</pre> | </pre> | ||
+ | ===15 May 2007=== | ||
+ | Gmail chat | ||
+ | <pre> | ||
+ | 10:41 AM markus: Hi | ||
+ | me: Hello, Markus | ||
+ | Howdy? | ||
+ | markus: How are you? | ||
+ | me: I'm fine, thank you | ||
+ | You still in India, I see | ||
+ | 10:42 AM markus: Yep, I am, but only for another month. | ||
+ | 10:43 AM Beginning with June it will be easier to schedule meetings. | ||
+ | me: Excellent | ||
+ | 10:44 AM markus: I'll log this session so Remy gets to know what we decided. | ||
+ | me: Alrighty | ||
+ | So, the main things I wanted to know were | ||
+ | 10:45 AM 1) Shall we stick to the scope of the project as somewhat defined on the wiki? and | ||
+ | 2) Where can I find good free Eclipse learning material? | ||
+ | 10:46 AM markus: Remy brought up the idea to prefer CDT use cases since those fall into the area where we get the most questions in newsgroups and irc. | ||
+ | 10:47 AM me: Ah. Good choice | ||
+ | 10:48 AM markus: But once you got discovery in the local file system working, discovery of jdk or php shouldn only be a matter of adding just another "rule". | ||
+ | -n | ||
+ | me: Yup | ||
+ | 10:49 AM BTW, for CDT we'd need to discover things like the compiler, Make, maybe subversion or CVS etc.? | ||
+ | markus: GCC, any other compiler... | ||
+ | 10:50 AM With GCC being the test case? | ||
+ | me: test case? Do you mean starting point? | ||
+ | markus: Basically it comes down to discovering a binary in the local fs and making sure it's the right one. | ||
+ | me: Yeah | ||
+ | 10:51 AM markus: by generically specifying discovery heuristics. | ||
+ | 10:52 AM Do you have an idea on how to verify that it's indeed the correct binary? Just calling the bin might be dangerous. | ||
+ | 10:53 AM me: That's a good point. Hadn't thought about malicious bins | ||
+ | markus: Might also be slightly expensive to call several binaries. | ||
+ | me: I'm thinking... :) | ||
+ | What do you mean expensive? | ||
+ | 10:54 AM markus: performance | ||
+ | 10:55 AM something like "aBinary --version" shouldn't be too expensive but we can't be sure of the side effects. | ||
+ | On the other hand using something like a checksum might be too strict and I don't know of a fuzzy checksum. ;o | ||
+ | 10:56 AM me: 1 possibility, which isn't very flexible, would be to rely on the registry or environment variables | ||
+ | But of course sometimes, the program isn't registered | ||
+ | 10:57 AM markus: This would require the user to setup the environment or the tool to register appropriately. | ||
+ | But the environment, registry,... could still be used to gather knowledge about the system. | ||
+ | 10:58 AM me: I understand the danger of calling random binaries but perhaps its not so much of a problem since other programs out there do it all time when they "auto-detect" the location of your JDK or some other program | ||
+ | 11:00 AM markus: Well, lets leave the verification open for the moment but lets not forget about it either. | ||
+ | 11:01 AM me: Yeah. That was a very good point you brought up | ||
+ | 11:02 AM markus: In regards of free documentation for eclipse | ||
+ | eclipse.org/articles | ||
+ | wiki.eclipse.org | ||
+ | help system | ||
+ | eclipsezone | ||
+ | news.eclipse.org | ||
+ | 11:03 AM I found http://www.amazon.com/Eclipse-Building-Commercial-Quality-Plug-ins-2nd/dp/032142672X/ref=sr_1_1/102-0371229-4118559?ie=UTF8&s=books&qid=1179241370&sr=8-1 to be very helpful too. | ||
+ | You might find it in a library. | ||
+ | Otherwise those $43 are worth it. | ||
+ | 11:04 AM me: ah. I'll check out the articles first and then probably pick up the book too. | ||
+ | Someone else blogged about using that same book | ||
+ | 11:05 AM markus: I think it's the most comprehensive book on plug-in development. | ||
+ | Though with 3.3 it is slightly outdated, but not much. | ||
+ | 11:06 AM me: okey-doke | ||
+ | markus: Have you thought about a way to describe the heuristics? | ||
+ | 11:07 AM me: I've been reading about Drools and it seems like it might save me from having to invent a mini-language for heuristics | ||
+ | 11:08 AM markus: Great you picked the idea up. :) | ||
+ | me: :) yup | ||
+ | It sounded like you'd worked on it a bit | ||
+ | 11:09 AM howdja get into it? | ||
+ | markus: I read a thesis about rules engines and drools in particular. | ||
+ | And I can contact the author if necessary. | ||
+ | 11:10 AM me: oh wow. What was the thesis about? | ||
+ | markus: using rules engines for implementing business logic in applications. | ||
+ | unfortunately its written in german. | ||
+ | 11:11 AM me: ah... | ||
+ | I gotta hurry up on them Lektions :) | ||
+ | 11:12 AM markus: Next Saturday you won't be in town? | ||
+ | But the one thereafter?! | ||
+ | 11:13 AM me: Yeah | ||
+ | Actually... | ||
+ | I think I'll have access to internet where I'm going | ||
+ | (I'll be at a graduation which is onthe Monday after) | ||
+ | 11:14 AM markus: But it isn't your graduation, is it? | ||
+ | me: Oh no no no | ||
+ | markus: otherwise you might face problems with payment. ;) | ||
+ | 11:16 AM me: <sigh> I'd love to meet then but I won't even know where I might end up that Saturday (since Friday will be a big party for all the graduates and their friends) | ||
+ | (and I might not be sober by then :) ) | ||
+ | markus: I guess i understand. ;) | ||
+ | 11:17 AM me: So for now, I guess the project can be condensed to: | ||
+ | An implementation of a rule engine for detectin binaries on an FS | ||
+ | ? | ||
+ | *detecting | ||
+ | 11:18 AM markus: With the detection part being as generic as possible so it won't be hard to extend it beyond the local fs. | ||
+ | me: yup | ||
+ | 11:19 AM markus: So more like: A framework based on a rules engine to detect "services" with an exemplary local fs implementation. | ||
+ | 11:20 AM me: Ah yes. I like that :) | ||
+ | markus: Btw any news in regards to the paperwork? | ||
+ | me: No. I sent mine in yesterday, though | ||
+ | 11:21 AM markus: The Google or the Eclipse ones? | ||
+ | me: Could you please tell me where I can find the buttons that say whether they've been received? | ||
+ | oh ah. um the google ones | ||
+ | 11:22 AM markus: Tbh I don't know of any button. You might want to ask other students either on #eclipse-soc, soc-dev@eclipse.org or the official google ml. | ||
+ | Might be best to sent a question to soc-dev. Other might search for the same button. ;) | ||
+ | 11:23 AM me: True true. Although the topic was beaten to death a few weeks ago...while I wasn't looking for the button | ||
+ | And so I didn't join it then | ||
+ | I'm gonna be so hated :) | ||
+ | Anyway... | ||
+ | 11:24 AM markus: I haven't seen anything on this topic on the soc-dev ml. %) | ||
+ | me: oh. Sorry, I meant the Google ml | ||
+ | You're right. I'm hitting up soc-dev | ||
+ | BTW, should I put our chat logs on on the wiki? | ||
+ | 11:25 AM markus: IRC or this one? | ||
+ | IIRC for IRC the group agreed on not putting the up. | ||
+ | 11:26 AM them | ||
+ | me: Well, the IRC...and all the "official" meetings | ||
+ | I thought it'd be nice to have em all in one place fore reference | ||
+ | markus: Currently there is some discussion ongoing on how we wanna "monitor" the projects. | ||
+ | 11:27 AM Either inside the wiki, the mailinglist or with bugs in bugzilla. | ||
+ | Or even blog posts. | ||
+ | me: About that, isn't monitoring projects via bugs kind of an abuse of the system? | ||
+ | 11:28 AM I mean, isn't bugzilla meant for bugs? | ||
+ | just wondering | ||
+ | markus: The eclipse development process makes heavy use of bugzilla for all kind of issues so I don't think it would be a problem. | ||
+ | chatlogs could go in as attachments. | ||
+ | 11:29 AM me: OK | ||
+ | So I guess the answer is to wait until y'all decide the means we should use to track our discussions, eh? | ||
+ | 11:30 AM markus: I guess so | ||
+ | me: 'key-doke | ||
+ | 11:31 AM One last question: | ||
+ | How do you manage to be so enthusiastic about Eclipse all the time? | ||
+ | Whenever I talk to you or Remy, I just get all fired up with Eclipse-coding-passion | ||
+ | 11:32 AM markus: Well, I spent nearly all day working with Eclipse. In the evening I'm not that enthusiastic anymore. ;) | ||
+ | But working here in India is more exhausting than back home. | ||
+ | </pre> | ||
===21 April 2007=== | ===21 April 2007=== | ||
Revision as of 12:35, 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 ;-)
15 May 2007
Gmail chat
10:41 AM markus: Hi me: Hello, Markus Howdy? markus: How are you? me: I'm fine, thank you You still in India, I see 10:42 AM markus: Yep, I am, but only for another month. 10:43 AM Beginning with June it will be easier to schedule meetings. me: Excellent 10:44 AM markus: I'll log this session so Remy gets to know what we decided. me: Alrighty So, the main things I wanted to know were 10:45 AM 1) Shall we stick to the scope of the project as somewhat defined on the wiki? and 2) Where can I find good free Eclipse learning material? 10:46 AM markus: Remy brought up the idea to prefer CDT use cases since those fall into the area where we get the most questions in newsgroups and irc. 10:47 AM me: Ah. Good choice 10:48 AM markus: But once you got discovery in the local file system working, discovery of jdk or php shouldn only be a matter of adding just another "rule". -n me: Yup 10:49 AM BTW, for CDT we'd need to discover things like the compiler, Make, maybe subversion or CVS etc.? markus: GCC, any other compiler... 10:50 AM With GCC being the test case? me: test case? Do you mean starting point? markus: Basically it comes down to discovering a binary in the local fs and making sure it's the right one. me: Yeah 10:51 AM markus: by generically specifying discovery heuristics. 10:52 AM Do you have an idea on how to verify that it's indeed the correct binary? Just calling the bin might be dangerous. 10:53 AM me: That's a good point. Hadn't thought about malicious bins markus: Might also be slightly expensive to call several binaries. me: I'm thinking... :) What do you mean expensive? 10:54 AM markus: performance 10:55 AM something like "aBinary --version" shouldn't be too expensive but we can't be sure of the side effects. On the other hand using something like a checksum might be too strict and I don't know of a fuzzy checksum. ;o 10:56 AM me: 1 possibility, which isn't very flexible, would be to rely on the registry or environment variables But of course sometimes, the program isn't registered 10:57 AM markus: This would require the user to setup the environment or the tool to register appropriately. But the environment, registry,... could still be used to gather knowledge about the system. 10:58 AM me: I understand the danger of calling random binaries but perhaps its not so much of a problem since other programs out there do it all time when they "auto-detect" the location of your JDK or some other program 11:00 AM markus: Well, lets leave the verification open for the moment but lets not forget about it either. 11:01 AM me: Yeah. That was a very good point you brought up 11:02 AM markus: In regards of free documentation for eclipse eclipse.org/articles wiki.eclipse.org help system eclipsezone news.eclipse.org 11:03 AM I found http://www.amazon.com/Eclipse-Building-Commercial-Quality-Plug-ins-2nd/dp/032142672X/ref=sr_1_1/102-0371229-4118559?ie=UTF8&s=books&qid=1179241370&sr=8-1 to be very helpful too. You might find it in a library. Otherwise those $43 are worth it. 11:04 AM me: ah. I'll check out the articles first and then probably pick up the book too. Someone else blogged about using that same book 11:05 AM markus: I think it's the most comprehensive book on plug-in development. Though with 3.3 it is slightly outdated, but not much. 11:06 AM me: okey-doke markus: Have you thought about a way to describe the heuristics? 11:07 AM me: I've been reading about Drools and it seems like it might save me from having to invent a mini-language for heuristics 11:08 AM markus: Great you picked the idea up. :) me: :) yup It sounded like you'd worked on it a bit 11:09 AM howdja get into it? markus: I read a thesis about rules engines and drools in particular. And I can contact the author if necessary. 11:10 AM me: oh wow. What was the thesis about? markus: using rules engines for implementing business logic in applications. unfortunately its written in german. 11:11 AM me: ah... I gotta hurry up on them Lektions :) 11:12 AM markus: Next Saturday you won't be in town? But the one thereafter?! 11:13 AM me: Yeah Actually... I think I'll have access to internet where I'm going (I'll be at a graduation which is onthe Monday after) 11:14 AM markus: But it isn't your graduation, is it? me: Oh no no no markus: otherwise you might face problems with payment. ;) 11:16 AM me: <sigh> I'd love to meet then but I won't even know where I might end up that Saturday (since Friday will be a big party for all the graduates and their friends) (and I might not be sober by then :) ) markus: I guess i understand. ;) 11:17 AM me: So for now, I guess the project can be condensed to: An implementation of a rule engine for detectin binaries on an FS ? *detecting 11:18 AM markus: With the detection part being as generic as possible so it won't be hard to extend it beyond the local fs. me: yup 11:19 AM markus: So more like: A framework based on a rules engine to detect "services" with an exemplary local fs implementation. 11:20 AM me: Ah yes. I like that :) markus: Btw any news in regards to the paperwork? me: No. I sent mine in yesterday, though 11:21 AM markus: The Google or the Eclipse ones? me: Could you please tell me where I can find the buttons that say whether they've been received? oh ah. um the google ones 11:22 AM markus: Tbh I don't know of any button. You might want to ask other students either on #eclipse-soc, soc-dev@eclipse.org or the official google ml. Might be best to sent a question to soc-dev. Other might search for the same button. ;) 11:23 AM me: True true. Although the topic was beaten to death a few weeks ago...while I wasn't looking for the button And so I didn't join it then I'm gonna be so hated :) Anyway... 11:24 AM markus: I haven't seen anything on this topic on the soc-dev ml. %) me: oh. Sorry, I meant the Google ml You're right. I'm hitting up soc-dev BTW, should I put our chat logs on on the wiki? 11:25 AM markus: IRC or this one? IIRC for IRC the group agreed on not putting the up. 11:26 AM them me: Well, the IRC...and all the "official" meetings I thought it'd be nice to have em all in one place fore reference markus: Currently there is some discussion ongoing on how we wanna "monitor" the projects. 11:27 AM Either inside the wiki, the mailinglist or with bugs in bugzilla. Or even blog posts. me: About that, isn't monitoring projects via bugs kind of an abuse of the system? 11:28 AM I mean, isn't bugzilla meant for bugs? just wondering markus: The eclipse development process makes heavy use of bugzilla for all kind of issues so I don't think it would be a problem. chatlogs could go in as attachments. 11:29 AM me: OK So I guess the answer is to wait until y'all decide the means we should use to track our discussions, eh? 11:30 AM markus: I guess so me: 'key-doke 11:31 AM One last question: How do you manage to be so enthusiastic about Eclipse all the time? Whenever I talk to you or Remy, I just get all fired up with Eclipse-coding-passion 11:32 AM markus: Well, I spent nearly all day working with Eclipse. In the evening I'm not that enthusiastic anymore. ;) But working here in India is more exhausting than back home.
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