Auto-conf meeting logs

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