Timestamps are in GMT/BST.
[0:23] * mdiggory_ (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit (Read error: 104 (Connection reset by peer))
[0:24] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[2:48] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit (Read error: 60 (Operation timed out))
[3:15] * krnl__ (i=krnl_@193.219.158.144) has joined #duraspace
[3:31] * krnl_ (i=krnl_@193.219.158.144) Quit (Read error: 110 (Connection timed out))
[3:40] * krnl_ (i=krnl_@193.219.158.144) has joined #duraspace
[3:59] * krnl__ (i=krnl_@193.219.158.144) Quit (Read error: 110 (Connection timed out))
[4:43] * grahamtriggs (n=trig01@195.128.10.96) has joined #duraspace
[4:44] * grahamtriggs (n=trig01@195.128.10.96) has left #duraspace
[4:45] * grahamtriggs (n=trig01@195.128.10.96) has joined #duraspace
[5:03] * RichardJones (n=richard@94-194-200-240.zone8.bethere.co.uk) has joined #duraspace
[7:21] * grahamtriggs (n=trig01@195.128.10.96) has left #duraspace
[8:03] * mhwood (i=mwood@mhw.ulib.iupui.edu) has joined #duraspace
[9:02] * scottatm (n=scottatm@r74-192-18-124.bcstcmta01.clsttx.tl.dh.suddenlink.net) Quit ()
[9:27] * scottatm (n=scottatm@peat.evans.tamu.edu) has joined #duraspace
[9:37] * ksclarke (n=kevin@ip-152010148147.library.appstate.edu) has joined #duraspace
[10:32] * Sam_O (i=4a42460e@gateway/web/freenode/x-hzrzspcpmrmxmpyl) Quit ("Page closed")
[13:10] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) has joined #duraspace
[14:30] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) Quit ()
[15:48] * ben_atmire (n=ben_atmi@62.235.144.177) has joined #duraspace
[15:55] * tdonohue (i=80ae241d@gateway/web/freenode/x-vxiuichdecaqycee) has joined #duraspace
[15:58] <kshepherd> morning all
[15:59] <stuartlewis> Hi Kim
[15:59] <kshepherd> hey stuart.. back in 5
[16:02] * rrodgers (n=rrodgers@dhcp-18-111-15-222.dyn.mit.edu) has joined #duraspace
[16:03] <stuartlewis> Are we supposed to be having a meeting now?
[16:03] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) has joined #duraspace
[16:03] <mdiggory> Hello
[16:04] <rrodgers> (so can we officially now start dumping work on tdonohue ? ;) )
[16:04] * bollini (n=chatzill@host142-190-dynamic.17-87-r.retail.telecomitalia.it) has joined #duraspace
[16:04] <mdiggory> :-)
[16:04] <tdonohue> rrodgers: Eeek no!
[16:04] <tdonohue> i'm holding out as long as I can... :)
[16:05] <bollini> hi all
[16:05] <tdonohue> I've got too much transition work going on locally these days ;) though I'm looking forward to it being done, so I can concentrate on Dspace/DuraSpace
[16:06] <rrodgers> anyway, got a msg that bradmc can;t attend, so one of us should moderate
[16:07] <mdiggory> I assume it will be predominantly 1.6, can we volunteer stuartlewis
[16:07] <mdiggory> ;-)
[16:07] <rrodgers> I like your thinking
[16:07] <stuartlewis> Not sure I do! :)
[16:07] <tdonohue> in any case, we can start with agenda items...right?
[16:07] <mdiggory> I have to leave in about 30 minutes so I'm not a great candidate
[16:08] <bollini> I'm too
[16:08] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer))
[16:08] <stuartlewis> 1) 1.6 - stats and embargoes
[16:08] <stuartlewis> 2) 1.6 release planning
[16:08] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:08] <mdiggory> me/ thinks this could also be tdonohue's passage of initiation
[16:08] <stuartlewis> Any other agenda items?
[16:09] <tdonohue> sure, i'm fine pushing the agenda along...though it sounds like most of it is going to be stuartlewis led w/1.6
[16:09] <mdiggory> (1) is why I'm here...
[16:09] <stuartlewis> mdiggory: No, we'll make sure his initiation takes place late at night in Gothenburg...! :)
[16:09] <mdiggory> hehehe
[16:09] * tdonohue is not sure he likes where this is going :)
[16:09] <stuartlewis> Any other agenda items?
[16:10] <rrodgers> JIRA?
[16:10] <stuartlewis> JIRA cleanup?
[16:10] <rrodgers> yes - not sure there is much to say
[16:10] <stuartlewis> No -seems to be going well. Will be good when the duraspace intern gets the time to action all the decisions.
[16:11] <tdonohue> agreed
[16:11] <rrodgers> Will one more session suffice?
[16:11] <stuartlewis> At the rate we're going, possibly not.
[16:11] <stuartlewis> What we could do, is skip any issues that are assigned to people.
[16:12] <stuartlewis> So if you have any assigned that you don't want, unassign yourself, and vice versa.
[16:12] <rrodgers> I ask, because if we want follow-on before code freeze, it might be tight...
[16:12] <stuartlewis> Yes :(
[16:12] <mdiggory> sounds like we could use an update to the wiki concerning which have been covered, which are owned and which still need review
[16:12] <bollini> what is the mean of code freeze exactly?
[16:13] <mdiggory> code-freeze means no more new features may be added
[16:13] <rrodgers> Well, traditionally one still allows bug fixes, but not destabilizing new features
[16:13] <mdiggory> and we move into an iteration of testing
[16:13] <bollini> features scheduled for 1.6 but not completed before...?
[16:13] <stuartlewis> Do we think we can aim for an end of September code freeze?
[16:14] <tdonohue> yes, if we want a beta by DSUG in Oct, we probably need an end of Sept code freeze
[16:14] <stuartlewis> Major missing components (which need to be in 1.6 rather than 1.6.1) are embargoes and stats.
[16:14] <mdiggory> possibly, if we can get resolution on outstanding new features like stats by then
[16:14] <stuartlewis> Ok - lets talk about those. Embargoes first...
[16:14] <mdiggory> stuartlewis: stats is not missing... its in process
[16:15] <rrodgers> I have heard no daminng words about embargo, so I could check in soon
[16:15] <stuartlewis> rrodgers: How are the embargoes going? Any indication of a date when they'll be ready and commited?
[16:15] <stuartlewis> middogry: Sorry - missing = missing from svn
[16:15] <stuartlewis> rrodgers: Excellent news. Thanks.
[16:15] <mdiggory> in svn, not in trunk...
[16:16] <stuartlewis> Stats then....
[16:16] <stuartlewis> WHat are the outstanding issues we need to decide Mark?
[16:16] <kshepherd> rrodgers: the simple implementation i tested worked perfectly..
[16:16] <mdiggory> Ok, per stats... there are two topics of interest
[16:16] <rrodgers> Remember that it's really a framework, not a canned solution. I'm hoping we will have 2 or 3 sample implementations
[16:16] <mdiggory> UsageEvent/Services... Graham present issues with using services and caching.
[16:16] <rrodgers> one from Harvard, maybe one from kshepherd
[16:17] <tdonohue> rrodgers: but, does that mean there will still be something "out-of-the-box" or no?
[16:17] <mdiggory> I consulted with Aaron concerning this and we determined that the only caching that was being done was at the request level
[16:17] <mdiggory> ok, one topic at a time?
[16:17] <tdonohue> (sorry...we're on to stats...we can go back to embaro afterwards)
[16:17] <tdonohue> yep
[16:17] <tdonohue> go one mdiggory
[16:18] <tdonohue> go on
[16:18] <mdiggory> dspace-services uses ehcache to cache request objects during the request cycle, this is all
[16:18] <mdiggory> it doesn't do caching of any session level or DSpaceObjects, thus there is no replication
[16:19] <mdiggory> the request is cached so that it can be referenced easily during the transactional window
[16:19] <mdiggory> and released at the end of the request cycle (by the servlet filter/etc
[16:19] <rrodgers> like DS 1 context cache?
[16:20] <mdiggory> Yes, somewhat
[16:21] <mdiggory> explicitly for RequetCache, there are other caching options "scopes" available, but they are unused in dspace-services
[16:21] <mdiggory> they are used in DSpace 2.0 User services aand Session services
[16:21] <mdiggory> but thes are not provided in the build I created for use in 1.x
[16:22] <stuartlewis> So is there a decision that we have to make?
[16:23] <mdiggory> Yes, services vs original 1.x code + alterations to support easier transfer of DSpaceObjects/State and multiple UsageEvent Consumers
[16:23] <rrodgers> how extensive would the alterations be?
[16:24] <stuartlewis> What are the pros / cons of each?
[16:24] <mdiggory> I.E. either we adopt services, or we tweak 1.x to make it more like EventService
[16:24] <mhwood> Multiple consumers appears to be a fairly small change.
[16:24] <mdiggory> we have a patch ben_atmire has done to work with... changes look like....
[16:25] <ben_atmire> the patch I created simply chained all consumers after each other
[16:25] <mdiggory> In either case... More hooks in the JSPUI and XMLUI to generate Usage Events (as seen in the imho statistics code
[16:26] <rrodgers> Have we quantified this UI work? days, weeks?
[16:26] <mdiggory> UsageEvent needs to have its method signatures changed to hold DSpaceOBject and HttpRequest Objects
[16:26] <mdiggory> rrodgers: Most of this work is done in both cases, what we have are two approaches that we are trying to decide between
[16:27] <stuartlewis> mdiggory: Do you have a preference?
[16:27] <tdonohue> so, going back to what stuart said, I'm not sure i understand the full pros/cons of the choices
[16:27] <mdiggory> My preference (given my research and planned presentation work for DSUG) is dspace-services
[16:27] <rrodgers> mdiggory: noted, I was just worried about resources in the 1.6 timeframe
[16:28] <bollini> I have not looked at this code yet but if we can move towards to 2.0 architecture (services) this could be great
[16:28] <stuartlewis> Is it do-able in the next 4 weeks?
[16:28] <mdiggory> IMO either is doable in 4 weeks
[16:29] <mdiggory> challenges are not implementation, challenges are acceptance and testing by the community
[16:29] <stuartlewis> How seamless a change would services be to joe public sys admin?
[16:29] <tdonohue> what sort of challenges do you see in acceptance? Is it in migrating existing stats systems (minho, etc) over to use this one?
[16:30] <mdiggory> Services are configured in ServiceManager, not in DSpace.cfg
[16:30] <stuartlewis> What does that mean in practice?
[16:30] <mdiggory> tdonohue: the challenges I see with migrating Minho are that I am unaware how they integrate with the UI beyond the UsageEvent level.
[16:31] <bollini> are you talking about spring configuration files right?
[16:31] <mdiggory> Yes and No...
[16:32] <mdiggory> Configuring the DSpace ServiceManager can be done in Spring, or it can be done programatically. In the cases I careated, it is configured in a Spring applicationContext file stored within either the XMLUI or JSPUI and initiatlized in the servlet lifecycle
[16:32] <mdiggory> in XMLUI it is the same applicationContext.xml utilized by Cocoon
[16:33] <ben_atmire> but this is something that's preconfigured, and most installations don't need to worry about it?
[16:33] <tdonohue> this is sounding too complex for "joe sys admin"...
[16:34] <bollini> tdonohue: I'm not sure about this... there are a lot of examples of spring configuration files out of there
[16:34] <mdiggory> ben_atmire: yes, it is preconfigured, and is not any further out of the reach of Joe System Admin than applying crazy patches maintained in a S.F. tracker
[16:35] <mhwood> As I understand it, you wouldn't need to touch the config. unless you want to plug in something else (or additional).
[16:35] <mdiggory> sorry, meant to also address that to tdonohue
[16:35] <mdiggory> mhwood: correct
[16:35] <mdiggory> Which leads to the question of the delivery of a statistics addon for DSpace 1.6
[16:36] <mdiggory> currently the solr stats solution resides int he modules directory with its own release cycle
[16:36] <mdiggory> and this is the manner I've proposed the community switch to for creating new features for dspace 1.x and 2.x
[16:37] <mdiggory> for instance you will also find dspace-srw and several other webapps/addons among the projects there
[16:37] <mdiggory> including the language packs
[16:38] <stuartlewis> How does someone make use of these? Check them out, edit a pom, and mvn' it?
[16:39] <mdiggory> as a developer, yes, as a user, they would add them as dependencies to their maven pom, just like the way we use existing dependencies
[16:39] <tdonohue> i'm mostly worried about whether this is going to be useable immediately by the folks without much sysadmin support...is there something that will work "out-of-the-box" for 1.6?
[16:39] <mdiggory> however, with solr and any other webapplication based addons our current model requires the use of amodules/xxxx project to overaly on
[16:40] <mdiggory> the question of it working out of the box has to do with if we enable it by default or not
[16:40] <tdonohue> ok
[16:41] <mdiggory> I think there would be less questions if the prototype were looked at and reviewed by the group
[16:41] <bollini> could we release more packages? a dspace1.6 base, a dspace1.6+stats etc.?
[16:41] <mdiggory> https://scm.dspace.org/svn/repo/dspace/branches/dspace-1.6.x-services/
[16:41] <mhwood> I *think* I have the prototype here, but I was unclear on what bits to get, where from, how arranged, and how to plumb them together for building.
[16:42] <mdiggory> bollini: the idea tends to be that we could release a "base" installation within which you can configure those modules you wish to be using
[16:43] <mdiggory> The significant change in this prototype is the addition of...
[16:43] <mdiggory> https://scm.dspace.org/svn/repo/dspace/branches/dspace-1.6.x-services/dspace/modules/solr/
[16:43] <bollini> mdiggory: ok... but a preconfigured "binary" could help
[16:43] <mdiggory> for the solr server that runs statistics storage and querying functionality
[16:43] <mdiggory> bollini: if dspace had a "binary" this is as close as we get...
[16:44] <mdiggory> the dspace-1.6.0-release.zip would contain just the following contents...
[16:44] <mdiggory> https://scm.dspace.org/svn/repo/dspace/branches/dspace-1.6.x-services/dspace/
[16:44] <stuartlewis> What are the implications of solr in terms of startup scripts, or is it just another webapp to copy to tomcat?
[16:44] <mdiggory> and the build would have solr and statistics eventservices preconfigured
[16:45] <mdiggory> just another webapp... I wrote initialization scripts within it that creat the appropriate /dspace/solr directory and configuration on startup
[16:45] <tdonohue> is the solr webapp just for stats right now?
[16:46] <mdiggory> its also deploys its configuration to dspace/config on that initialization as well
[16:46] <mdiggory> the solr configuration that is deployed is "multicore"
[16:46] <mdiggory> which means that solr can be utilized for more than just stats.
[16:46] <tdonohue> right...gotcha...i'm very familiar with solr
[16:47] <mhwood> I have a strong dislike of applications that write in their configuration directories, but I can grumble about that later.
[16:47] <mdiggory> the solr server would be part of the release no matter if we ustilize UsageEvent or EventService
[16:48] <mdiggory> mhwood: that can be altered if it becomes too offensive ;-)
[16:48] <stuartlewis> So it sounds like we just need to make a decision and get on with it.
[16:48] <mdiggory> pretty much...
[16:48] <stuartlewis> Is everyone happy to make a decision now, or do we want to look into the prototypes further?
[16:48] <rrodgers> I'd say we need volunteers to download/testdrive Mark's config
[16:48] <mdiggory> but I have a criticism about making such decisions in meetings like this
[16:49] <kshepherd> +1 to more testing
[16:49] <tdonohue> rrodgers ++ it'd be good to get some more eyes on this (though it sounds good, based on marks description)
[16:49] <stuartlewis> Time is the issue. Would everyone be happy to test in the next 7 days, and decide at the meeting next week?
[16:49] <stuartlewis> Or do we need longer?
[16:50] <rrodgers> within 2 weeks?
[16:50] <tdonohue> i won't be able to help out in next 7...but then again, i'm swamped for a while
[16:50] <bollini> I will have no time to check it before the 1.6 release...
[16:50] <mdiggory> There are portions of the stats "presentation" work we are still completing... they are my next topic...
[16:50] <mdiggory> but I am very much out of time.
[16:50] <tdonohue> mdiggory: do you have a demo site to show off the presentation work?
[16:51] <mdiggory> and suggest that it can be tested in parralell to those developments
[16:51] <mdiggory> tdonohue: once added, they will show up int he dspace JSPUI and XMLUI as simple tables for this iteration
[16:51] <mhwood> Do we just checkout http://scm.dspace.org/svn/repo/dspace/branches/dspace-1.6.x-services and we have all we need? I had a notion that I also needed http://scm.dspace.org/svn/repo/modules/dspace-services/trunk stuck into dspace/modules.
[16:51] <kshepherd> mhwood: that's dspace 2.0 services i think
[16:52] <mdiggory> mhwood: you shouldn't, hey are delivered by Maven
[16:52] <mdiggory> and are in the snapshot dspace maven repo
[16:52] <bollini> sorry... I need to leave, I will check the logs tomorrow
[16:52] <mdiggory> and would be deployed to the central repo on release
[16:52] <stuartlewis> Thanks Andrea. Bye.
[16:52] <bollini> bye all
[16:52] * bollini (n=chatzill@host142-190-dynamic.17-87-r.retail.telecomitalia.it) Quit ("ChatZilla 0.9.85 [Firefox 3.0.13/2009073022]")
[16:53] <mdiggory> I'm afraid I will need to go as well... But it is clear that I need to provide some guidelines for testing the prototype and will do so.
[16:53] <mhwood> dir
[16:53] <mhwood> Sorry, wrong focus.
[16:54] <rrodgers> thanks mdiggory
[16:54] <tdonohue> thanks mdiggory!
[16:54] <mdiggory> hehe
[16:54] <mhwood> mdiggory: yes, please, and thanks!
[16:54] <mdiggory> ok... will try to get that out asap...
[16:54] <mdiggory> bye all
[16:54] <stuartlewis> Thanks Mark. Bye.
[16:54] <kshepherd> seeya, cheers
[16:54] <mhwood> 'bye
[16:54] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) Quit ()
[16:54] <tdonohue> bye Mark
[16:54] <stuartlewis> So... back to embargoes, or does anyone want to talk about stats more?
[16:55] <tdonohue> not right now...i was wondering whether there's anything for the embargos that will be "out-of-the-box" or not...
[16:55] <rrodgers> To answer tdonohue question: embargo always depends on a policy, which we won't define
[16:56] <tdonohue> that makes sense...but how do the policies get configured?
[16:56] <rrodgers> but, if one's needs are really simple (like putting in an end date), there will be sample code (like Harvard's) that
[16:56] <rrodgers> you can use as is.
[16:57] <tdonohue> i'm worried a bit on how easy this would be for folks without much sys admin support
[16:57] <rrodgers> If one's need are more complex, you write the logic in a java class
[16:58] <tdonohue> "complex = java" makes sense...I'd just hope there's something simple that folks without a sys admin can set up for now
[16:58] <mhwood> Apparently "simple = somebody else already wrote one"
[16:59] <stuartlewis> Can we ship some basic preconfigured options that just uncommenting etc?
[16:59] <rrodgers> I debated offering samples with the distribution, and can do, but I'm not convinced there are any cases that really address that many institutional needs
[16:59] <rrodgers> stuartlewis: yes we can
[16:59] <tdonohue> yea...i'm just trying to think from the point of view of the folks who requested these features from the community-outreach surveys...there's quite a few folks there who don't have java support locally, etc.
[17:00] <rrodgers> What I am worried about is this: there are things like language dependencies that are sticky
[17:00] <tdonohue> hmmm...true
[17:00] <rrodgers> I can give you a "6 months" but how about a "6 monat" etc
[17:01] <rrodgers> the point is that policy language tends to be native
[17:01] <tdonohue> and i'm assuming the current i18n stuff just won't cut it with this?
[17:01] <kshepherd> could we come up with some i18n keys for common date/time/emgargo terms?
[17:01] <kshepherd> embargo*
[17:02] <rrodgers> kshepherd: in time I think we could, but I think the code needs to be socilaized a bit first
[17:03] <rrodgers> also, there were many cases where poliicies don't even involve dates but references to publishers etc
[17:04] <stuartlewis> Sounds good anyway. Looking forward to it :)
[17:04] <tdonohue> i'm still worried that people will be expecting "out-of-the-box"...i.e. they expect to upgrade to 1.6 and suddenly see an "embargo" step/option in submission process, etc.
[17:04] <tdonohue> but, maybe that's just me...i could be wrong
[17:04] <kshepherd> i do have to agree that there is very little common ground between various institutions' embargo requirements, even though it has been requested as one broad feature
[17:05] <mhwood> Could the specific i18n issues be enumerated, categorized and laid out in an email for study, without a lot of work?
[17:05] <stuartlewis> tdonohue: Yes - just a basic one like setting a date during submission or workflow.
[17:05] <tdonohue> stuartlewis: yea, definitely nothing complex...very simple
[17:05] <rrodgers> stuartlewis: tdonohue I can give you a 'set the date' out of the box - it's just a plugin
[17:06] <tdonohue> rrodgers: i think that'd be great
[17:06] <rrodgers> In fact Harvard already wrote it
[17:06] <rrodgers> All you have to do is in dspace.cfg pick a metadata field to use and its done
[17:06] * ksclarke (n=kevin@ip-152010148147.library.appstate.edu) Quit ("Leaving.")
[17:06] <tdonohue> ok, then that covers my worries...i don't think i had understood what was written and what wasn't
[17:06] <mhwood> That might cover a lot of cases and give some time to study the more complex ones.
[17:07] <stuartlewis> An hour is up now. Do we have more to talk about, or shall we wrap it up for today?
[17:07] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer))
[17:07] <rrodgers> OK we'll launch with that one
[17:07] <tdonohue> sounds great...
[17:07] <tdonohue> i think i'm done...i gotta run anyways
[17:07] <mhwood> I need to go too.
[17:07] <tdonohue> thanks all!
[17:07] <kshepherd> cheers, bye all
[17:08] <mhwood> Thanks!
[17:08] <rrodgers> thanks all
[17:08] * rrodgers (n=rrodgers@dhcp-18-111-15-222.dyn.mit.edu) Quit ()
[17:08] * tdonohue (i=80ae241d@gateway/web/freenode/x-vxiuichdecaqycee) Quit ("Page closed")
[17:08] <stuartlewis> Thanks. Bye.
[17:08] * mhwood (i=mwood@mhw.ulib.iupui.edu) has left #duraspace
[17:16] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[17:32] * scottatm (n=scottatm@peat.evans.tamu.edu) Quit ()
[17:36] * ben_atmire (n=ben_atmi@62.235.144.177) Quit ()
[18:58] * ksclarke (n=kevin@adsl-1-145-78.clt.bellsouth.net) has joined #duraspace
[20:21] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 54 (Connection reset by peer))
[20:21] * bradmc_ (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[20:21] * bradmc_ is now known as bradmc
[22:41] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[23:03] * ksclarke (n=kevin@adsl-1-145-78.clt.bellsouth.net) Quit ("Leaving.")
[23:48] * mdiggory_ (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[23:48] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit (Read error: 54 (Connection reset by peer))
[23:48] * mdiggory_ is now known as mdiggory
[23:57] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit ()
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.