* ChanServ hat das Thema geändert zu: Fedora Robotics SIG Meeting 2010-11-10
[...]
<timn> http://www.crunchgear.com/2010/11/10/kinect-hacked-open-source-drivers-now-working/
<timn> Another very interesting piece of robot hardware :-)
<rmattes> I agree, I ordered one this morning
<timn> Yeah, we got some in the office.
<timn> I'm going to give it a try tomorrow.
<rmattes> I was looking over the driver this afternoon, it's fairly simple.  I'm going to try to write a Player driver for it this weekend
<timn> It's unfortunate primesense does not sell the prototype package. It has a much better form factor.
<rmattes> They've probably got some kind of exclusivity contract with Microsoft
<timn> I guess the SwissRanger guys will be shocked by this thing. Just 150 bucks and from first impression easily as good as the SR4000 data.
<rmattes> I know... the SR4000 is insanely expensive
<rmattes> by almost 2 orders of magnitude
<timn> Yip. I got to play with one (only shortly, was while learning for exams). The data is good, but not 4000 $$ more expensive good.
<rmattes> agreed.  I'm wondering if I can get the Kinect working on my BeagleBoard.
<rmattes> I've been working with the ARM SIG for the past few weeks trying to get a working Fedora 13 on the ARM architecture
<timn> Cool stuff. I had applied to BeagleBoard for Google SoC, but then I got the position here. Did you do any robotics projects on the board?
<rmattes> Yeah, we have a BeagleBoard on one of our ground robots that handles position and power stuff
<timn> Position stuff as in localization?
<rmattes> It handles bringing up the motor controller and arbitrating motor commands, as well as managing all of the power to the rest of the sensors and subsystems.
<rmattes> Our localization scheme is mostly GPS based, it could probably handle that without much issue
<timn> Wow, having a Fedora on such a thing would be really cool. No more dealing with some specific Linux distro for a single machine on the robot.
<timn> Have you played with the BB-XM?
<rmattes> Yeah, I'm actually loading Fedora on an SD card for one now
<timn> Awesome. Is the repo etc already up, or is it still WiP?
<rmattes> There's a Fedora 12 repo that's been up for a while,
<rmattes> The ARM SIG just got a koji buildfarm up and running for F13 on at arm.koji.fedoraproject.org, it looks like they're also catching up on updates for f12
<rmattes> And in the meantime I used my repos.fedorapeople.org space to host Player and Gearbox rpms for ARM
<timn> How do you build for ARM using fedpkg/koji?
<rmattes> there should be an "arm-koji" script installed with fedpkg
<rmattes> http://fedoraproject.org/wiki/Architectures/ARM/Package_Maintainers
<timn> Ah, I see. Comes with fedora-packager. Are they going straight to F-14 or will they stay on F-13 for a while?
<rmattes> I think the goal is to catch up with F13
<rmattes> They were stuck on F13 glibc-2.12 for a while, but a build finally succeeded over the weekend so the koji has been building nonstop since then
<timn> Hehe. How many beagleboard make up the Fedora build farm?
<rmattes> Looks like just one or two, it's mostly the Marvell guruplugs
<rmattes> http://zenit.senecac.on.ca/wiki/index.php/Fedora_ARM_Secondary_Architecture/ARM_hardware
<timn> Interesting. Didn't realize there was such an ARM project for Fedora.
* hedayat (~hedayat@fedora/hedayatvk) hat #fedora-robotics betreten
<hedayat> Hi!
<timn> Hi Hedayat.
<rmattes> Hi
<timn> Hope you have a good cup of coffee with you :-)
<hedayat> :D
<hedayat> Well, there are some tea
<timn> Even better.
<hedayat> :)
<timn> Ok, I'd say let's go step by step through the agenda Rich put up on the wiki (http://fedoraproject.org/wiki/SIGs/Robotics/Meetings)
<timn> *** Package Reviews/Outstanding Tasks/Interesting Software 
<timn> ****** Package Reviews/Outstanding Tasks/Interesting Software ******
<timn> (making it obvious for the log later on)
<rmattes> Alright
<timn> So, for my understanding for a basic demo we have the basic building blocks in place: Fawkes, Player, Stage (from top to bottom).
<timn> What remains is a demo package, which ties it all together in an easy-to-use package.
<hedayat> aha
<timn> Hedayat, this does not include your soccer server package. I envision a home service robot scenario rather than robot soccer atm. I think most people can easier connect to this. Would you be ok with that?
<hedayat> Yeah, certainly
<timn> rmattes: agreed on the general setting?
<hedayat> In fact, I've no idea what an interesting demo can be made for rcss
<hedayat> as it's mostly competition oriented
<rmattes> I think a Fawkes/Player/Stage solution is a good idea
<hedayat> I agree
<rmattes> We have to be careful about creating one-off packages I think, I don't know if the spin guidelines will allow it
<timn> Agreed. Though it might be interesting for a later scenario. But let's worry about that once we got the first demo and LiveCD in place.
<timn> I imagine an application that we stack on top of Fawkes, and I'm interested in hosting an upstream for it. It'll make a great introduction to Fawkes and Player/Stage.
<rmattes> Indeed, I'm also imagining a set of tutorials in an easy language like Python that can drive a robot around in Stage
<hedayat> Yes, having an upstream is much better
<rmattes> Also, I am Player's upstream, and Tim is Fawkes' upstream
<rmattes> This gives us a lot of latitude in terms of including tutorial and demo software in the packages
<hedayat> :D Nice to see how much 'upstream' people we have
<timn> Indeed.
<hedayat> Great
<timn> So, assuming that we have the basic packages in place, I'd say we assign the task list towards the end of the meeting, and skip re-evaluating the interesting software list for now. Agreed?
<rmattes> Yeah, I agree that the interesting software list is not so important at the moment
<rmattes> I did rearrange it a little bit as I outlined earlier this week, but we now have enough packages to do something more interesting
<hedayat> Agreed
<timn> Then I think we can go to the next topic.
<timn> ****** Tutorials/Documentation ******
<timn> A crucial question here is, if we can agree on a single demo application for the whole stack as the main eye catcher, or if we should have multiple such apps, specific for the particular framework/software they endorse.
<hedayat> Well, how many demos are readily available? If I know correctly, almost nothing.
<hedayat> So, if we are going to have a demo, probably investing on a single demo is better
<rmattes> Player has a series of c++ example programs that escalate in difficulty
<timn> From last time I looked these are more targetted towards roboticists evaluating Player for use.
<rmattes> Right, that's kind of the image I have in my mind though: a series of tutorials that grow in complexity that do something like connect to Player and move a robot around
<timn> The main audience I see is people seeing robotics as "cool", and having a first look. Or students that start diving into robotics.
<rmattes> I'm not really sure what kind of application we can design that can cater to them: maybe something like PlayerNav running and PlayerV showing laser data?
<timn> I see. That's why I stated the initial question. In my favored scenario, the Fawkes Lua environment is used, and the framework, Player, and Stage act as "backend", and probably display (Stage)
<timn> You get a command-line like interface for the start (which we also have a GUI for). You have commands like "goto{place=...}" or "close_gripper()".
<timn> Initially, this could be made buttons. The increasing complexity also involves getting used to typing commands, and eventually writing programs making the robot perform more complex tasks.
<rmattes> Alright, I see what you're getting at
<timn> So within on particular GUI, we have the increasing complexity.
<rmattes> That's basically what I was thinking with the Python stuff, but Fawkes looks a lot more polished
<timn> I understand the delicacy about this, because we also want to present Player in a shining light, which may not be as obvious if we go through Fawkes.
<rmattes> The act of launching Player alone will definitely bring it a lot of attention :/
<timn> That's why I asked, if we can agree on such a stack, and come up with something that presents all components to satisfaction. Or if we feel that we should have multiple "tracks" of demos/levels/tasks/applications.
<rmattes> I'd like to eventually end up with multiple tracks, since the different frameworks do have different advantages and disadvantages
<timn> The former case is more streamlined, and in my opinion more attractive. The second option would need an introductory explanation giving hints to the user to make a decision for one or the other (or doing them in sequence, of course)
<rmattes> We could take the video game approach: bring the user in with a straightforward linear track, and once they accomplish that, present them with various steps forward
<timn> About starting launching stuff: for the demo I envision, the GUI app will do everything of that for you. It will (for the start) be your only interaction point.
<rmattes> That's do-able
<timn> Sounds like a good middle way. How would we do that? I mean, what is the linear track? The full-stack demo? And from after this tell the user "Look, you now used A for ..., B for ..., and C for .... If you want to dive deeper, please choose a A, B, or C"?
<rmattes> Well basically we start with your idea, a GUI that buttons for "Move robot here" and escalates into scripting a small program for the robot
<rmattes> Then once that's done, have a collection of other tutorials in different areas of interest and let the user choose what to do next
<timn> Ok, and then we have the option screen you proposed after say 5 levels or so?
<timn> Sounds good.
<rmattes> Right
<hedayat> Yes, I do also think that everything is not necessarily linear
<timn> Summary: a few levels linear, involving the whole stack. Then fan out and provide user further tutorial options.
<hedayat> I think that the last screen/page should present most notable robotics software in the DVD
<hedayat> including rcssservers :P
<hedayat> and usable libraries: e.g. MRPT
<rmattes> Things like MRPT are quite difficult to use
<rmattes> At least they are if you're not familiar with C++
<timn> That's a good idea. We would likely put the member favorites further up, as we have more insight and documentation.
<hedayat> Yes, this is why is put them for the last screen to just show off what we provide
<hedayat> ?!
<rmattes> Ah alright
<timn> We provide the options, favoring what we know more about, can present more, and can actually prepare further documentation.
<rmattes> I think some kind of wiki would be a good idea for the documentation stuff
<timn> Indeed.
<hedayat> yes, I think it is nice to have an eye on more professional people too
<timn> Is there some offline-wiki that we could bundle with it, or do we require web access?
<rmattes> Maybe we can do it in Doxygen
<timn> You think so? We use it, but only because there is nothing better. I find it horrible.
<hedayat> hmmm... not completely sure but I think there should be some offline-wiki software
<rmattes> Well, we already have stuff like http://playerstage.sourceforge.net/doc/Player-svn/player/group__tutorials.html
<rmattes> Most of that is sorely out of date, or just stubs that say "TODO"
<rmattes> And all of it is also in the player-doc package
<hedayat> zim?
<timn> That doesn't look to bad. If there were an offline-wiki app and it didn't suck I'd prefer it. But that really doesn't look bad.
<timn> hedayat: about the more professional people. I'd say having a LiveCD that you can run and then have the frameworks and libs at your hands is already a giant leap forward.
<rmattes> And it'd be really easy to embed gtk-webkit in our "app" and host those local pages
<rmattes> timn: You're absolutely right.  There was much clamoring on the Player mailing lists for a livecd loaded with Player that people could experiment with
<timn> I thought about that the other day to embed the Fawkes webinterface. But the C++ bindings were in a horrible state at that time. Maybe I should try again.
<timn> I just want to be able to give the CD to students during lab courses and say: look, run the CD, it's got all you need, run ... and you're set.
<hedayat> @timn: Yeah I agree. I wanted to say that we can have a small presentation for them too
<timn> (and quietly: I don't care about put-the-most-obscure-Linux-derivate-you-know-of-here, use the LiveCD)
<hedayat> :)
<timn> hedayat: right. We probably should have a shortcut to the "further documentation/tutorial" screen.
<hedayat> nice
<timn> Good. So we have the basic plan in shape:
<timn> - have a linear demo of a couple of levels based on Fawkes/Player/Stage
<timn> - afterwards provide links to more in-depth tutorials of the different components and robotics software in general
<timn> - provide a shortcut to that link list for advanced users
<rmattes> Right..and pointers to the library documentation for lower-level stuff
<timn> Right.
<timn> So let's go further through the list, coming back later to this for the task assignment.
<rmattes> Alright
<hedayat> OK
<timn> ****** LiveCD spin ******
<timn> Reading quickly over the LiveCD spin, what we need to do is get everything in place in Fedora so you can yum install it.
<timn> Then write a proposal and kickstart file and apply to the Spins SIG
<rmattes> And also register a F15 feature
<hedayat> Probably the kickstart file should be easy
<hedayat> I don't think that we would have anything special in it
<rmattes> Do we want to have -devel packages?
<rmattes> and things like Eclipse?
<timn> Yes, so we have two things: create a Fedora feature, and a "Spin in development"
<hedayat> I consider the above plan the biggest part of the effort
<hedayat> rmattes: I think so
<hedayat> And it'll surely be larger than a CD
<hedayat> as mentioned before
<rmattes> With that stuff we're probably going to have to target a 1GB USB stick
<timn> I definitely want to have the -devel stuff on their. Eclipse is fine with me if it fits. But I damn sure want to have an Emacs :-)
<hedayat> :)
<rmattes> Oh dear...
<timn> Spins must either fit a CD, or a DVD. I think we clearly go for the DVD.
<rmattes> DVD works...we'll have plenty of leeway
<hedayat> The negative point above a liveDVD is that it'll install the whole stuff on installation
<hedayat> which will take a large space
<timn> Yeah, but I rather have everything required to get people going to install, and don't worry about the package footprint, then having to byte-squeeze besides all the other stuff.
<timn> Because then the kickstart file _would_ become work again.
<timn> So I'd trade convenience and completeness over space and install time
<hedayat> OK
<rmattes> I agree with that
<timn> So, to summarize this:
<timn> - Prepare everything the usual Fedora way, get packages in
<timn> - Create a Spin in development proposal to update while we go
<timn> - Create a kickstart file to be able to generate and test spins
<timn> - Create a Fedora 15 feature: Robotics Spin (mostly to gain more attraction on release)
<timn> - have robotics packages and development environment on the disk
<timn> That's it I think.
<hedayat> I do too
<rmattes> Sounds good to me...we should probably break some of it down into action items per person so we all know what we have to do
<rmattes> We can save that for the end
<timn> Yes, I'm noting action items while we go and will summarize them in the end and then we can fight for the bait
<rmattes> Great
<timn> Next:
<timn> ****** Blogging/Planet Fedora ******
<timn> So the ideas are fedora-robotics blog and/or more individual robotics related blog entries.
<rmattes> I've been hanging out on Planet Fedora recently, and I think we can gain expoure with periodic updates about what we're doing
<hedayat> hmmm
<timn> Yes, posts to the Fedora planet got it all started after all.
<rmattes> And stuff we're doing anyway applies because A) it's all blogs and B) We're all using Fedora anyway
<timn> I fear that for a dedicated fedora-robotics blog we are not enough people (and I'm certainly not a frequent poster anyway), so it might look deadish or deserted.
<rmattes> So after I spend 3 hours bashing my head against the wall getting D-Star up and and running, I can post pretty pictures and a summary of what I just did
<timn> Yeah, indeed!
<rmattes> (That's what I did Monday night :/ )
<timn> I could report a little about the stuff I'm doing here at Intel, and I just pushed a video of a talk I gave online.
<timn> But I hope you got the Eureka! moment and had it.
<timn> hedayat: do you have a blog on Fedora planet?
<hedayat> I can post about what I do at RCSS
<hedayat> yes I do
<hedayat> but I've not written much about robotics there
<rmattes> timn: I did have a eureka moment, but it was while i was taking a shower the next day
<hedayat> hmmm I can do more
<hedayat> specially as this year I'm in RoboCup OC
<rmattes> I've been working on a software stack to compete in the IGVC competition next summer
<hedayat> and this is the year of Fedora in RoboCup 3D simulation
<hedayat> :D
<hedayat> If the spin is available soon enough, it'll be the distribution of choice for 2011 competitions
<timn> rmattes: yeah, shower is the best place for ideas and revelations. I think it's because senses are busy with boring stuff (seeing shower curtain, smelling and feeling water), so processing power can go to more interesting stuff.
<hedayat> :)
<rmattes> Agreed.
<timn> Ok, seems we agree that we will not have an explicit blog, but rather boost our writing efforts aggregated on fpo
<rmattes> And maybe throw in some 'shout-outs' to the Robotics SIG ;)
<rmattes> Grassroots, if you will
<timn> Yeah. I really hope we can get some more people on the SIG once we get things rolling.
<timn> Good, on to:
<timn> ****** Wiki Page ******
<rmattes> So I think I outlined this in the email rant I sent, but I see wiki/Robotics as a one-page showcase of why Fedora is the best distro for robotics, with links to how to learn more
<timn> So rmattes made several proposals for improvements to the wiki.
<timn> And I wholeheartedly agree
<hedayat> I do too
<timn> So what needs to happen to make it work, can you give a brief info about possible action items?
<rmattes> Basically, all I'll need is a paragraph or two about each software package, with a couple of screenshots of it in action
<rmattes> For example, I'll write a little article about what Player is, who uses it, why it's awesome, and how Fedora is the ideal environment for its use
<hedayat> :) Nice
<timn> Ok. Can we have a better layout in the Fedora wiki that is more space efficient, e.g. something like http://trac.fawkesrobotics.org with boxes?
<timn> And you wanted to contact the arts department or so for a header and stuff?
<rmattes> Yeah...again, I was looking more at http://spins.fedoraproject.org/fel/#portfolio as a model
<rmattes> Except with little blurbs instead of bullet lists
<timn> Wow, that looks good.
<rmattes> But we can do boxes: http://playerstage.sourceforge.net/wiki/Main_Page is an example
<timn> Ah, it's not a wiki page :-)
<rmattes> Right...that's part of the benefit of being a Spin :)
<timn> Ok. So what has to happen is that we write up something about our pet projects with a screenshot.
<rmattes> Yes.
<timn> Then a nicer wiki page is created, making it easier to find stuff.
<rmattes> I can handle Player and Stage
<timn> I'll do Fawkes.
<hedayat> And I'll do Rcss 2D/3D
<timn> For the remaining libs I'd say we make it a sentence or so and have them in a unified paragraph.
<timn> Basically the packages we do not specifically describe, urg, libphidget and what not.
<rmattes> Right, a sentence or two for each should suffice
<hedayat> nice
<timn> Ok, summary again:
<timn> - featured package descriptions and screenshots
<timn> Restructure wiki page (boxes?)
<timn> - brief overview of other libs
<timn> - possibly contact arts department now for nicer sig page, or for spin later
<timn> Anything else?
<rmattes> That about does it for now
<rmattes> We can add links later about how to get started with the LiveCD, etc
<timn> Good, I leave the regular meeting point for the very end, now let's go to
<timn> ****** Task Assignment ******
<timn> So I have noted:
<timn> - Feature Page
<timn> - Spin page
<timn> - Demo application
<timn> - Prepare advanced documentation overview
<timn> - blog more
<timn> - featured package descriptions and screenshots
<timn> - Restructure wiki page (boxes?)
<timn> I have started a feature page, so I will post a draft in my personal namespace for you to review.
<timn> The "blog more" is for us all
<rmattes> I can work on the robotics wiki pages; since I'm going to be writing the summaries for Player and Stage I can post them as a template for the rest
<timn> Good.
<hedayat> OK
<timn> You can take stuff from http://www.fawkesrobotics.org for the start, there are also screenshots, and I'll modify it from there.
<timn> I forgot:
<timn> - Spin kickstart
<rmattes> Ah, spin kickstart shouldn't be that hard
<rmattes> Maybe we should work on a package list on our Spin In Progress page before we get started with the kickstart
<timn> Agreed.
<hedayat> yes, if the package list is ready
<rmattes> Right.
<hedayat> the kickstart will not need much work
<timn> Ok, I'll setup the spin page, again as a draft for your review. It'll be brief for the start. The description will be most of it.
<rmattes> There's a template for spin pages somewhere, right?
<timn> Yes
<rmattes> Alright thought so.
<timn> The demo will be a big thing and involve quite some work. I will setup a repository that pulls in Fawkes and then we can go from there. How can we distribute that work on more shoulders?
<rmattes> I'm not really sure... Improving Player's stock documentation has long been on my to-do list to begin with, maybe I can spend some time writing tutorials there?
<timn> Yeah, I had hoped for some coding help. GUI apps always take so long.
<rmattes> I'm pretty useless when it comes to creating GUIs (at least outside of MATLAB)
<rmattes> I have been trying to learn pygtk in my limited free time
<timn> So the basic skeleton for such an application could be the graphical frontend we have for the scripting environment. But this does neither provide anything level-demo-like, nor yet a scripting interface to write large chunks of code.
<timn> Ok, I'm stuck with gtkmm atm.
<rmattes> I tried with gtkmm but could find no decent documentation
<rmattes> I'd much prefer to stay in C++ so I don't have to be learning Python at the same time
<timn> Maybe once I setup a start, you can chime in and have a look if you can join.
<timn> Ok, I'm all for C++.
<rmattes> I'm alright with that...we can set up a project on fedorahosted
<timn> Because otherwise it'll be tough to meet the deadlines with only me working on this.
<hedayat> Unfortunately I do not think that I can help much
<timn> Why not? You're writing on the soccer server. I bet you'll find it super easy to join just writing a demo :-)
<timn> OK, I can also setup a repo on git.fawkesrobotics.org. That's all we need, right?
<rmattes> Yup...we could even do github or something, the hosting location is immaterial
<hedayat> :) I'll try to join. My main consideration is the available time :P
<timn> We are all short on time anyway :-)
<hedayat> :) Yeah I know
<rmattes> That's why I'm leaning towards extending Player's documentation for now...it's something I work on anyway, it's not much of a stretch for me
<rmattes> And once my gtk-fu develops further, I want to do things like make PlayerCam, and PlayerV have connection dialogues so they don't just trigger ABRT when you launch them without Player
<timn> I understand. But in that case we might end up having to cut back to a pure "LiveCD full of robot software prepackaged".
<timn> We should try hard to make this a joint effort. For one to increase the bus factor, for the other to have a realistic chance of getting the work done in a mere two months.
<rmattes> I think that's an acceptable fallback position, but I do think I'll be able to help with this GUI stuff
<timn> hedayat, can you work on something for the documentation overview? Evaluate options for offline viewers or come up with something easily maintainable for the index page.
<hedayat> :) I'll try to help as much as possible too, but that won't be much
<hedayat> hmmmm I think so
<hedayat> But what do you mean about the index page?
<hedayat> what kind of maintainability are you refering to?
<hedayat> :P
<timn> The whatever-thing we show from where users can continue to more documentation.
<timn> It should be something visually appealing, probably repeating the package descriptions and screenshots for the favored stuff, and brief descriptions of the rest.
<timn> And we should aim for having that available offline on the LiveCD. So check for possible viewers, web browser is fine, evaluate if there are other options for viewers.
<hedayat> hmm OK, I'll probably will come back with some suggestions in the mailing list
<timn> Perfect, assigned :-)
<rmattes> Almost all of the packages I do come with html documentation
<rmattes> Even Fedora's release notes just bring up the web browser
<timn> Ok, so we should probably go with that.
<rmattes> (System->Documentation->Release Notes)
<timn> It's also easy to host a copy on the web
<hedayat> :P Nice!
<hedayat> Maybe this task is near to ending ;)
<timn> I'd prefer something lightweight, so not Firefox or so. It should start quickly and provide less GUI buzz than Firefox.
<hedayat> OK
<hedayat> I'll have a look around
<timn> You still need to get something cool for the index page.
<hedayat> :D yeah
<rmattes> Doesn't GNOME default to Epiphany?
<timn> I think looking appealing is key to get people to look further.
<timn> Maybe, don't know.
<rmattes> System->Help is basically a web browser
<timn> hedayat will figure it out
<rmattes> Jeez, maybe we can start with that!
<hedayat> :)
<rmattes> I guess the moral of the story is that we have lots of options
<timn> Yeah, hedayat, check it out!
<timn> Ok, regular meetings is one of the last things on the agenda.
<hedayat> OK
<timn> I'm all for it. I'd say biweekly should be doable by everybody on the one hand, and is frequent enough for the short time frame in which we want to get things done.
<rmattes> And we can coordinate informally on the mailing list for updates with our action items
<hedayat> For this release at least, I also agree
<timn> Yes, we should use the mailing list whenever something has happened, has been done, or needs attention.
<timn> We should really keep us informed, for me personally that is motivating to keep going.
<rmattes> Me too...I have terrible focus issues :/
<hedayat> OK
<hedayat> :D
<timn> Ok, let me give the summary (going to be some lines...)
<timn> ****** Summary ******
<timn> Decisions:
<timn> - do not focus on additional software to add for now
<timn> - have linear ~5 level demo using Fawkes/Player/Stage
<timn> - Afterwards present pointers to more in-depth information
<timn> - Provide shortcut to pointers for advanced users
<timn> - Make Robotics LiveCD a proper Spin
<timn> - Make Robotics LiveCD a Fedora 15 Feature
<timn> - Prepare spin (kickstart etc.) as we go
<timn> - Have development files and IDE on spin
<timn> - Blog more about robotics for Fedora Planet
<timn> - no specific fedora-robotics blog
<timn> - Restructure wiki, give pointers to software
<timn>  
<timn> Tasks:
<timn> - Feature Page (timn)
<timn> - Spin page (timn)
<timn> - Package list on spin page (all)
<timn> - Demo application (timn et al.)
<timn> - Prepare advanced documentation overview (hedayat)
<timn> - blog more (all)
<timn> - featured package descriptions and screenshots (rmattes)
<timn> - Restructure wiki page, possibly using boxes (rmattes)
<timn> - Spin kickstart (postponed)
<timn>  
<timn> That's it
<timn> Anything to add?
<rmattes> That looks good to me...anything we forgot we can bring up on the mailing list
<hedayat> :) I agree too
<timn> Good, I guess that concludes the meeting for today. Should we plan for Nov 24th for the next meeting? We probably need to find a better time?
<hedayat> Yeah, I think so
<hedayat> :D
<hedayat> :P
<rmattes> I'm much less likely to wake up at 4:30 in the morning :P
<hedayat> :)
<timn> So your offset to us is 8:30, which would limit us to mornings until early afternoon I guess. rmattes, are you available at that time?
<timn> I guess the following meetings will also be shorter again.
<rmattes> Yeah, I'm usually at work during that time but as long as I know in advacne I can make sure there's no work-type meetings
<timn> What about 10am EST, that's 15:00 UTC, so I think that's 18:30 in Iran?
<hedayat> Yes
<hedayat> That is fine for me
<rmattes> I can only do that Thursdays...I have a class at 10AM EST MWF, and usually a meeting Tuesdays around that time
<timn> Would work for me, hedayat?
<timn> Remember though that this will be the thanksgiving weekend (and Thursday)
<rmattes> I plan on taking off from work that entire week
<hedayat> Yes, that's OK with me
<timn> But you still have the class?
<rmattes> Good question
<rmattes> no
<rmattes> No classes thanksgiving week
<timn> Ok, so we could meet on Wednesday and avoid the holiday (I might make up plans for that as I'm leaving the states in a couple of weeks)
<rmattes> That's fine with me
<hedayat> me too
<timn> Good, Nov 24th 2010 15:00 UTC it is.
<hedayat> OK
<rmattes> Great!
<rmattes> timn: Will you post the minutes
<timn> Yes, I will right now (I still have the mini minutes from last time on my desktop)