Attendees: clsk, j_k9, neeraj, tstone2077
Note: All timestamps in UTC+2
This meeting's agenda is available here.
Oct 16 02:12:44 <j_k9_> Alright! This is everyone, so let's start :)
Oct 16 02:13:12 <j_k9_> First of all, it's great to see that this project is back on track, so thanks to all of you for being here.
Oct 16 02:13:37 <j_k9_> Let's try to make it to a full release this time, right? ;)
Oct 16 02:13:49 <clsk> riiiight
Oct 16 02:14:11 <clsk> It'll take 3 or 4 more of these. But we'll get there
Oct 16 02:14:21 <neeraj> sure
Oct 16 02:14:37 <j_k9_> I think we should start with the agenda in order: first the administrative topics, then the design. If anyone has any other points they would like to mention which aren't on the agenda, we'll make time for that at the end.
Oct 16 02:15:36 <j_k9_> I agree with clsk's point that we should move away from SourceForge completely. This involves moving our last remaining attachment - the mailing list - from SourceForge to Launchpad.
Oct 16 02:16:10 <j_k9_> My plan is to set up the mailing list on Launchpad and invite all the developers to subscribe to it.
Oct 16 02:16:29 <clsk> I think we should try it out first, and see how it works.
Oct 16 02:16:59 <j_k9_> Definitely. Although it runs GNU Mailman (so it should be fine), we should at least verify that it all works smoothly.
Oct 16 02:17:04 <clsk> I just saw that there are mailing lists in launchpad now, but I'm not sure how they work
Oct 16 02:17:09 <clsk> oh ok
Oct 16 02:17:12 <clsk> didn't know that
Oct 16 02:17:27 <j_k9_> Then, if we're satisfied, we'll create a final thread in our current mailing list notifying everyone of the change and move to the new one.
Oct 16 02:17:43 <clsk> I remember the earliest implementation of their mailing list feature didn't allow for the list to be public
Oct 16 02:18:53 <j_k9_> I think the current implementation does allow lists to be public. See: https://help.launchpad.net/ListHelp
Oct 16 02:18:54 <clsk> but I don't think they were using mailman back then
Oct 16 02:19:33 <j_k9_> It allows non-subscribers to post to the list, so I presume the list archives etc are also public. It's just a question of configuring the mailing list correctly.
Oct 16 02:19:57 <clsk> yea, it says the archives are public
Oct 16 02:20:00 <clsk> good
Oct 16 02:20:15 <j_k9_> Great. Does everyone agree with this plan then?
Oct 16 02:20:36 <neeraj> look good to me too
Oct 16 02:20:37 <clsk> launchpad has come a long way :)
Oct 16 02:20:41 <clsk> yep
Oct 16 02:22:11 <j_k9_> Ok, next on the agenda. This is a point raised by Alan which I think is crucial to keeping our main branch (trunk) in a stable condition. The suggestion is to work on code in a separate branch under ~mira-dev/ until the code compiles correctly on all supported platforms.
Oct 16 02:22:39 <j_k9_> Once the code compiles on Windows, Linux and Mac OS X, then a proposal can be made to merge it into trunk.
Oct 16 02:22:48 <clsk> and runs :)
Oct 16 02:23:00 <clsk> at least compile, but testing before merging would be nice too
Oct 16 02:23:14 <j_k9_> Good point :)
Oct 16 02:23:15 <j_k9_> For example, Alan's current work on the P2P system is being housed in lp:~mira-dev/mira/p2p
Oct 16 02:23:23 <j_k9_> instead of lp:mira
Oct 16 02:23:27 <clsk> However, we do have an issue. We don't have anyone with a Mac box in the team.
Oct 16 02:23:46 <clsk> so for now I'd say at least make sure it compiles/runs in linux and windows
Oct 16 02:23:48 <j_k9_> I have a Mac, it's just a question of setting up the build system correctly (which I failed to do last time).
Oct 16 02:23:56 <clsk> would be nice to test BSD systems too
Oct 16 02:23:58 <clsk> oh
Oct 16 02:24:12 <clsk> would be nice if there was a Mac emulator
Oct 16 02:24:50 <j_k9_> This is a separate point on the agenda though. For now, does everyone agree that this should be a general course of action in the future? I think this deserves a completely separate thread in the mailing list to notify the other developers if we agree on it.
Oct 16 02:25:28 <clsk> either way, I'm going to try and setup a openbsd or freebsd virtual machine to test code on too
Oct 16 02:25:28 <neeraj> I did not get chance to work on anything to check-in check-out for mira
Oct 16 02:26:00 <neeraj> so I am not sure of branching and stuff
Oct 16 02:26:30 <neeraj> I was working on local copy
Oct 16 02:26:50 <neeraj> Its been a long time do we have something on our site regarding that.
Oct 16 02:27:00 <clsk> neeraj, all you have to do is create a branch in launchpad and then “bzr push” to that branch
Oct 16 02:27:30 <clsk> and then keep pushing to it
Oct 16 02:28:00 <clsk> I could walk you through it if you want
Oct 16 02:28:20 <neeraj> ok sure I can check the bzr command and if I have issue I will get back to you guys.
Oct 16 02:28:25 <neeraj> commands*
←- j_k9 (n=max@75.243.120.212.dsl.dynamic.gibconnect.com) has quit (Read error: 110 (Connection timed out))
Oct 16 02:28:30 <neeraj> great
Oct 16 02:28:40 <clsk> ok, should we keep going?
Oct 16 02:28:45 <neeraj> np
Oct 16 02:29:20 <clsk> j_k9_ ?
Oct 16 02:29:30 <tstone2077> so, how are the merges going to happen? are we going to have one person build a specific version on all platforms (linux/windows to start)?
Oct 16 02:29:50 <clsk> well if you're working on something and you want to merge it to the main branch (trunk), there's a “Propose merge” button (feature) in launchpad
Oct 16 02:30:03 <clsk> then at that time we could all review the merge (compile/test/add/remove code)
Oct 16 02:30:14 <clsk> and once everybody's happy then we'd do the merge
Oct 16 02:30:19 <j_k9> I'm sorry about this - my connection has chosen the worst time to drop. I'm back.
Oct 16 02:30:31 <clsk> I haven't tried the feature yet, but it's supposed to be neat
Oct 16 02:30:55 <neeraj> I am just thinking is it too much dependency?
Oct 16 02:31:14 <clsk> hm dependency on what? on other people?
Oct 16 02:31:21 <neeraj> yeah
Oct 16 02:31:33 <neeraj> if people are active it should be ok
Oct 16 02:31:38 <clsk> but that's the way it should work though (I think)
Oct 16 02:31:42 <clsk> yea, well that's the thing
Oct 16 02:31:49 <neeraj> but when everyone is hibernating?
Oct 16 02:31:52 <clsk> if nobody else is active, then I'd say go ahead and merge
Oct 16 02:32:03 <clsk> yea, I know, there's been a lot of that in this project
Oct 16 02:32:12 <clsk> so if nobody else is around, then just go ahead and merge
Oct 16 02:32:17 <clsk> just try to test as much as possible
Oct 16 02:32:20 <neeraj> yeah but if one person who wants to merge and has only one OS?
Oct 16 02:32:53 <tstone2077> before a release, though, i think it should be mandatory to test each platform. If that is trunk or not doesn't really matter.
Oct 16 02:32:54 <clsk> even if there's people around and for example right now, nobody can compile the code in Mac OS, then there's nothing we can do. It'd be counter-productive to just stop development
Oct 16 02:33:06 <clsk> oh yea, before release definitely
Oct 16 02:33:30 <clsk> neeraj, I'd say try to run on a virtual machine at least. But as a last resort, go ahead and merge.
Oct 16 02:33:46 <neeraj> make sense
Oct 16 02:33:58 <clsk> Maybe it shouldn't be a rule, but more of a policy. Do it if possible, if not… oh well
Oct 16 02:34:14 <tstone2077> that works
Oct 16 02:34:15 <neeraj> :)
Oct 16 02:34:37 <j_k9> That's better than a strict rule.
Oct 16 02:35:37 <clsk> ok.. moving on?
Oct 16 02:35:49 <j_k9> Ok, so that's that. We also mentioned needing a Mac, which is on the agenda. I have a Mac but I remember having difficulty setting up a suitable development environment for Mira the last time I tried. I think we need to find a developer with Mac OS X experience.
Oct 16 02:36:13 <j_k9> Alan, if you could test on BSD that would definitely help
Oct 16 02:36:52 <clsk> j_k9: do you want me to send you what was said while your connection dropped?
Oct 16 02:37:03 <j_k9> clsk: By email would be great, thanks.
Oct 16 02:37:23 <clsk> sent
Oct 16 02:38:17 <clsk> I'm thinking about buying a Mac in the future. I plan to buy a new laptop in about two months. I just can't justify expending extra $ on a computer with inferior hardware.
Oct 16 02:38:25 <clsk> but I'm thinking about it. We'll see how it goes
Oct 16 02:38:52 <j_k9> clsk: If you do, and manage to set up a dev environment, please let me know. If not, would you be able to set up a Mac OS X virtual machine?|
Oct 16 02:39:12 <clsk> I don't think such a thing is possible
Oct 16 02:39:24 <j_k9> I think it is now that Mac OS X runs on x86: http://wiki.osx86project.org/wiki/index.php/Vmware_how_to
Oct 16 02:39:24 <clsk> I was trying to find out if it was last night, but didn't see anything
Oct 16 02:39:33 <tstone2077> I've done that before
Oct 16 02:39:36 <clsk> ogg
Oct 16 02:39:37 <clsk> ohh
Oct 16 02:39:39 <clsk> lets see
Oct 16 02:39:46 <neeraj> new to me
Oct 16 02:40:01 <j_k9> clsk, are you up for trying this out?
Oct 16 02:41:22 <clsk> definitely
Oct 16 02:41:26 <clsk> will try it out this weekend
Oct 16 02:41:40 <j_k9> Ok, duly noted. By the way, reading through the log clsk sent me, neeraj seemed to have a few queries about Bazaar. This document might help: http://miragroupware.org/wiki/doku.php/development/bazaartechniques
Oct 16 02:42:45 <clsk> wonder if it'll work with the linux version of vmware
Oct 16 02:43:18 ←- j_k9_ has quit (Read error: 110 (Connection timed out))
Oct 16 02:43:19 <clsk> oh also, make sure to associate bazaar with your launchpad account
Oct 16 02:43:42 <j_k9> Yes, that's important. That should be on the wiki as well under 'configuring Bazaar'.
Oct 16 02:44:21 <j_k9> Next on the agenda is tracking tasks with Launchpad Blueprints. We are doing this at the moment, but I think it's a little too high-level at the moment which makes using it less useful. Alan, would you mind explaining this in more detail?
Oct 16 02:45:17 <clsk> one more thing on the previous topic
Oct 16 02:45:36 <j_k9> Sure.
Oct 16 02:45:41 <clsk> it's about the wiki. Instead of just emailing patches, people can create branches under their username in Bazaar
Oct 16 02:45:49 <clsk> and then use the “Propose Merge” feature too
Oct 16 02:45:54 <clsk> that's it
Oct 16 02:46:12 <j_k9> Thanks clsk, I didn't know that. I'll check it out and amend the wiki.
Oct 16 02:46:44 <clsk> j_k9: To be honest, I don't know THAT much about the blueprint feature. However, I've seen how other projects use it, and it's pretty nice
Oct 16 02:46:57 <clsk> you can design the whole thing and share with others
Oct 16 02:47:08 <clsk> so you can have different people edit the blueprint
Oct 16 02:47:39 <j_k9> We have that, I just don't think we've taken full advantage of it. How do you think we can use it more effectively?
Oct 16 02:47:50 <clsk> you can add dependencies and stuff
Oct 16 02:47:54 <clsk> and it'll map it graphically
Oct 16 02:48:05 <clsk> yea, that's true
Oct 16 02:48:07 <j_k9> I think tstone2077 did this with the GUI modules.
Oct 16 02:48:13 <clsk> yes
Oct 16 02:48:14 <tstone2077> wow… each blueprint can be part of a sprint
Oct 16 02:48:19 <clsk> I guess we should just keep using it
Oct 16 02:48:52 <j_k9> Should we use it in greater detail though? As Thurston did: break down layers into bite-size chunks, connected graphically?
Oct 16 02:49:07 <clsk> Although the wiki is nice to present blueprints, we should probably use launchpads to work on them, and then when they're in a stable state (the blueprint itself) then we can post it on the wiki
Oct 16 02:49:18 <clsk> also, I think you can associate blueprints with branches
Oct 16 02:49:33 <clsk> so when yo do a branch merge request for example, people can go and see the blueprint
Oct 16 02:49:37 <clsk> it's all well integrated IMO
Oct 16 02:49:52 <clsk> yea
Oct 16 02:49:53 <clsk> maybe
Oct 16 02:50:19 <clsk> but, we should just make sure that when we create blueprints it's something we're going to work on (like Thurston did)
Oct 16 02:50:29 <clsk> not just create blueprints to do it
Oct 16 02:50:32 <neeraj> if the blueprint can attach with the branch that is good
Oct 16 02:51:15 <clsk> tstone2077: yea that's really nice. Just realized that too
Oct 16 02:51:36 <j_k9> It looks like it can by being 'linked' to the branch: https://launchpad.net/+tour/feature-tracking
Oct 16 02:51:37 <clsk> I think launchpad is an excellent site. We just need to exploit (use) its features
Oct 16 02:52:06 <clsk> you can link bug reports too
Oct 16 02:52:17 <j_k9> tstone2077: That's a good point. We could use this to determine exactly which modules need to be implemented for 0.1, 0.2, etc.
Oct 16 02:52:19 <clsk> I'm probably going to do a blueprint on the P2P stuff
Oct 16 02:52:23 <clsk> and expand the network blueprint
Oct 16 02:52:30 <clsk> I'll be back in a second
Oct 16 02:52:44 <clsk> I have to let my dog outside. He's begging to use the bathroom
Oct 16 02:52:52 <neeraj> whats sprint tstone2077
Oct 16 02:52:58 <j_k9> But as smaller, discrete 'modules' which combine to make a layer
Oct 16 02:53:44 <tstone2077> a sprint is an agile development terminology – http://en.wikipedia.org/wiki/Scrum_(development)
Oct 16 02:54:05 <tstone2077> well… i guess it's more of a term than an entire terminology
Oct 16 02:54:09 <neeraj> ok got you
Oct 16 02:55:04 <j_k9> So, let's summarise our plan for blueprints (let me know if this is right):
Oct 16 02:55:27 <j_k9> - Use greater detail by splitting layers into modules, one blueprint per module (as Thurston did with the GUI)
Oct 16 02:55:52 <j_k9> - Collaborate on blueprints on Launchpad, then copy to the wiki when they are in an approved/stable state
Oct 16 02:56:23 <j_k9> - Link blueprints to personal branches when working on code which *might* be merged into trunk
Oct 16 02:56:37 <tstone2077> I have an edit to that
Oct 16 02:56:42 <j_k9> Please do.
Oct 16 02:57:25 <tstone2077> For me, it makes sense to make a branch for each blueprint (which is basically a defined unit of work). then once the work is complete, the branch should probably be merged to the dev branch
Oct 16 02:58:02 <tstone2077> if the dev branch builds nicely on linux/windows/mac/bsd/google chrome/android/etc… then it can go to trunk
Oct 16 02:58:34 <tstone2077> so… the dev is basically a cumulation of completed blueprints
Oct 16 02:58:40 <tstone2077> and the trunk is a stable dev
Oct 16 02:58:52 <tstone2077> … just a thought
Oct 16 02:59:07 <clsk> hm
Oct 16 02:59:29 <clsk> yea I think it makes sense
Oct 16 02:59:55 <j_k9> Ok, so what would the procedure be?
Oct 16 03:00:07 <clsk> hm .. thinking about it
Oct 16 03:00:33 <clsk> also
Oct 16 03:01:13 <clsk> maybe changing the word module with “sprint” (that's a new term to me too) would make more sense. People could and will misinterpret module as the term is used for so many things
Oct 16 03:01:43 <clsk> I think what tstone2077 is saying makes sense
Oct 16 03:01:47 <tstone2077> sprint is typically more of a timeframe… say… 3 weeks or so
Oct 16 03:02:10 <clsk> oh ok
Oct 16 03:02:12 <clsk> makes sense
Oct 16 03:02:19 <clsk> either way, we should name the wording
Oct 16 03:02:24 <tstone2077> yeah
Oct 16 03:02:41 <clsk> people have to realize though, that if you're working on a branch, you could merge with branches other people are working on
Oct 16 03:03:07 <tstone2077> certainly… there is a lot of power in distributed SCM that we can take advantage of
Oct 16 03:03:14 <clsk> so if for example, I'm working on the network code, and Thurston is working on the GUI branch, and Thurston creates a function for me to update the GUI so that it reflects a change in the network
Oct 16 03:03:20 <clsk> then we should merge our branches
Oct 16 03:03:27 <clsk> yep
Oct 16 03:03:28 <j_k9> That makes sense
Oct 16 03:03:29 <clsk> I agree
Oct 16 03:03:35 <clsk> I really like bazaar/launchpad
Oct 16 03:03:44 <tstone2077> me too… it's very impressive
Oct 16 03:03:54 <clsk> it's pretty nice. So much you can do that you couldn't do with cvs and svn
Oct 16 03:04:07 <clsk> so.. can you create these so-called sprints in launchpad?
Oct 16 03:04:19 <clsk> like is there a visual/object representation of this?
Oct 16 03:04:53 <j_k9> I'm not sure I understand the need for the dev branch though. If the code is completed in a personal branch, can't other people check out the personal branch, test the code and, if it works, merge the personal branch directly into trunk?
Oct 16 03:05:11 <j_k9> Otherwise, we'll need someone who is capable of maintaining the dev and trunk branches in sync.
Oct 16 03:05:28 <clsk> well. The trunk is where everything is merged together.
Oct 16 03:05:32 <tstone2077> FYI… the basic idea in scrum is that you have a giant list of things to do… a backlog… then you prioritize important things to the top. Then there is a sprint (3 weeks) to do the top most items. I think that will be very useful for managing bug fixes vs. feature requests.
Oct 16 03:06:00 <clsk> yep, I agree
Oct 16 03:06:13 <clsk> j_k9: Yes. We all do that though.
Oct 16 03:06:19 <clsk> that's what merge proposals are for
Oct 16 03:06:29 <clsk> we review the code before it's merged into trunk
Oct 16 03:06:29 <neeraj> but then how does it integrate with the branching and merging?
Oct 16 03:06:40 <clsk> that way we know everything in branch has been tested
Oct 16 03:06:50 <neeraj> tstone2077, are you saying after every work done we instantly merge?
Oct 16 03:07:12 <clsk> if possible in the future we should create test cases, and even more in the future regression tests
Oct 16 03:07:22 <tstone2077> yeah… it just gives a little more stability to trunk. Yeah, after work is done, we merge, but bzr has made merging much less painful than SVN and CVS
Oct 16 03:07:39 <j_k9> clsk: Sprints in Launchpad are controlled here: https://launchpad.net/sprints
Oct 16 03:07:41 <tstone2077> merges/branches can be done often and easily (usually)
Oct 16 03:07:44 <clsk> well, make the proposal first and let people review the changes
Oct 16 03:08:03 <j_k9> But would that be a proposal to merge to the dev branch or trunk?
Oct 16 03:08:31 <clsk> oh, for them sprints are more like meetings it seems.
Oct 16 03:08:46 <clsk> the dev branch = trunk right?
Oct 16 03:09:08 <tstone2077> the proposal would be to merge to trunk… since that is the stable. dev can be merged by anyone with a blueprint
Oct 16 03:09:47 <tstone2077> i can write up a little proposal on the process and send it out
Oct 16 03:09:52 <tstone2077> see what you guys think
Oct 16 03:09:57 <j_k9> tstone2077: So are you suggesting we create a dev branch to take care of this?
Oct 16 03:10:08 <clsk> seems like sprints are a new feature to launchpad I think
Oct 16 03:10:17 <j_k9> That proposal would be a good idea. I'd be happy to discuss that on the list.
Oct 16 03:10:24 <clsk> hm
Oct 16 03:10:27 <clsk> I'm confused
Oct 16 03:10:45 <clsk> oh I see now
Oct 16 03:10:57 <clsk> yea, the proposal would be to merge to trunk
Oct 16 03:11:07 <clsk> after the merge is done, then that dev branch can be deleted
Oct 16 03:11:22 <tstone2077> ok, i'll draft up something this weekend
Oct 16 03:11:23 <clsk> and any further fixes, additions, etc… would be done directly to trunk
Oct 16 03:11:42 <clsk> tstone2077: cool
Oct 16 03:12:13 <j_k9> Going back to blueprints quickly, I think we should use the 'Series goal'/'Milestone' features - that should help us identify which features are essential for version 0.1, 0.2, etc.
Oct 16 03:12:59 <clsk> yea
Oct 16 03:13:35 <clsk> that's always subject to change I suppose though, especially this early on in development
Oct 16 03:14:01 <j_k9> Ok, I think we can put those two topics to the side for now, unless anyone else has something to add. How are we all doing for time?
Oct 16 03:14:02 <tstone2077> j_k9: definitely
Oct 16 03:14:04 <clsk> like, for example, we weren't planning on service discovery, but I just felt like working on this last weekend and got it finished. So we could always add stuff
Oct 16 03:14:18 <j_k9> clsk: That's true.
Oct 16 03:14:26 <clsk> I'm good for another two hours
Oct 16 03:14:34 <tstone2077> I am going to have to go in about 15 min
Oct 16 03:15:07 <j_k9> Ok, in that case shall we skip to design quickly to discuss the more important topics (e.g. Directory layer, P2P)?
Oct 16 03:15:32 <j_k9> neeraj, are you pushed for time at the moment?
Oct 16 03:15:39 <clsk> well, all I have to say about the Directory layer, is that we need someone to work on it
Oct 16 03:15:54 <clsk> It's something we really really need right now
Oct 16 03:15:54 <neeraj> no
Oct 16 03:16:02 <clsk> but honestly, it's something that doesn't personally interest me
Oct 16 03:16:15 <clsk> I'll work on it if I have to, but I'd rather someone else worked on it
Oct 16 03:16:22 <j_k9> clsk: I think the problem is that developers don't know where to start with it, even with the blueprint
Oct 16 03:16:34 <clsk> yea, we need more design work on it.
Oct 16 03:16:36 <j_k9> The two developers that have started it have given up
Oct 16 03:16:41 <clsk> it's really something very complex
Oct 16 03:16:52 <clsk> I've spent hours scratching my head on it.
Oct 16 03:16:54 <neeraj> I am gonna work on Directory
Oct 16 03:17:02 <neeraj> but I need HELP!
Oct 16 03:17:14 <neeraj> I would need help is better ;)
Oct 16 03:17:18 <clsk> I think I had somewhat if a design a while ago and started working on it, but quit working on it because it was just confusing
Oct 16 03:17:28 <clsk> neeraj: I can help
Oct 16 03:17:32 <j_k9> Neeraj, we understand! Directory is probably the toughest layer
Oct 16 03:17:45 <clsk> it definitely is I think.
Oct 16 03:18:04 <clsk> to me, I find it to be the most boring layer to work on too. Which is what makes it really challenging
Oct 16 03:18:21 <neeraj> I have been doing nothing and then I loose interest.
Oct 16 03:18:26 <clsk> but it's very necessary before we can implement any of the high-level features
Oct 16 03:18:57 <clsk> the blueprint only talks about the high-level stuff
Oct 16 03:19:04 <clsk> there's a lot more details that need to be worked out
Oct 16 03:19:32 <clsk> tstone2077: question before you go.. are you going to be able to start working on the GUI again?
Oct 16 03:19:38 <neeraj> sure
Oct 16 03:19:57 <tstone2077> yeah, i would like to
Oct 16 03:20:08 <tstone2077> if not the GUI, i can work on other portions
Oct 16 03:20:18 <clsk> GUI is great
Oct 16 03:20:28 <clsk> you've done a great job with it, or so I think
Oct 16 03:20:36 <tstone2077> :) thanks
Oct 16 03:20:47 <clsk> btw, I found out how to call GUI methods from other threads
Oct 16 03:20:48 <j_k9> clsk: I agree. Great job, Thurston! Excellent choice to use Qt too :)
Oct 16 03:21:18 <clsk> If you get a chance, look at the branch I created so you can see.
Oct 16 03:21:31 <tstone2077> clsk: very cool! that will definitely be needed… i'll take a look
Oct 16 03:21:48 <clsk> I had to make the MainWindow object a global singleton
Oct 16 03:22:06 <clsk> and then we need to be able to get GUI objects from that class
Oct 16 03:22:18 <clsk> although, another design would probably be better
Oct 16 03:22:25 <clsk> but that's quick hack I came up with
Oct 16 03:22:34 <clsk> last weekend
Oct 16 03:23:04 <j_k9> clsk: Would you be happy to mentor neeraj on IRC (or some other way) and flesh out the design of the Directory layer in more detail? I'd be happy to transcribe it all into a blueprint - the plaintext backend currently doesn't have one on Launchpad (or the wiki).
Oct 16 03:23:25 <clsk> j_k9: Sure.
Oct 16 03:23:35 <j_k9> clsk: It'd be helpful to go through the work you've already done on it with him.
Oct 16 03:23:37 <clsk> hmm the plaintext backend is really just a proof-of-concept
Oct 16 03:23:44 <clsk> and we should probably scratch the whole thing anyway
Oct 16 03:24:14 <clsk> maybe base it somewhat on it. But I don't think it's really a good model
Oct 16 03:24:26 <clsk> so I don't think we should document it really
Oct 16 03:24:32 <j_k9> Ok, but in that case we need a strong design for the next version of the plaintext backend, one than Neeraj can work with.
Oct 16 03:24:40 <clsk> yep
Oct 16 03:24:45 <clsk> that's what we're going to work on
Oct 16 03:25:01 <clsk> a design that's flexible enough to work with the other backends we plan on having
Oct 16 03:25:06 <j_k9> It should be a similar concept for all the backends - the only difference should be the method in which the data is accessed/stored, not the structure or content of the data.
Oct 16 03:25:13 <j_k9> Exactly.
Oct 16 03:25:31 <clsk> Can we talk a little bit about the network code
Oct 16 03:25:40 <j_k9> Of course, go ahead.
Oct 16 03:26:08 <clsk> ok, this might be a bit radical, but I think we should redesign some of it
Oct 16 03:26:17 <clsk> not the code itself, but the high-level functionalities
Oct 16 03:26:41 <clsk> I think this is probably we should discuss on the list, because it'll take some time
Oct 16 03:27:08 <clsk> the first thing is… P2P model and client-server should and have to work differently
Oct 16 03:27:09 <j_k9> clsk: Can you send an email to the list explaining your proposal for the network code?
Oct 16 03:27:15 <clsk> sure
Oct 16 03:27:26 <clsk> it might take me a few days, because I'm really still thinking about it
Oct 16 03:27:53 <clsk> One thing I do want to express
Oct 16 03:28:25 <clsk> one of the ideas I have, and I think we've wanted it to work this way since the beginning, is to be able to have Mira work on an unconfigured network
Oct 16 03:28:36 <clsk> or just a small LAN seamlessly
Oct 16 03:28:44 <clsk> I think it's something that would make it very popular
Oct 16 03:28:51 <clsk> have Mira “just work”
Oct 16 03:29:17 <j_k9> That makes a lot of sense. Is that your idea behind the Avahi code?
Oct 16 03:29:30 <clsk> people in a network open up mira and they see neighbors and they can start using it. Sharing files, have conversations, have version controlled files
Oct 16 03:29:32 <clsk> yea
Oct 16 03:29:43 <neeraj> ok
Oct 16 03:29:48 <clsk> Have heard of Giber?
Oct 16 03:29:51 <clsk> Giver
Oct 16 03:30:08 <tstone2077> that's a very good idea!
Oct 16 03:30:14 <clsk> An application a Novell employee created in some kind of week camp thing novell did
Oct 16 03:30:23 <clsk> Is that, but with all the mira capabilities
Oct 16 03:30:24 <j_k9> The problem with that is controlling the roles that individual members of a Workplace would have if there is no server coordinating it
Oct 16 03:30:27 <clsk> that's what I'd like to have
Oct 16 03:30:32 <clsk> if you get a chance, look at it
Oct 16 03:30:39 <clsk> well, that's the thing
Oct 16 03:30:40 <j_k9> clsk: I'll take a look.
Oct 16 03:30:53 <clsk> In P2P mode, someone would have to create a workspace
Oct 16 03:31:02 <clsk> and then invite others to join the workspace
Oct 16 03:31:12 <clsk> the workspace is then completely distributed after that
Oct 16 03:31:19 <clsk> and probably everybody will have access to it
Oct 16 03:31:22 <j_k9> Right, so effectively the person creating the Workplace is acting as the Server
Oct 16 03:31:26 <clsk> but that's only in P2P mode
Oct 16 03:31:37 <j_k9> in P2P mode.
Oct 16 03:31:37 <clsk> what we've planned for client-server mode will still hold true
Oct 16 03:31:44 <clsk> well
Oct 16 03:31:47 <clsk> at first probably
Oct 16 03:31:53 <clsk> but after that it can transfer
Oct 16 03:32:08 <clsk> if that person drops off the network, then someone else would take over as the server
Oct 16 03:32:18 <j_k9> That sounds like it would work! Would it be easier to implement Client-Server first though, seeing as that has a consistent structure?
Oct 16 03:32:25 <clsk> is not really a server, it's somewhat of a control station. But the whole thing is completel distributed
Oct 16 03:32:45 <clsk> hm I think I can pull of the P2P stuff quite fast
Oct 16 03:32:51 <clsk> it should actually be easier I think
Oct 16 03:32:57 <clsk> but, that brings me to another topic
Oct 16 03:33:06 <clsk> maybe we should build in basic utilities
Oct 16 03:33:21 <clsk> especially the version control file utility
Oct 16 03:33:29 <clsk> file sharing should also probably
Oct 16 03:33:37 <tstone2077> i have to take off
Oct 16 03:33:47 <clsk> also, in P2P mode, if you're not on a workspace you can also chat and share files
Oct 16 03:33:54 <clsk> maybe send appointsments and things like that
Oct 16 03:34:01 <clsk> ok tstone2077, take care
Oct 16 03:34:04 <j_k9> clsk: All sounds good.
Oct 16 03:34:15 <tstone2077> this is good stuff… I'll take a look at the rest of the notes later… thanks! and see ya!
Oct 16 03:34:22 <j_k9> tstone2077: Thanks for joining! I'll post up the log later.
Oct 16 03:34:24 ←- tstone2077 has quit (“Page closed”)
Oct 16 03:34:44 <clsk> j_k9: Right now the P2P network code is separated from the client regular network code
Oct 16 03:35:05 <clsk> either way, the client needs to know the difference between a peer and the server
Oct 16 03:35:13 <j_k9> clsk: My worry is that the GUI interface isn't yet capable of supporting one network interface, let alone two
Oct 16 03:35:26 <j_k9> But all in good time, I suppose?
Oct 16 03:35:33 <clsk> hm what do you mean?
Oct 16 03:36:01 <clsk> actually, the way I plan it, the modifications to the GUI should be minimal
Oct 16 03:36:03 <j_k9> Well, it might be difficult to distinguish between standard Client-Server mode and P2P mode.
Oct 16 03:36:29 <clsk> also, we might have to make sure use Mira in either mode, but not both at the same time
Oct 16 03:36:37 <clsk> at least at the beginning
Oct 16 03:36:52 <clsk> but there are more things I'm thinking/designing
Oct 16 03:37:01 <j_k9> We also need to consider that we'll need a P2P interface for Client-Client interaction with the normal set-up (i.e. Client-Server which allows Clients to share data directly)
Oct 16 03:37:01 <clsk> when I have something concrete I'll post a proposal to the list
Oct 16 03:37:09 <clsk> I'll probably create a blueprint to start working on it
Oct 16 03:37:13 <j_k9> We don't want to mix those two P2P systems: the internet one and the LAN one
Oct 16 03:37:15 <clsk> yea
Oct 16 03:37:19 <clsk> I've been thinking about this
Oct 16 03:37:42 <clsk> j_k9: Maybe we do ;) I'll explain more in detail when I post to the list
Oct 16 03:37:57 <j_k9> clsk: You're the coder! I'll leave this to you :)
Oct 16 03:38:05 <clsk> We might even have server be peers
Oct 16 03:38:14 <clsk> but I still need to think this over some more
Oct 16 03:38:20 <clsk> I haven't had much time to think about it
Oct 16 03:38:29 <clsk> servers*
Oct 16 03:38:42 <clsk> o
Oct 16 03:38:43 <clsk> ok
Oct 16 03:38:54 <clsk> what do you think about having built-in utilities?
Oct 16 03:38:58 <neeraj> how will the P2P connectivity work?
Oct 16 03:39:58 <j_k9> clsk: I think the default Utilities should be built-in (i.e. should come with Mira Client/Server on installation). For now, the easiest one to implement is probably Notes.
Oct 16 03:40:36 <neeraj> or Alan you are assuming it working and you will build on top?
Oct 16 03:41:12 <clsk> I'm sorry had a call from work
Oct 16 03:41:35 <clsk> neeraj: for on-the-LAN computers, I have service-discovery working on linux
Oct 16 03:41:51 <clsk> I plan to implement it on Windows and Mac OS X with Apple's Bonjour library
Oct 16 03:42:06 <neeraj> for lan there should be no problem
Oct 16 03:42:14 <clsk> right now peers can discover and connect to eachother
Oct 16 03:42:40 <clsk> hm I don't think I understand your question really
Oct 16 03:43:02 <clsk> j_k9: What I mean by built-in is that they're not plug-ins. They're integrated in the main code
Oct 16 03:43:06 <neeraj> Were we not wanting to it work over two different lans?
Oct 16 03:43:18 <clsk> hm what?
Oct 16 03:43:31 <clsk> I still don't understand, I'm sorry
Oct 16 03:43:43 <clsk> can you explain?
Oct 16 03:44:21 <j_k9> neeraj: Not really. The point was that we need two P2P interfaces: one which allows Clients to connect to each other over the internet (because they're both connected to the same Mira Server), and another P2P interface which allows Clients on a LAN to connect to each other without a server (this is the service discovery that Alan is talking about).
Oct 16 03:44:25 <j_k9> Does that make sense?
Oct 16 03:45:14 <neeraj> oh ok
Oct 16 03:45:37 <j_k9> clsk: Hmm, is there a need to do that - to integrate our own Utilities directly into the code? Wouldn't it be better to have all the Utilities operate via the same plug-in interface, even if they're distributed with Mira instead of by third-parties?
Oct 16 03:45:57 <neeraj> sorry Alan I was talking about the Client to Client (P2P)
Oct 16 03:46:29 <clsk> J-k9: It would be, but right now we don't have any plugin code in trunk
Oct 16 03:46:58 <clsk> actually we won't really be able to work on a plugin API, until everything else internally is done
Oct 16 03:47:21 <clsk> because we can't have an external API, when we don't even have an internal API
Oct 16 03:47:27 <j_k9> clsk: That's true. Would it be worth creating one or two simple Utilities (e.g. Notes and Discussion) and having them inbuilt for now?
Oct 16 03:47:33 <clsk> maybe if only for now, just as proof of concept
Oct 16 03:47:45 <clsk> yea
Oct 16 03:48:00 <clsk> although, it's not like it would be a waste
Oct 16 03:48:07 <clsk> we could always port the code to use the plugin interface
Oct 16 03:48:26 <clsk> either way, it will work to see what internal stuff the Utilities are really going to need
Oct 16 03:48:27 <j_k9> Exactly, and in the meantime we could use it to test the Clients' ability to communicate with each other and via a Server
Oct 16 03:48:53 <clsk> I think for up to beta version we should probably do basic utilities built-in
Oct 16 03:49:08 <clsk> or maybe Alpha actually
Oct 16 03:49:49 <clsk> I think beta would be marked by transitioning fully to plugin-based utilities
Oct 16 03:50:11 <j_k9> Ok. It would be nice to know how Stefan's plug-in code is progressing, but I'll ask him to push that to a personal branch and hopefully we'll be able to see for ourselves. I don't think the plug-in interface is an easy task, to be honest…
Oct 16 03:50:29 <clsk> well
Oct 16 03:50:35 <clsk> he can't really develop an interface yet
Oct 16 03:50:57 <clsk> he can get plugins to work, as in… load external symbols, etc…
Oct 16 03:51:10 <j_k9> We don't even have a Storage layer to support it, do we? Without that, how is a Utility expected to store data.
Oct 16 03:51:16 <clsk> but we won't be able to have a stable API until everything internal is stable
Oct 16 03:51:32 <clsk> my point :)
Oct 16 03:51:46 <j_k9> Right, I get it now. :)
Oct 16 03:52:11 * clsk wonders what the Storage layer was really supposed to do
Oct 16 03:52:24 <j_k9> In that case, yes, I think we should have a couple of basic Utilities built into the platform for now, at least until we can support a fully functional plug-in system.
Oct 16 03:53:28 <clsk> I've really been away from Mira for a while
Oct 16 03:53:40 <j_k9> Isn't the purpose of the Storage layer to allow Utilities to store data in different ways? Some might need direct access to the filesystem (e.g. the Files Utility), whereas others might just need access to a database (e.g. a DBMS or XML file)
Oct 16 03:53:43 <clsk> I was thinking we said the storage layer was going to be a utility
Oct 16 03:53:54 <clsk> yep, just realized this
Oct 16 03:54:34 <j_k9> Very basic blueprint here: http://miragroupware.org/wiki/doku.php/development/blueprints/layers/storage
Oct 16 03:54:41 <clsk> yep
Oct 16 03:54:44 <clsk> just went over that
Oct 16 03:54:57 <j_k9> Ah, ok. :)
Oct 16 03:55:09 <clsk> I've forgotten some of the stuff we've discussed before
Oct 16 03:55:49 <clsk> hm I'm thinking wether we should make it a utility or leave it as an actual layer
Oct 16 03:56:09 <clsk> if utilities will have some way of communicating with each other
Oct 16 03:56:43 <j_k9> Hmm… I think it's better as an independent layer below the Utility layer, don't you think?
Oct 16 03:56:58 <clsk> yea
Oct 16 03:56:59 <clsk> probabluy
Oct 16 03:57:03 <clsk> probably*
Oct 16 03:57:50 <clsk> yea
Oct 16 03:57:56 <clsk> it should
Oct 16 03:58:07 <neeraj> I think I got lost
Oct 16 03:58:09 <j_k9> Ok. So this is something that will need to be worked on - creating one or two simple Utilities and embedding them in the code (for now).
Oct 16 03:58:16 <neeraj> sorry for interrupting
Oct 16 03:59:24 <neeraj> 'What is utility need for?
Oct 16 03:59:36 <j_k9> That's ok, neeraj: we're talking about the Storage layer. This layer allows the Utility layer to store data on the Client or Server. For example, the Notes Utility would need to store text, right? In order to store or access this text, it needs to call a function in the Storage layer which uses the appropriate backend to find the data.
Oct 16 03:59:49 <clsk> but version-controled files is an utility too
Oct 16 04:00:13 <clsk> so it's kinda confusing have it as a layer, and as a utility
Oct 16 04:00:21 <clsk> the layer should be the general idea
Oct 16 04:00:38 <j_k9> clsk: It is a Utility, but wouldn't it just use the version control Storage backend? What if another Utility wants to use version control, for example?
Oct 16 04:00:42 <clsk> and the utility will be the separate high-level implementations I guess
Oct 16 04:00:48 <clsk> yea
Oct 16 04:00:54 <clsk> that makes sense
Oct 16 04:00:55 <j_k9> e.g. say we wanted to have version control in Notes.
Oct 16 04:00:56 <clsk> I guess
Oct 16 04:01:31 <j_k9> Ok. Neeraj, is that clearer?
Oct 16 04:01:34 <clsk> also, we could have the layer decide how to move data around depending on wether working on a P2P workspace or a client-server on
Oct 16 04:01:38 <neeraj> better
Oct 16 04:02:19 <neeraj> so utility is like a derived class
Oct 16 04:02:34 <clsk> no
Oct 16 04:02:37 <neeraj> and it could be based out from the other stuff like versioning
Oct 16 04:02:40 <clsk> neeraj: utility is a plugin
Oct 16 04:02:54 <j_k9> clsk: That's something we'll need to discuss when you propose your system. Having a LAN P2P discovery mode adds another side to everything :)
Oct 16 04:03:07 <clsk> yea, it does
Oct 16 04:03:17 <clsk> should we move on to another topic?
Oct 16 04:03:20 <clsk> I think we have two more
Oct 16 04:03:32 <clsk> this has been a long meeting
Oct 16 04:04:01 <j_k9> neeraj: Take a look here: http://miragroupware.org/mockups/ You see the items on the left, Notes, Files, etc.? Those are all Utilities. Each allows users to do different things in a Workplace. They are, as Alan said, just like plug-ins.
Oct 16 04:04:10 <j_k9> This has been a very long meeting indeed!
Oct 16 04:04:30 <clsk> I'm going straight to sleep after this
Oct 16 04:04:44 <clsk> so..
Oct 16 04:04:45 <clsk> - Discuss about using existing technologies for some utilities (bzr or git for Files, akonadi for (mail & calendar), Discussions (Google Wave kind-of-thing?))
Oct 16 04:04:49 <j_k9> Likewise. It's 4am here..
Oct 16 04:04:58 <clsk> for files I guess that's storage layer
Oct 16 04:05:20 <clsk> I was looking at using bzr for the version-control stuff
Oct 16 04:05:22 <j_k9> For Files it would be the Filesystem backend of the Storage layer, yes.
Oct 16 04:05:25 <clsk> I have to do more research on it
Oct 16 04:05:43 <clsk> either bzr or git
Oct 16 04:05:49 <clsk> they both have external APIs
Oct 16 04:06:02 <clsk> only problem with bzr is that it's a python API.
Oct 16 04:06:05 <j_k9> Version control is more complicated though. We should leave that for a much later release and focus on Filesystem and Database(/Plaintext) backends for now, IMHO
Oct 16 04:06:10 <clsk> but, maybe we could use Boost.Python for it
Oct 16 04:06:28 <clsk> yea
Oct 16 04:06:38 <clsk> version-control is the really interesting stuff though :)
Oct 16 04:06:55 <j_k9> Because version control is really only needed mainly for a version controlled Files Utility (and maybe some other specialist Utilities)
Oct 16 04:06:56 <clsk> but yea, I'd work on the file system and database backends first
Oct 16 04:07:10 <clsk> to get the interface going at least
Oct 16 04:07:31 <neeraj> we can always add up stuff
Oct 16 04:07:46 <clsk> but those are the things that are going to “sell” mira
Oct 16 04:07:48 <j_k9> Exactly. We don't need to do everything at the beginning - baby steps. :)
Oct 16 04:07:57 <neeraj> it works well as you say Alan getting the Plain file and db first
Oct 16 04:08:15 <clsk> j_k9: I don't know if you remember the guy from India that was developing something like what we want Mira to be.
Oct 16 04:08:33 <j_k9> Yes, the one from the forum who was developing Collaber in Java?
Oct 16 04:08:36 <clsk> his product is out there, and it actually looks nice. Except it's written in java and is probably slow as..
Oct 16 04:08:39 <clsk> yea
Oct 16 04:09:00 <j_k9> I've tried it. It does the job, but it's got a bad interface and it's slow.
Oct 16 04:09:11 <clsk> yea I kinda figured it would be
Oct 16 04:09:17 <clsk> Java leads to both of those for some reason
Oct 16 04:09:21 <j_k9> It's actually a really good effort… But a C++ version, like Mira, will be better.
Oct 16 04:09:41 <clsk> not sure why Java always leads to bad interfaces
Oct 16 04:10:02 <clsk> but really, I like to innovate
Oct 16 04:10:07 <j_k9> I really like what we've got at the moment. Thurston did a good job with it.
Oct 16 04:10:19 <clsk> push something out that hasn't been done yet. That's what's going to get the project popular
Oct 16 04:10:24 <clsk> yea, I agree
Oct 16 04:10:30 <clsk> it seems like he did really quick too
Oct 16 04:10:41 <clsk> He migrated from wxWindows to Qt in a matter of a few weeks
Oct 16 04:10:56 <clsk> he seems to be really good at it, and he said he liked Qt too
Oct 16 04:11:37 <j_k9> I know, pretty impressive stuff. He's obviously good at Qt, so if he's interested in working on the GUI (which he said he is) it'll be good to have him updating the GUI while the code below it is upgraded.
Oct 16 04:11:52 <clsk> It didn't seem like he did it really quick…. He did it really quick
Oct 16 04:12:04 <clsk> yep
Oct 16 04:12:18 <clsk> for the mail stuff
Oct 16 04:12:29 <clsk> I don't think we've talked about “personal utilities”
Oct 16 04:12:44 <clsk> utilities that the client has, but are not distributed across the network
Oct 16 04:12:49 <clsk> like a mail utility would be nice
Oct 16 04:13:08 <clsk> and a “local” calendar utility that can communicate with a workspace calendar would be nice too
Oct 16 04:13:28 <clsk> either way, I think Akonadi would be a great backend for that
Oct 16 04:13:38 <clsk> but that would probably would be for a 1.0 or 2.0 release
Oct 16 04:13:50 <j_k9> Do you think that is a good idea though? I like programs that do one job and do it well. I wouldn't want to have email getting confused with a private system, but I do see the interest that there might be in what you're suggesting.
Oct 16 04:14:01 <j_k9> It's definitely something we should think about for a future .0 release.
Oct 16 04:15:02 <clsk> well normally mail and calendar are the basis of groupware software
Oct 16 04:15:17 <clsk> because a lot of communication is done through those
Oct 16 04:15:26 <clsk> meetings are scheduled through calendars
Oct 16 04:15:36 <clsk> and email is definitely still being used nowdays
Oct 16 04:15:46 <clsk> so why not integrate it with our system.
Oct 16 04:15:58 <clsk> we're not re-inventing it, we're just integrating it with our system
Oct 16 04:16:03 <j_k9> That's a very good point. I see the value in that.
Oct 16 04:16:25 <neeraj> maybe we need a priority list
Oct 16 04:16:30 <j_k9> Then again, it's probably something for 2.0 or 3.0, but an interesting point nonetheless.
Oct 16 04:16:41 <clsk> and with Akonadi it should be easy to do the backend stuff. We'd still need to work on the front-end (the GUI) for it.
Oct 16 04:16:41 <clsk> yea
Oct 16 04:16:51 <clsk> if we do end-up using akonadi
Oct 16 04:16:54 <clsk> it's just a suggestion
Oct 16 04:16:59 <clsk> yep
Oct 16 04:17:04 <clsk> that's definitely far from now
Oct 16 04:17:57 <j_k9> It was worth raising, though. Shall we move on to the last topic?
Oct 16 04:18:43 <clsk> sure
Oct 16 04:18:50 <j_k9> The final topic is icons. The ones used in the mock-ups are http://www.famfamfam.com/lab/icons/silk/ but I could make any extra graphics required myself. Is there anything you had in mind?
Oct 16 04:19:25 <clsk> nop
Oct 16 04:19:35 <clsk> not really
Oct 16 04:19:45 <clsk> I think I did, but I can't remember
Oct 16 04:19:57 <clsk> I'm sure there will be something in Silk for it though
Oct 16 04:20:06 <j_k9> Silk has just about everything. :)
Oct 16 04:20:46 <j_k9> Does anyone have any points to raise? clsk, neeraj?
Oct 16 04:20:48 <clsk> we should probably remember to give credit to the guy
Oct 16 04:21:02 <clsk> yes
Oct 16 04:21:04 <j_k9> Good point. We'll need an 'About Mira' dialog at some point.
Oct 16 04:21:04 <clsk> one more thing
Oct 16 04:21:06 <j_k9> ok
Oct 16 04:21:11 <clsk> there is one
Oct 16 04:21:16 <clsk> in the GUI
Oct 16 04:21:19 <clsk> we just have to add that
Oct 16 04:21:22 <j_k9> Ah, even better. :)
Oct 16 04:21:23 <clsk> either way
Oct 16 04:21:45 <clsk> can we delete all the people that have never contributed anything to the project from the wiki and the launchpad site?
Oct 16 04:21:52 <j_k9> Of course.
Oct 16 04:22:15 <neeraj> :D
Oct 16 04:22:17 <clsk> there's a bunch of “developers” in our pages
Oct 16 04:22:19 <j_k9> They're irrelevant, so we can just remove them.
Oct 16 04:22:48 <j_k9> People who haven't said anything in months. Yes, I'll do that. :)
Oct 16 04:22:57 <clsk> really the only ones there should be (I think): Thurston, you, Neeraj, Shilpa, Sibta, and I
Oct 16 04:23:00 <clsk> and Daryl as a past developer
Oct 16 04:23:21 <clsk> who is Sibta? I know he submitted a patch to trunk
Oct 16 04:23:29 <j_k9> And Stefan
Oct 16 04:23:29 <clsk> Can't remember seeing him on the mailing list though
Oct 16 04:23:41 <clsk> hm sure Stefan too
Oct 16 04:23:50 <j_k9> Sibte can't come back to us at the moment - I'll forward you his email.
Oct 16 04:24:14 <clsk> on Sibte
Oct 16 04:24:14 <clsk> sorry
Oct 16 04:24:20 <clsk> that's ok. I was just wondering
Oct 16 04:24:36 <clsk> the patch he posted fixed a real bug, so at least he did do something
Oct 16 04:25:03 <clsk> btw, here's a quote I read earlier from kdeplanet.org that I wanted to share
Oct 16 04:25:32 <clsk> “Of course, KDE is a project that thrives because it is people doing rather than people just talking”
Oct 16 04:25:40 <clsk> the whole post is rather irrelevant, but that part is.
Oct 16 04:25:53 <j_k9> I think that's something we definitely need to take on board. :)
Oct 16 04:26:02 <clsk> yea
Oct 16 04:26:34 <clsk> A lot of people have talked a lot in the list, but haven't really done anything with the exception of the people I mentioned earlier
Oct 16 04:26:44 <clsk> not sure, but it's been the case
Oct 16 04:26:56 <clsk> that's all I've got :)
Oct 16 04:26:58 <j_k9> neeraj, if you feel a little left out at the moment it's because you haven't had a chance to really immerse yourself in the project. Don't worry - we'll try to give you more guidance this time so that you really can start working on the Directory layer yourself.
Oct 16 04:27:25 <neeraj> sure np
Oct 16 04:27:29 <j_k9> Thanks clsk. :)
Oct 16 04:27:48 <clsk> yep
Oct 16 04:28:10 <clsk> Neeraj: let me know when you want to start working on the design for the directory layer
Oct 16 04:28:25 <clsk> or if you want to do it over email/mailing-list that's fine too
Discussion