Timestamps are in GMT/BST.
[2:41] * elschlomo (~ruckus@HSI-KBW-085-216-105-023.hsi.kabelbw.de) Quit (Quit: Leaving)
[6:27] -hubbard.freenode.net- *** Looking up your hostname...
[6:27] -hubbard.freenode.net- *** Checking Ident
[6:27] -hubbard.freenode.net- *** Found your hostname
[6:27] -hubbard.freenode.net- *** No Ident response
[6:27] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:27] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:27] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[10:40] * blob_ (81d746b9@gateway/web/freenode/ip.129.215.70.185) has joined #duraspace
[10:41] * blob_ (81d746b9@gateway/web/freenode/ip.129.215.70.185) Quit (Client Quit)
[13:53] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:24] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[15:41] * robint (81d746b9@gateway/web/freenode/ip.129.215.70.185) has joined #duraspace
[15:41] * robint (81d746b9@gateway/web/freenode/ip.129.215.70.185) has left #duraspace
[17:06] * snail (~yeatesst@130.195.179.39) Quit (Ping timeout: 268 seconds)
[17:13] * snail (~yeatesst@130.195.179.39) has joined #duraspace
[19:54] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[19:57] * KevinVdV (~KevinVdV@d54C14B50.access.telenet.be) has joined #duraspace
[19:59] <KevinVdV> HI all
[19:59] <robint> Hi KevinVdV
[19:59] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[20:01] <robint> Its time for our weekly developers meeting
[20:01] <robint> Looks like we are a small gang tonight :)
[20:01] <mhwood> Attendance seems light today.
[20:01] <robint> Everyone winding down for Xmas already !
[20:02] <robint> What about we have a quick look at the 1.8.1 issues and then we could do a normal Jira review ?
[20:02] <mhwood> Yes.
[20:02] <robint> https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=fixVersion+%3D+%221.8.1%22+AND+project+%3D+DS
[20:03] <robint> Thats the complete list assigned to 1.8.1. Quite a good number really.
[20:03] <robint> Lets whiz through the few that are still unresolved
[20:04] <robint> DS-1090
[20:04] <robint> Ah, no kompewter
[20:04] <robint> https://jira.duraspace.org/browse/DS-1090
[20:04] <mhwood> There is a patch.
[20:05] <mhwood> assignee is not here to discuss.
[20:05] <robint> Yes, actually Peter has committed it for 1.8.1
[20:05] <robint> DS-1082
[20:06] <robint> https://jira.duraspace.org/browse/DS-1082
[20:06] <robint> Invalid embargo causes item archival to crash.
[20:06] <robint> This was discussed at length last week
[20:06] <KevinVdV> Well I am assigned to that one, we talked about it a lot last meeting but no conclusion came out of it ........ so I am still unsure on how to proceed
[20:06] <robint> Me too.
[20:06] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[20:06] <robint> Hi hpottinger
[20:07] <hpottinger> hi, all
[20:07] <mhwood> Discussing DS-1082
[20:08] <robint> I reread last weeks discussion and it seemed we still didn't have a clear path
[20:09] <KevinVdV> Hence my confusion on how to proceed
[20:09] <robint> Just looking at the attached patch
[20:09] <mhwood> Still leaning toward "just catch the exception and say 'fix your embargo data'".
[20:11] <robint> I note that the patch logs the error, but doesn't email anyone
[20:11] <robint> mhwood: How were you thinking we would notify someone ?
[20:12] * mdiggory (~mdiggory@64.134.233.79) has joined #duraspace
[20:12] <robint> hi mdiggory
[20:13] <KevinVdV> Well at moment of writing I didn't have that in mind but Richard Rodgers did bring it up & quite like the idea of adding an alert email
[20:13] <KevinVdV> & perhaps a default embargo
[20:13] <hpottinger> is there ever any situation where DSpace e-mails an admin with a warning?
[20:13] <KevinVdV> (configurable)
[20:13] <robint> Just discussing again https://jira.duraspace.org/browse/DS-1082
[20:13] <mdiggory> robint: hi
[20:13] <mhwood> Argh, I don't know the submission process as well as I should. Redisplay the final-submission page with a red error message, go to an error page with a way back into submission -- something less disastrous than a stack trace.
[20:14] <mdiggory> small crowd...
[20:14] <robint> small but perfectly formed !
[20:14] <mdiggory> ba boom boom
[20:14] <KevinVdV> True mhwood, but if the item install isn't called from a UI ?
[20:15] <mhwood> Anything that calls it needs to catch the exception and turn it into something meaningful to the user.
[20:15] <robint> I'm leaning towards postponing this one for 1.8.2
[20:16] <KevinVdV> So am I at the moment (since I am low on time)
[20:16] <mhwood> That makes sense, given continuing uncertainty and the lateness of the hour.
[20:16] <robint> Its 9.15pm in KevinVdV land
[20:16] <mdiggory> seems like if its not the UI an email should go to the original submitter (IE SWORD user)
[20:16] <mdiggory> or CLI user
[20:17] <mhwood> Surely SWORD can pass back something that the client would recognize as an error indication.
[20:17] <robint> SWORD doesn't know if the collection has workflow attached
[20:18] <robint> so the item may be SWORD deposited but sit in workflow afterwards
[20:18] <mdiggory> But wouldn't InstallItem execute at the end of the sword request and fail?
[20:18] <mhwood> Why does SWORD need to know what happens to the item? It deposited successfully, or it didn't succeed and here's why.
[20:19] <robint> But InstallItem runs when the item is archived not when it is deposited
[20:19] <mhwood> Hmmm, no, InstallItem only happens at the end of workflow, yes?
[20:19] <mdiggory> robint: or more specifically, if there was not a workflow attached, it would be a sword error, if there was a workflow attached, it would be the workflow role...
[20:19] <KevinVdV> mhwood: yes
[20:19] <robint> mdiggory: yep, I think so
[20:20] <mdiggory> robint: But InstallItem runs when the item is archived not when it is deposited <---- depends, see above
[20:20] <KevinVdV> At the end of the workflow, but with the configurable workflow anything could be the end of the workflow
[20:20] <KevinVdV> Even a Command Line script could trigger the item install
[20:20] <mhwood> Explainer: I think of ingestion as always being a workflow, even if there are 0 steps between Submit and Install.
[20:20] <mdiggory> KevinVdV: yep...
[20:21] <KevinVdV> Hence my reluctance to just show something in the UI
[20:21] <mhwood> "embargo data are silly" is just a special case of "can't advance this submission, please fix it."
[20:22] <mdiggory> at least its good for the submitter (CLI, SWORD or XMLUI) to know (but only if they are the user in the InstallItem context)
[20:22] <mdiggory> Maybe its more (IS there someone in "Context" during the InstallItem, they should be alerted... otherwsie, its the admin.
[20:23] <robint> Happy to keep discussing, but I don't think we are going to get anything done for tomorrow.
[20:23] <KevinVdV> Indeed I suggest to postpone it
[20:23] <robint> Which is not a problem, I should add.
[20:23] <robint> Ok lets move on
[20:23] <mdiggory> Note, we are very close to starting a project to improve embargo system as a contribution to the community.
[20:23] <KevinVdV> I will log this discussion & previous weeks discussion in the task
[20:24] <robint> https://jira.duraspace.org/browse/DS-1081
[20:24] <robint> Java 7
[20:24] <robint> Thanks KevinVdV for investigating
[20:25] <robint> Looks like no action required other than us all confirming that there is no longer a problem
[20:25] <KevinVdV> But again haven't found much time ..........
[20:25] <robint> and then updaating the documentation
[20:25] <KevinVdV> Why aren't there more then 24 hours in a day :(
[20:25] <robint> No problem KevinVdV. Its one for us all to do in time.
[20:25] <hpottinger> I blame standards
[20:26] <robint> https://jira.duraspace.org/browse/DS-1076
[20:26] <robint> "Visualisation of static pages is broken in 1.8"
[20:27] <robint> Peter has attached a patch
[20:27] <hpottinger> patch looks good, am testing today
[20:27] <robint> Great stuff hpottinger !
[20:28] <robint> I notice Peter hasn't committed it yet
[20:28] <robint> I'm guessing he wanted some feedback first
[20:28] <hpottinger> I'll post results to the ticket, but I like the looks of the patch
[20:28] <mhwood> Patch looks like it will work. I had really hoped for something that would read an external file. I may do that approach anyway but that won't be ready today.
[20:29] <robint> We can always put something different into trunk
[20:30] <robint> If anyone has any comment, positive or negative, could they update the ticket ?
[20:30] <robint> Hopefully Peter will commit it for tomorrow
[20:31] <robint> If there are no further comments then that the end of our 1.8.1 review :)
[20:32] <hpottinger> I think there is a ticket for adding help pages to XMLUI that 1076 would make possible
[20:33] <robint> hpottinger: I'll have a dig around and mark it for 1.8.1 if that is the case, thanks
[20:34] <robint> Shall we do a quick Jira review ?
[20:34] <KevinVdV> Go right ahead
[20:34] <robint> https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-910+ORDER+BY+key+ASC
[20:34] <hpottinger> found the ticket for help pages: 894
[20:35] <robint> Thanks hpottinger
[20:35] <robint> https://jira.duraspace.org/browse/DS-910
[20:35] <robint> "Encoding of discovery facet urls"
[20:37] <KevinVdV> Interesting I think this one may be fixed for 1.8.x but not sure, so if nobody minds I will claim it & investigate
[20:37] <robint> Certainly don't mind ! Thanks KevinVdV
[20:38] <KevinVdV> *Claimed*
[20:38] <robint> https://jira.duraspace.org/browse/DS-911
[20:38] <robint> "Double facets on item pages"
[20:39] <robint> Another issue from the same person also on Discovery
[20:39] <KevinVdV> This has changed in DSpace 1.8.x so facets can't be enabled for item pages (since these are useless)
[20:40] <KevinVdV> So problem doesn't matter anymore
[20:40] <robint> Would you mind adding a comment to that effect in the ticket ?
[20:40] <KevinVdV> Not at all
[20:40] <robint> Sorry KevinVdV, everything is falling on you !
[20:40] <KevinVdV> Do we "Reject & close" ?
[20:41] <KevinVdV> No problem ;) the night is still young !
[20:41] <robint> Yes reject, and put in a comment. Thanks.
[20:41] <robint> https://jira.duraspace.org/browse/DS-912
[20:42] <robint> "Authorization policy"
[20:42] <robint> That covers a multitude of sins !
[20:42] <mhwood> User wants DSpace permissions to work like Windows filesystem.
[20:43] <robint> Looks like mdiggory and Stuart Lewis have both made good comments
[20:43] <mhwood> i.e. just inherit dynamically from parent until child is altered.
[20:44] <mhwood> Mapping makes this...interesting.
[20:44] <hpottinger> I have an internal ticket on changing the wildcard policy admin tool to work similarly to what is requested here
[20:44] <hpottinger> I like the curation task idea
[20:45] <robint> hpottinger: Feel free to claim it and run with it if you like :)
[20:46] <robint> It might turn out to be a can of worms
[20:46] <mhwood> It looks like concerns over zapping explicit policies set on the item would require saving whether a policy was copied.
[20:46] <hpottinger> nothing new with that, robint ;-)
[20:47] <hpottinger> I'd suggest two tasks: one for overwriting existing policies, one for retaining
[20:49] <robint> Ok, I'll cut and paste this conversation into the task
[20:49] <robint> One more...
[20:49] <hpottinger> or, I think tasks can go back for more feedback from an admin if run interactively
[20:49] <robint> https://jira.duraspace.org/browse/DS-913
[20:49] * hpottinger is a curation task newbie
[20:49] <mdiggory> TBH, I've been moody about ResourcePolices and the way we use them for some time now...
[20:50] <robint> mdiggory: It would be nice to abstract all that code behind some service
[20:51] <robint> so that we could plugin an alternative authorisation solution
[20:51] <mhwood> Ds-913 is for 1.6.2 so would need updating.
[20:51] <robint> Ah yes, thanks mhwood
[20:51] <mdiggory> A ResourcePolicy is a detail concerning the state of the Item, for instance, "Embargo" is a Policy. But we hard code that policy in proceedural code rather than objectifying it in our Policy framework.
[20:52] <mdiggory> what would be an alternative authorization system?
[20:53] <robint> Don't know :)
[20:53] <mdiggory> JAAS?
[20:53] <robint> But I sort of feel I don't need to know
[20:54] <robint> I should just be able to ask - am I authorised to do something to something
[20:54] <mhwood> Hmmm. IIRC, *testing* policy is concentrated in one place. So the problem is in composing policies and attaching them to objects?
[20:54] <mdiggory> well, that was the DSpace 2.0 initiative.... http://scm.dspace.org/svn/repo/dspace2/core/trunk/api/src/main/java/org/dspace/services/mixins/UserAuthorizationService.java
[20:56] <robint> Thats the sort of thing I had in mind
[20:57] <mhwood> Don't we have that now, in a non-Service way?
[20:58] <mdiggory> mhwood: even the setting of polices was abstracted away...
[20:58] <mdiggory> http://scm.dspace.org/svn/repo/dspace2/core/trunk/impl/src/main/java/org/dspace/services/user/MemoryUserAuthzProvider.java
[20:58] <mhwood> Thinking of AuthorizeManager.authorizeAction
[20:58] <mhwood> AuthorizeManager.addPolicies
[20:59] <robint> mhwood: yes'ish. Although we have other authorisation solution for metadata types, and for the devolved admin functions
[20:59] <robint> Its all got a bit messy
[20:59] <mhwood> The root, then, is that we need more kinds of DSOs.
[20:59] <mdiggory> http://scm.dspace.org/svn/repo/dspace2/core/trunk/api/src/main/java/org/dspace/providers/UserAuthorizationProvider.java
[21:00] <mdiggory> http://scm.dspace.org/svn/repo/dspace2/core/trunk/api/src/main/java/org/dspace/providers/AuthzManager.java
[21:02] <mhwood> More DSO subtypes and more operation codes.
[21:02] <mdiggory> not so sure, what types do you need?
[21:03] <mdiggory> why do they need to be DSO?
[21:03] <mhwood> So policies can be attached.
[21:03] <mdiggory> Why does an object need to be of type DSO to have a policy attached?
[21:04] <mdiggory> sorry, I'm baiting you
[21:04] <mhwood> Because I need to go back and look at the code again?
[21:04] <robint> mhwood: I was about to agree with you :)
[21:05] <robint> I notice that its past the hour
[21:05] <mdiggory> Ok, so generally, we have a DSpaceObject and because the method parameters are types and the DB has fkeys, we need to extend DSo to make more types in a way that we can attach resource policies
[21:05] <robint> So thanks to all for contributions
[21:06] <KevinVdV> I need to run, cya all
[21:06] <robint> Cheers KevinVdV
[21:06] * KevinVdV (~KevinVdV@d54C14B50.access.telenet.be) Quit (Quit: KevinVdV)
[21:06] <mdiggory> But, what I'm trying to get at is actually the ResourcePolicies, they are what should be extended...
[21:07] <robint> mdiggory: tell more
[21:07] <mdiggory> But our model is not extensible without great deal of work because we do not use JAVA Inheritance for typing in DSO or in ResourcePolicies
[21:07] <hpottinger> robint: are you sure you want to put DS-894 in for 1.8.1? I can try to get it done by deadline, but I'm not sure how doable that will be, realistically
[21:07] <mdiggory> We putt "typing" into fields in DSO
[21:07] <mdiggory> and into properties of the ResourcePolicy
[21:07] <mdiggory> ppppttttbbbbhhhhhhhh.....
[21:07] <robint> hpottinger: I wouldn't rush into it
[21:08] <mhwood> I think that's spelled, ":-P"
[21:08] <mdiggory> thanks
[21:08] <robint> I could just add a note to it that the other issue (whose number I forget) may have enabled a solution
[21:09] <hpottinger> robint: I have existing DRI for help files, patterned after the JSPUI help files, but it's full of MOspace-isms, that will have to be carefully excised/replaced
[21:10] <mdiggory> In a more extensible world.... ResourcePolicy would be a base type and you would have, ReadPolicy, WritePolicy, MyPolicy, RestrictPolicy, EmbargoPolicy....
[21:10] <robint> hopttinger: No probs. Sounds good but maybe for trunk rather than 1.8.1. Cheers
[21:11] <mdiggory> and you wouldn't remove an EmbargoPolicy to release the object from embargo, it would have a date range enforced within it.
[21:11] <mdiggory> in which it was valid
[21:12] <mdiggory> and it would have its own behavior which could be tested against to validate if the user can access the resource
[21:12] <mhwood> We could actually use the date ranges we already define....
[21:12] <mdiggory> correct, but they can have different meaning in RestrictPolicy vs AccessPolicy
[21:13] <robint> I'm going to hace to duck out. Cheers all.
[21:13] <mhwood> Thanks, robint!
[21:13] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Quit: Page closed)
[21:14] * mhwood wonders if we should first deal with not having *any* kind of policy applied to things people want to protect. (Metadata....)
[21:15] <mdiggory> depends on which is considered default
[21:15] <mdiggory> access or no access
[21:17] <mdiggory> If Policies were inherited on the hierarchy: Site > Community > Collection > Item > Bundle > Bitstream ....
[21:17] <mdiggory> then it could be entirely configurable
[21:18] <mhwood> Subclassing ResourcePolicy *does* make it easier to modularize policies. A policy instance in the backing store would be a BLOB of serialized goop which has attached behavior (when deserialized) to interpret itself, so e.g. an Embargo package could define policy subclasses only relevant to itself. They just drop in.
[21:18] <mdiggory> DefaultAccessPolicy attached to Site.... used to define Access below it
[21:20] <mhwood> We seem to have left behind the original issue: policies are inherited at object creation time and can't be made to track the parent's policies.
[21:20] <mdiggory> This takes me back to MIT... Pledge was an attempt to define the Policies that would be in force in a Repository.
[21:20] <mdiggory> http://pledge.mit.edu/index.php/Main_Page
[21:21] <mdiggory> the objective was to express real world policies in a descriptive actionable language (RDF)
[21:21] <mdiggory> http://pledge.mit.edu/images/c/cd/Cu0002rei.n3
[21:25] <mhwood> I just realized we're all talking about two quite different meanings of "inheritance".
[21:25] <mhwood> Must be careful.
[21:27] <mhwood> Anyway, the problem in the issue is a familiar one: people don't find it natural that a child object inherits policies at creation. They want the policy aspect of objects to be translucent: use the nearest un-obscured relevant policy of the object or any of its ancestors.
[21:28] <mdiggory> Yes, one is about policy enforcement, the other is about extensibility of the logic and persistence of policy capabilities.
[21:31] <mhwood> Or, at least, they want to be able to push policy changes down to child objects. But you correctly point out that we don't want to do that to explicit policies on the child, only to previously-inherited policies.
[21:34] <mhwood> We can do that whether we use the Java type hierarchy or invent our own.
[21:35] <mhwood> Letting Java take care of it for us has intriguing possibilities, but isn't that orthogonal to the problem that users keep pointing to?
[21:35] <mdiggory> right
[21:36] <mdiggory> I'm not so sure I let java take care of it...
[21:37] <mdiggory> I'd just give a little more freedom to the developers to create new types of policies...
[21:38] <mhwood> It sounded like we would deserialize a string of policies and ask each one: may I do this? until we get a positive answer or run off the end of the string.
[21:40] <mdiggory> to a degree... We might have a InheritedPolicy and SimplePolicy.... Inherited would contain the logic to step up the graph/hierarchy
[21:40] <mhwood> Oh, I was back on type inheritance. Sorry....
[21:40] <mdiggory> Simple would just have an evaluate interface
[21:41] <mdiggory> I think that would be too spooky for folks to wrap their heads around...
[21:42] <mdiggory> though you would get a great deal of freedom if you just serialized the object hierarchy to a blob... true... I just wouldn't want to be around when it broke for the end users ;-)
[21:43] <mhwood> No worse than ASN-1: you just have to provide tools to interpret the data.
[21:45] <mdiggory> its that latter part...
[21:46] <mhwood> Anyway, you were discussing just two types of policies: Inherited and Simple.
[21:47] <mhwood> Are we talking about dynamic inheritance from containers, or "push-down" modification of a contained object's policies from the container on demand?
[21:48] <mhwood> Does this need to move to dspace-devel?
[21:48] <mdiggory> probibly....
[21:49] <mdiggory> I almost assume that the default AuthorizationManager logic would be dynamic inheritance.
[21:49] <mhwood> I think that's what people really seem to want.
[21:50] <mdiggory> so that a change in dynamic collection level policies does not require pushing lots of changes into a DB...
[21:50] <mhwood> That's a trade-off: do we do lots more UPDATEs or lots more SELECTs?
[21:50] <mdiggory> however, policies can impact indexing among other things... some sort of eventing might be required to keep everything in sync
[21:51] <mhwood> Ugh, policy would have to travel with the index record, or be reconstituted on reference.
[21:51] <mhwood> No, it can't travel with the record.
[21:52] <mdiggory> we do need to maintain Item state now in our solr indexes... wish Kevin were still here... we worked on this a bit
[21:52] <mhwood> Would indexing really be affected? or would policy only shape what you can see from the index.
[21:52] <mdiggory> we are indexing Submission, Workflow, Archived and Withdrawn now...
[21:53] <mdiggory> and providing views on each in Discovery... to extend an ability to manage large numbers of items into the Submission and Workflow Administrative UI
[21:54] <mdiggory> thus why I said to Sands... don't rely on the solr webapp being able to be made public for json querying etc
[21:54] <mdiggory> because we plan to pack it with a great deal more detail about items...
[21:55] <mhwood> Yup, *every* interface needs to go through a policy filter.
[21:59] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) has joined #duraspace
[22:01] <mhwood> I'm going to have to go. Interesting discussion!
[22:03] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:06] * kompewter (~kompewter@peterdietz.lib.ohio-state.edu) has joined #duraspace
[22:07] <PeterDietz> sorry to have missed today's meeting, OSU had holiday events. I'll commit DS-1076 as is. Anyone who follows this issue will need to improve upon it.
[22:09] <mdiggory> sorry, have to go as well... enjoy
[22:09] * mdiggory (~mdiggory@64.134.233.79) Quit (Quit: mdiggory)
[22:09] <PeterDietz> I'll also commit DS-1090 (CC license negative size array) to trunk
[22:13] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) Quit (Read error: Connection reset by peer)
[22:13] * kompewter (~kompewter@peterdietz.lib.ohio-state.edu) Quit (Read error: Connection reset by peer)
[22:29] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[22:30] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) has joined #duraspace
[22:33] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) Quit (Read error: Connection reset by peer)
[22:44] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[22:50] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) has joined #duraspace
[22:53] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) Quit (Read error: Connection reset by peer)
[23:10] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) has joined #duraspace
[23:29] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) Quit (Read error: Connection reset by peer)
[23:41] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) Quit (Quit: mdiggory)
[23:46] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) has joined #duraspace
[23:59] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.