Timestamps are in GMT/BST.
[0:33] * bradmc (~bradmc@c-66-30-9-86.hsd1.ma.comcast.net) Quit (Quit: bradmc)
[0:50] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[2:10] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[2:17] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[3:58] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[6:45] -card.freenode.net- *** Looking up your hostname...
[6:45] -card.freenode.net- *** Checking Ident
[6:45] -card.freenode.net- *** Found your hostname
[6:45] -card.freenode.net- *** No Ident response
[6:45] [frigg VERSION]
[6:45] * DuraLogBot (~PircBot@duraspace.org) has joined #duraspace
[6:45] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[6:45] * Set by cwilper on Tue Jun 30 20:32:05 UTC 2009
[9:05] * mboschini (c1ce9ca0@gateway/web/freenode/ip.193.206.156.160) has joined #duraspace
[10:47] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[11:35] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) has joined #duraspace
[11:40] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[11:43] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[11:49] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[12:23] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[12:30] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[13:30] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[14:23] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) Quit (Quit: Heading out...talk to you later.)
[14:23] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[15:04] * ksclarke (~kevin@adsl-39-10-103.clt.bellsouth.net) Quit (Ping timeout: 276 seconds)
[15:05] * mboschini (c1ce9ca0@gateway/web/freenode/ip.193.206.156.160) Quit (Quit: Page closed)
[15:26] * ksclarke (~kevin@adsl-39-10-103.clt.bellsouth.net) has joined #duraspace
[16:26] * tdonohue1 (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[16:26] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) Quit (Disconnected by services)
[16:27] * tdonohue1 is now known as tdonohue
[19:04] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) Quit (Quit: alxp)
[19:43] * jatrimble (~jtrimble@maag127.maag.ysu.edu) has joined #duraspace
[19:53] * snail (~stuart@130.195.179.88) has joined #duraspace
[19:54] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[19:55] * HardyPottinger (80ce8627@gateway/web/freenode/ip.128.206.134.39) has joined #duraspace
[19:59] * kgerbeitson (~keith-noa@lib-kgilbertson.library.gatech.edu) has joined #duraspace
[20:00] * richardrodgers (~richardro@dhcp-18-111-26-9.dyn.mit.edu) has joined #duraspace
[20:00] <tdonohue> Hi all -- Here's today's DSpace Devel Mtg agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2010-08-11
[20:00] <tdonohue> We're going to start off today with some JIRA catchup (for the first 20 mins or so). We'll probably be doing this for the next few meetings, so that we can all catchup on what issues need fixing before 1.7
[20:01] <tdonohue> Here is a search for recent issues in JIRA: http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10020&resolution=-1&created%3Aprevious=-20w&assigneeSelect=&sorter/field=created&sorter/order=ASC
[20:01] * bollini (~chatzilla@host119-222-dynamic.16-87-r.retail.telecomitalia.it) has joined #duraspace
[20:01] <tdonohue> we'll be starting with DS-533, as soon as I'm able to paste in the info
[20:01] <tdonohue> Collection Short Description not visible : http://jira.dspace.org/jira/browse/DS-533
[20:02] <richardrodgers> +1 fix for 1.7
[20:02] <tdonohue> (for those who are new to this -- here's how we vote & review these JIRA issues: https://wiki.duraspace.org/display/DSPACE/JIRA+Cleanup+Sessions )
[20:02] <mhwood> +1
[20:02] <tdonohue> +1 as well, fix for 1.7
[20:03] <bollini> 0
[20:03] <kgerbeitson> +1
[20:03] <PeterDietz> its a theme bug, so that means update reference, or use different theme
[20:03] <snail> tdonohue: +1 the link in the issue doesn't work for me though
[20:03] <jatrimble> +1
[20:03] <tdonohue> Ok, DS-533 summary: +6, we'll schedule it for 1.7
[20:04] <tdonohue> Documentation patch to alleviate file ownership confusion : http://jira.dspace.org/jira/browse/DS-535
[20:04] <tdonohue> jatrimble, need any help with this one? I see it's already assigned to you?
[20:05] <mhwood> Comments say it needs rework & I haven't done that yet, sorry.
[20:05] <tdonohue> Oh -- wait -- I remember this one...this was change suggested by mhwood
[20:05] <jatrimble> I don't think so....I'd like to update the documentation when we convert to Confluence. Can we hold off until then? (Like in two weeks...)
[20:05] <jatrimble> yes.
[20:05] <jatrimble> OOPS
[20:05] <tdonohue> ok, we'll skip for now... mhwood & jatrimble will look into as needed
[20:05] <tdonohue> Functional Test Framework for DSpace : http://jira.dspace.org/jira/browse/DS-536
[20:06] <tdonohue> Any thoughts on this? Is this obsolete cause of the Unit Test Framework in Trunk now?
[20:07] <mhwood> It appears to be a different sort of testing.
[20:07] <tdonohue> (obsolete is wrong word -- obviously functional testing different then unit testing)
[20:07] <richardrodgers> It should at least be evaluated against that work , I think
[20:08] <tdonohue> Ok -- will assign DS-536 to stuartlewis (as he mentor for Unit Test GSoC project) to get his feedback. We'll revisit later
[20:08] <tdonohue> PopulateMetadataFromPubmed patch seems incompatible with DSpace 1.6 : http://jira.dspace.org/jira/browse/DS-540
[20:09] <richardrodgers> who did original work (patch)?
[20:09] <tdonohue> this was grahamtriggs' old patch -- it never made it into "trunk"
[20:09] <tdonohue> graham isn't here today...though, we can always assign it to him for feedback/updates
[20:09] <richardrodgers> Should we see if he has interest in keeping alive?
[20:10] <tdonohue> Sure. Assign DS-540 to Graham Triggs for feedback/updates. revisit later
[20:10] <tdonohue> Item Mapper List of Mapped Items Usability : http://jira.dspace.org/jira/browse/DS-545
[20:11] <richardrodgers> 0 - needs sponsor /inplementer
[20:11] <tdonohue> agreed -- sounds like it could be resolved relatively easily just by changing the wording on the instructions on that page?
[20:12] <tdonohue> any volunteers?
[20:12] <PeterDietz> half is to change the wording, likely an i18n thing, but it has some change requested
[20:12] <mhwood> Yeah, it's a bug *and* an improvement request.
[20:12] <PeterDietz> i.e. view mappings while not already drilled into collection
[20:13] <tdonohue> true -- I overlooked that. Any volunteers to split this issue apart (into it's halves) and/or tackle at least the bug?
[20:13] <mhwood> I can split and do the bug half.
[20:14] <bollini> -1 the browse system could change if we adopt the dspace-discovery
[20:14] <tdonohue> thanks mhwood -- assign DS-545 to mhwood, and split into bug & feature/improvement request
[20:14] <tdonohue> XMLUI 'Notice's are always added by the Administrative aspect even if the content was generated by another aspect. : http://jira.dspace.org/jira/browse/DS-546
[20:15] <tdonohue> robin taylor has already claimed this one...so, I'll assume he's working on it
[20:16] <tdonohue> I'd vote to schedule this for 1.7 though -- it sounds like mdiggory & rtaylor have a good handle on it
[20:16] <richardrodgers> yep +1 if Robin has it sorted
[20:16] <tdonohue> I'll schedule DS-546 for 1.7, and touch base with Robin
[20:17] <tdonohue> Allow anchor tags/Xref objects in the XMLUI to have an 'id' attribute. : http://jira.dspace.org/jira/browse/DS-549
[20:18] <richardrodgers> Any sense of how disruptive this would be?
[20:18] <tdonohue> seems simple enough -- it seems like the whole goal is just to allow for the final XHTML <a> elements to have @id
[20:19] <jatrimble> As long as it is optional, it would have backword compatability issue in web design.
[20:20] <tdonohue> good point, jatrimble -- I think it would be -- as the themes/CSS don't look for an @id attribute right now (as it isn't possible)
[20:20] <tdonohue> Any volunteers to look into this a bit more?
[20:21] <PeterDietz> I can test the patch
[20:21] <jatrimble> exactly........ with css, backwords compatability is essential until something in css is depricated.
[20:21] <tdonohue> ok, thanks PeterDietz
[20:21] <tdonohue> Assign DS-549 to PeterDietz for testing and analysis
[20:21] <tdonohue> Upgrade to latest Google Analytics tracking code : http://jira.dspace.org/jira/browse/DS-550
[20:22] <tdonohue> +1 this seems logical, already assigned to stuartlewis...I'd say we schedule for 1.7
[20:22] <mhwood> +1 should be small and simple too.
[20:22] <kgerbeitson> +1
[20:22] <tdonohue> oh wait -- it already is scheduled for 1.7 :)
[20:22] <richardrodgers> +1
[20:22] <jatrimble> +1
[20:22] <tdonohue> Servlet to deliver repository size statistics : http://jira.dspace.org/jira/browse/DS-552
[20:23] <richardrodgers> Isn't this also proposed 1.7 feature?
[20:23] <mhwood> Depends on DS-494
[20:23] <bollini> 0 It seems more a REST function
[20:24] <tdonohue> yea, this was a proposed 1.7 feature -- any comments mhwood? Sounds useful to me, assuming it's obviously Admin-only
[20:24] <tdonohue> (and also assuming we add links to this /content-statistics path from the Admin UIs)
[20:25] <mhwood> We're using it here for the "library dashboard", to show anyone who cares how many items we have and suchlike.
[20:25] <mhwood> It's not really formatted for browsing; it's a little blob of XML for other app.s to use.
[20:25] <bollini> the output content is in xml
[20:26] <kgerbeitson> what's the "images" statistic?
[20:27] <mhwood> Any bitstream with MIME time "images/*".
[20:27] <kgerbeitson> ok
[20:27] <bollini> move this stuff in the rest project so that it is separate from jspui/xmlui
[20:27] <mhwood> Assuming that the REST project is adopted, that is probably the place for this to go.
[20:27] <tdonohue> if it's just XML returned, it seems logical to add to either REST or SOLR (or both)
[20:28] <mhwood> How would it fit into Solr?
[20:28] <PeterDietz> expose via REST, +1
[20:28] <bollini> via REST +1 (in solr project only staff related to the solr engine)
[20:29] <tdonohue> Solr can store any data -- so, it could just as easily be used to store/cache this information about content stats (you just need to feed it into Solr, and then build an interface to pull it out of Solr into a UI)
[20:29] <kshepherd> hi all
[20:30] <PeterDietz> hi kshepherd
[20:30] <bollini> I think that with dspace-discovery we can already build these data
[20:30] <mhwood> Seems simpler just to ask the DBMS to count index entries, for now. If the data model changes radically then Solr might be more attractive.
[20:30] <kshepherd> sorry for lateness, i'm a bit further from work these days..
[20:30] <tdonohue> bollini -- yea, I think you might be right -- and dspace-discovery is built on Solr :)
[20:31] * mhwood makes a note to finally find out what dspace-discovery is.
[20:31] <bollini> I'm starting to investigate about discovery
[20:31] <kshepherd> mhwood: solr search+facets instead of ArtifactBrowser in XMLUI, basically :)
[20:31] <tdonohue> ok -- any resolution on DS-552? sounds like many in favor of moving this to REST or at least putting on hold for now?
[20:32] <kshepherd> +1 REST, it already has some 'countitems' verbs that i've noticed
[20:32] <mhwood> +1 hold for REST decision
[20:32] <bollini> +1 rest
[20:32] <tdonohue> ok -- DS-552 -- keep assigned to mhwood. On hold to investigate moving to REST
[20:32] <tdonohue> we're at 30mins now..shall we stop for today (and do another 1/2 hour next week)?
[20:33] <mhwood> Yes, we've made good progress and shouldn't starve any other agenda items.
[20:33] <tdonohue> ok...if we have more time, we'll tack more JIRA items on at the end
[20:34] <tdonohue> The only other item today was DSpace 1.7 discussion/updates
[20:34] <bollini> I have some concerns about discovery... but I notice that Mark is not here today to discuss
[20:35] <bollini> any other has tried it?
[20:35] <richardrodgers> not me
[20:35] <PeterDietz> I got it, and put up a how to, and kshepherd has been able to install it as well
[20:35] <bollini> my concerns are about the solr installation
[20:35] <kshepherd> i have it running fine
[20:35] <tdonohue> I have not tried it -- Mark Diggory is on leave (he & his wife just had a baby), but he said he should be back in our meetings next week
[20:36] <kshepherd> solr installation is no more difficult than solr statistics currently
[20:36] <kgerbeitson> Will this be an optional module? (also concerns about having someone who can admin solr at small sites)
[20:36] <bollini> have you noted that it is a custom installation?
[20:36] * sandsfish (~sandsfish@18.111.11.108) has joined #duraspace
[20:36] <bollini> I'm talking about the solr installation
[20:36] <kshepherd> i'm happy to give people access to http://dspace.net.school.nz (it's behind http auth) if they want to try out discovery
[20:37] <snail> kgerbeitson: solr shouldn't need independent admin
[20:37] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[20:37] <PeterDietz> I think Dryad also runs discovery in some form: http://www.datadryad.org/search?query=&rpp=10&group_by=none&sort_by=score&order=DESC&submit=Go
[20:37] <kshepherd> bollini: i'm not sure what you mean.. i already had solr isntalled because i was using 1.6 stats
[20:37] <PeterDietz> discovery becomes an additional core to solr, as statistics was the original core
[20:37] <kshepherd> bollini: so building discovery was just adding a core
[20:37] <bollini> kshepherd, the sorl installation for statistics is a 1.3
[20:37] <bollini> the solr installation for discovery is a 1.4 modified
[20:38] <bollini> with support for additional features like aggregation
[20:38] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[20:39] <tdonohue> ok -- we probably need to touch base with mdiggory and @mire about this. So, far, Discovery was still not finalized as being part of 1.7. I think it was a hopeful feature, but never voted in.
[20:39] <kshepherd> ah. i didn't realise that it was modified..
[20:39] <bollini> http://scm.dspace.org/svn/repo/modules/dspace-solr/trunk/README
[20:39] <tdonohue> bollini, would you be willing to send you concerns/questions about Discovery to 'dspace-devel', to try and kick off this discussion?
[20:39] <bollini> I'm concerned about the maintenance of the SOLR-236 patch
[20:40] <bollini> tdonohue ok
[20:40] <tdonohue> So, one thing for us all to note, is that this week is our first milestone "Feature Decision Day". See timeline here: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+1.7.0+Notes
[20:41] <tdonohue> Obviously, it sounds like there are still a few features that are undecided -- e.g. Discovery, REST, others?
[20:41] <mhwood> And there are two proposed features on the agenda: REST and AIP Backup.
[20:42] <tdonohue> yes. So, those are two that I know have been proposed recently: REST & AIP Backup/Restore. Bollini just also brought up Discovery which is also needs a decision
[20:42] <kshepherd> well i like discovery.. i didn't realise the issues with dspace-solr dependency (didn't even realise it *was* a dependency) or that dspace-solr was so custom.. but at least it's basically stable and working as advertised
[20:42] <richardrodgers> I'm still reasonably confident about generalized type-based submission & curation (AIP replication, virus check, etc)
[20:43] <bollini> I like the idea behind discovery, so +1 for it with some technical details to decide
[20:43] <tdonohue> the point here is that, we probably won't be able to decide all of this by our proposed "Feature Decision Day". So, I'm willing to be a little flexible (assuming everyone agrees), and work these details out over the next few weeks
[20:43] <PeterDietz> Can we say that features that have sponsors, progress, and low hurdles are planned/approved features for 1.7, and the tougher things will be decided later
[20:43] <kshepherd> AIP looks good to me, i haven't had a chance to play with it yet
[20:44] <bollini> a last notice, I should be able to support the integration of discovery in JSPUI for 1.7
[20:44] <kshepherd> and i've played with REST API and will definitely be +1 on that once all the GET features work as advertised (without running tomcat out of memory ;))
[20:46] <kshepherd> though.. it's also a candidate for async release as well?
[20:46] <tdonohue> So, I think we have sponsors in place for most of these main features (as listed on the 1.7 notes). It'd just be good to start to get more of this work going into trunk
[20:46] <tdonohue> (or moving towards trunk if not quite there yet)
[20:46] <mhwood> So are there any we are ready to decide?
[20:48] <tdonohue> I'd like to decide on the AIP backup/restore work today, if we could do a quick vote (i'm a bit biased, as I'm tired of merging code and want to get this work moved into trunk)
[20:48] <tdonohue> via email, I had already heard +2 (from Stuart and from Robin) for AIP into trunk...
[20:48] <richardrodgers> I'm OK - but I sent you a few more issues tdonohue
[20:49] <tdonohue> richardrodgers -- yep, this code can change still, if we have issues with parts of it :) Just want to get it in soon, as it's in a nice stable state to do so
[20:49] <bollini> +1 as all the changes need by sword, lni are already in place, right?
[20:49] <richardrodgers> fine +1
[20:50] <mhwood> AIP +1 -- we need to get it out in front of people and see what they make of it.
[20:50] <tdonohue> bollini -- yes...SWORD changes are thoroughly tested & work. LNI changes are in there, but I need some more help testing it (volunteers?)
[20:50] <kgerbeitson> +1
[20:50] <kshepherd> +1
[20:50] * jatrimble (~jtrimble@maag127.maag.ysu.edu) Quit (Quit: Leaving)
[20:50] <bollini> tdonohue, sorry I can't test LNI
[20:51] <tdonohue> (my problem with LNI, is that I cannot even get the 1.6.2 LNI working properly with the clients I've tried -- so, it makes it difficult to test my small refactoring of it)
[20:51] <tdonohue> I'll add an Issue to JIRA to ask for LNI testing after the code goes into Trunk -- someone surely is using LNI?
[20:52] <tdonohue> ok -- sounds like we have a general consensus -- I'll work to get the code into trunk very soon, and also work to resolve the issues that richardrodgers sent along already
[20:52] <stuartlewis> Can I raise a quick question? In 1.6.1 we sort-of deprecated the /bin scripts. Can we vote to remove them in 1.7?
[20:53] <stuartlewis> (just leave 'dspace', and any non-java scripts)
[20:53] <mhwood> If it's been announced already, and we make some more noise as release approaches, I think we should do that.
[20:53] <bollini> I agree too
[20:53] <tdonohue> hi stuartlewis -- sure, we can vote on that... I'd be +1
[20:53] <kgerbeitson> +1, definitely with noise
[20:53] <kshepherd> yep, +1 to removal and to more noise/documentation
[20:53] <richardrodgers> stuartlewis: can we replace them with clones that say 'use dpsace'?
[20:54] <kshepherd> richardrodgers: hmm.. that's a good idea for people who forget about old cronjobs, etc.
[20:54] <richardrodgers> (just to be a little friendlier about pulling the rug out)
[20:54] <stuartlewis> richardrodgers: Maybe, but we've got to deprecate them sometime, so it might just confuse people more? Maybe a clean cut is better? Especially if people run these via cron, they might not see the warning message.
[20:55] <richardrodgers> true - it might get lost
[20:55] <kshepherd> it it's stderr output, cron should email it
[20:55] <mhwood> If they don't see the message from a cron job, will they see the job fail?
[20:55] <PeterDietz> also, are we changed the header code license to be a bit more abbreviated
[20:56] <stuartlewis> So we're plus four (incl me) for dropping the scripts. Any other votes?
[20:56] <tdonohue> I'd like to see us actually cut things off that we 'deprecate', and just document/announce it broadly (we've been notoriously bad about this in the past -- we've been releasing with a deprecated DCValue class for years now)
[20:57] <richardrodgers> +1 ok with me
[20:57] <stuartlewis> Thanks - will get that done.
[20:57] <mhwood> Well, DCValue has its tentacles into *everything*. But breaks or complains, either way people who are watching should see it and those not watching won't.
[20:57] <mhwood> +1 remove old scripts
[20:58] <tdonohue> yea, i just noticed it again now that Trunk (for me at least) throws WARNING every time it compiles anything with DCValue :) (I think it's the new testing settings?)
[20:58] <PeterDietz> +1 drop the bin scripts
[20:59] <stuartlewis> tdonohue: Yes - static analysis as part of maven. Is that OK, or would you prefer it turned off?
[21:00] <kshepherd> i think it's pretty cool, personally
[21:00] <tdonohue> OK for now -- might need to turn it off for the release (we don't want people emailing asking what the WARNING messages mean when they first build DSpace 1.7)
[21:00] <mhwood> For release it should be off, and we should be able to turn it on via profile or the like (and should do so).
[21:01] <stuartlewis> OK - we can investigate that over the next month or so.
[21:02] <tdonohue> OK -- we're over time. We'll push the REST discussion to next week, when mdiggory will also be back. We can try and decide whether we want to release it as "experimental", do an asynchronous release, or just wait till 1.8
[21:02] <mhwood> Discovery also on next week?
[21:02] <tdonohue> Feel free to add your thoughts on dspace-devel, or dspace-commit
[21:02] <richardrodgers> that's the beauty of timed releases, there's always another on soon...
[21:02] <tdonohue> yes -- Discovery too
[21:03] <tdonohue> So, next week will be: JIRA catchup, REST, Discovery (and anything else that comes up between now and then)
[21:03] <tdonohue> have a good one all! I'll stick around here for a bit in case anyone has anything pressing to discuss
[21:03] <mhwood> Sounds good. 'bye, all.
[21:04] <richardrodgers> bye all
[21:04] <bollini> thanks all
[21:04] * richardrodgers (~richardro@dhcp-18-111-26-9.dyn.mit.edu) Quit (Quit: richardrodgers)
[21:04] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[21:04] * sandsfish (~sandsfish@18.111.11.108) Quit (Quit: sandsfish)
[21:04] * bollini (~chatzilla@host119-222-dynamic.16-87-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716])
[21:04] * kgerbeitson (~keith-noa@lib-kgilbertson.library.gatech.edu) Quit (Quit: kgerbeitson)
[21:32] * HardyPottinger (80ce8627@gateway/web/freenode/ip.128.206.134.39) Quit (Quit: Page closed)
[21:45] * ksclarke (~kevin@adsl-39-10-103.clt.bellsouth.net) Quit (Ping timeout: 265 seconds)
[22:12] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[22:19] * ksclarke (~kevin@adsl-39-10-103.clt.bellsouth.net) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.