Timestamps are in GMT/BST.
[0:02] * greg-g (i=greg@ubuntu/member/greg-g) Quit ("Reconnecting")
[1:28] * ChanServ (ChanServ@services.) has joined #duraspace
[1:28] * greg-g (i=greg@ubuntu/member/greg-g) has joined #duraspace
[1:28] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[1:28] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[1:28] * snail (n=stuart@130.195.178.61) has joined #duraspace
[1:28] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[1:44] [freenode-connect VERSION]
[3:57] * mdiggory (n=mdiggory@cpe-76-176-9-20.san.res.rr.com) has joined #duraspace
[3:59] * mdiggory (n=mdiggory@cpe-76-176-9-20.san.res.rr.com) Quit (Client Quit)
[4:05] * DuraLogBot (n=PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:05] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:05] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[4:06] [freenode-connect VERSION]
[5:36] * snail (n=stuart@130.195.178.61) Quit (Read error: 110 (Connection timed out))
[5:36] * snail (n=stuart@130.195.178.61) has joined #duraspace
[7:57] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Remote closed the connection)
[7:57] * bradmc (n=bradmc@207.172.69.79) has joined #duraspace
[8:07] * mhwood (i=mwood@mhw.ulib.iupui.edu) has joined #duraspace
[9:27] * tdonohue (n=tdonohue@98.228.50.55) has joined #duraspace
[9:31] * tdonohue1 (n=tdonohue@98.228.50.55) has joined #duraspace
[9:40] * justben (n=ben@170.140.210.175) has joined #duraspace
[9:49] * tdonohue (n=tdonohue@98.228.50.55) Quit (Read error: 110 (Connection timed out))
[10:09] * tdonohue1 (n=tdonohue@98.228.50.55) has left #duraspace
[10:09] * tdonohue (n=tdonohue@98.228.50.55) has joined #duraspace
[11:13] * mdiggory (n=mdiggory@cpe-76-176-9-20.san.res.rr.com) has joined #duraspace
[11:40] * michaeldb (n=michaeld@CPE00222d540978-CM00222d540975.cpe.net.cable.rogers.com) has joined #duraspace
[12:22] * mdiggory (n=mdiggory@cpe-76-176-9-20.san.res.rr.com) Quit (Read error: 54 (Connection reset by peer))
[12:22] * mdiggory_ (n=mdiggory@76.176.9.20) has joined #duraspace
[12:22] * mdiggory_ is now known as mdiggory
[12:22] * mdiggory (n=mdiggory@76.176.9.20) Quit (Read error: 131 (Connection reset by peer))
[12:23] * mdiggory (n=mdiggory@cpe-76-176-9-20.san.res.rr.com) has joined #duraspace
[14:47] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) Quit ()
[14:52] * lcs (n=lcs@serenity.hul.harvard.edu) has joined #duraspace
[14:57] * jtrimble (n=jeffreyt@70.17.168.48) has joined #duraspace
[14:57] * jtrimble (n=jeffreyt@70.17.168.48) Quit (Client Quit)
[14:58] * jeffreytrimble (n=jeffreyt@pool-70-17-168-48.pitt.east.verizon.net) has joined #duraspace
[14:58] <tdonohue> Hi all. We have a DSpace Developer's meeting coming up here in a few minutes. I'm hoping we have enough for a small quorum, and can at least do a JIRA review. StuartLewis won't be able to attend, but would like us to review a few Jira issues for 1.6
[14:58] <tdonohue> if you have any other agenda items, feel free to list them now
[15:02] <lcs> i'd like to cover ds-377 in the jira review
[15:03] * Caryn (i=80c8e115@gateway/web/freenode/x-eiqyagzgeeicvyht) has joined #duraspace
[15:05] <snail> tdonohue: i'm vaguely around for the meeting but have no agenda items
[15:05] <tdonohue> Ok, so how many of you are actually "live" right now (and not just lurking) and willing to do a quick JIRA review?
[15:06] <tdonohue> Also, I need a volunteer to either (a) list the next JIRA item for review...or (b) total up and summarize after one minute is up -- I can do one or the other
[15:09] * tdonohue hears crickets
[15:09] <mhwood> Present. Do we just have a manual list of issues for review? (377, 390, 389, 295)
[15:10] <tdonohue> mhwood... those four were mentioned specifically by lcs and stuartlewis. After those, we left have a running list via JIRA search: http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10020&resolution=-1&created%3Aprevious=-4w&status=1&assigneeSelect=&sorter/field=created&sorter/order=ASC
[15:11] <tdonohue> (we last reviewed DS-375...so, we'd only be reviewing numbers greater than that)
[15:11] <lcs> i'm only giving this partial attention, so i'm half here..
[15:11] <mhwood> I think I can figure out how to feed the items from that, thanks. Will do.
[15:12] <tdonohue> ok...how about this. Since we have so many partials, let's just do this more ad hoc.
[15:12] <tdonohue> lcs: what did you want to discuss about DS-377, since we have you here
[15:13] <tdonohue> mhwood: no need to feed items...I think we are too small to even really vote (we are supposed to have at least three +1 votes to formally approve code changes, based on our voting procedures)
[15:14] <mhwood> OK
[15:14] <lcs> just wanted to make sure everyone is done stirring DS-377 before I commit it, but there's not much of "everyone"
[15:15] * jeffreytrimble (n=jeffreyt@pool-70-17-168-48.pitt.east.verizon.net) Quit ("Leaving")
[15:16] <mdiggory> don't think there's any more "stirring"
[15:16] <tdonohue> lcs: well, last meeting we did all approve DS-377 as-is. So, I think that should give you enough approval to commit. However, as you saw there were many suggestions for post 1.6
[15:16] <tdonohue> since mdiggory did the most stirring, i'd say commit it :)
[15:17] <lcs> that's about what I was figuring, although there's still the possibility of adding version info to response headers -- but that was mdiggory's puppy.
[15:18] <tdonohue> yea, i'd say the response headers is a good idea, but could wait for another patch
[15:19] <mhwood> I agree.
[15:19] <mdiggory> a little too much on my plate to add anything else at this time
[15:20] <tdonohue> lcs: so we good on DS-377 then?
[15:20] <lcs> good, we're all agreed. i'll commit and leave it open.
[15:21] * bradmc (n=bradmc@207.172.69.79) Quit (Read error: 104 (Connection reset by peer))
[15:21] * bradmc (n=bradmc@207.172.69.79) has joined #duraspace
[15:21] <tdonohue> Ok. The other issue that we had previously approved was DS-295 -- Stuart wondered if there was any more comments (see last two comments for changes since our approval). anyone have any thoughts?
[15:22] <tdonohue> http://jira.dspace.org/jira/browse/DS-295
[15:23] <mdiggory> yes, I think that is one for sturat to follow up on commiting
[15:23] <mdiggory> sturat = stuart
[15:24] <tdonohue> mdiggory: yea, stuart was more just looking to see if we generally approved the changes made since our last meeting
[15:24] <mdiggory> generally.... yes
[15:24] <lcs> it looks like the final outcome is to give the bitstreams actual descriptive BitstreamFormats, which is fine.
[15:24] <mdiggory> I agree with them ;-)
[15:24] <mhwood> I see nothing to object to.
[15:25] <mdiggory> Do we have any dependencies on the legacy "License" bitstream format?
[15:25] <tdonohue> ok, so that's 4 of us. I'll add a comment to let Stuart know we approve
[15:25] <lcs> mdiggory: all the plain-text deposit licenses use the legacy "License" format, unfortunately.
[15:27] <tdonohue> Since we currently have 4 of us active...Stuart also wanted a quick review of two more issues. I'll start with http://jira.dspace.org/jira/browse/DS-389 . Thoughts?
[15:27] <mdiggory> wondering if we still want to have CC License and License bitstreamformats !
[15:28] <mdiggory> both are just plain/text
[15:28] <lcs> mdiggory: can o' worms, see my bitstreamformat renovation patch.
[15:28] <mdiggory> :-)
[15:28] <mdiggory> I'm good at opening those
[15:28] <tdonohue> i'd agree with lcs...that's a big change I think
[15:29] <lcs> it's worth doing, someday, preferably while reforming bitstreamformats.
[15:29] <tdonohue> Quick vote on http://jira.dspace.org/jira/browse/DS-389 - Misleading label: "Submit to This Collection" (since it seems straightforward)
[15:29] <mhwood> +1
[15:29] <tdonohue> +1
[15:29] <lcs> +1 on ds-398
[15:29] <lcs> i mean, 389
[15:30] <mdiggory> but, I wonder if, as preparation for adding the BitstreamFormat renovation, there might be an interim opportunity to do some preparatory cleanup
[15:30] <mdiggory> 389 +1
[15:31] <tdonohue> Ok, I'll let stuart know DS-389 is approved - +4 in favor
[15:31] <tdonohue> mdiggory: might be a little too "late" to do too much preparatory cleanup before 1.6 -- not sure we have a volunteer who has time
[15:32] <mdiggory> think we should start a 1.7 version in the JIRA and start assigning tickets to it that are relevant
[15:33] <tdonohue> mdiggory: thanks for volunteering :)
[15:33] <mhwood> Is that 1.7 or 1.6.x?
[15:33] <mdiggory> funny how I get myself into these things ;-)
[15:33] <tdonohue> mhwood does bring up a good question though...we don't know what the next version is called yet
[15:33] <mdiggory> 1.7, limiting 1.6.x to true maintnence
[15:34] <tdonohue> oh, ok. I see, so 1.7 for major features. 1.6.x for bug fixes and usual maintenance. makes sense
[15:34] <mdiggory> we took 1.5.x a little too far out of the "maintence" mode
[15:34] <lcs> you mean 1.7 vs. 2.0? there's sure to be a 1.6.1.
[15:35] <tdonohue> lcs: agreed. Was more thinking of the when do we call it "2.0" question -- but that's a broader discussion that should happen after 1.6 is out the door
[15:36] <mdiggory> I think 2.0 will be cutting out major parts of the 1.x and dropping them onto cutting room floor
[15:36] <mdiggory> 1.7... should be viewed as preparation for that action
[15:36] * grahamtriggs (n=grahamtr@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[15:37] <tdonohue> I'd like to call one more quick vote (again on behalf of Stuart) for: http://jira.dspace.org/jira/browse/DS-390 - Workflow task notification emails not available on deposits via SWORD.
[15:40] <lcs> just glancing at the patch, looks like it is being done within the ingester; i know this is probably raising the bar more than we have time to address now but i'd prefer to see the logic outside of ingester plugins and done in a general way for all unattended package ingest (lni, sword, commandline)
[15:41] <grahamtriggs> I'm not convinced it's the right approach - imho, task notifications should always be sent on entering workflow. Any option to not do so should be an eperson level choice
[15:43] <lcs> grahamtriggs: that works too. abolish startWithoutNotify() and move the logic upstream.
[15:43] <grahamtriggs> And beyond that, rules based configuration for notification of deposits by certain people (at which point, you could disable just the generic login sword deposits)
[15:44] <tdonohue> good ideas / thoughts. Sounds like this may need some further work
[15:45] <tdonohue> any recommendations on how to make this better?
[15:45] <Caryn> i like the idea of being able to control who gets notified when - i'm pretty new to DSpace, so i might not be aware of options available right now, but i would definitely like this kind of control
[15:45] <tdonohue> do we abolish startWithoutNotifiy() ? Do we leave it as is and create a larger issue to rethink task notifications?
[15:46] <tdonohue> Caryn: thanks for your opinion!
[15:46] <mhwood> I think the idea has grown past the point at which it should be marked, "good idea, not in 1.6.0"
[15:47] <tdonohue> mhwood - point taken. more discussion needed. :)
[15:48] <Caryn> btw - i should introduce myself - i'm from uci, where we're working on getting an instance of dspace up in the libraries... i'm new to dspace, but not digital archiving
[15:48] <lcs> for now, i'd say either abolish startWithoutNotifiy() or have it call start() and make that configurable -- but defining the rules would take time and discussion. (e.g. by collection, eperson, phase of hte moon?)
[15:49] <lcs> none of the other workflow email is configurable, is it? maybe all this needs for now is a Big Switch, on or off.
[15:49] <tdonohue> Hi Caryn. Welcome.
[15:49] <mhwood> Yes, welcome.
[15:50] <Caryn> this was actually one of my questions... can i configure email triggers?
[15:50] <mhwood> Do we need a Quick Fix right now, or is it better to point to the patch and say that something more comprehensive is being designed.
[15:51] <lcs> It seems that right now the problem is some people want email and can't get it, so a simple change and a Big Switch would fix that, and maybe Do It Right in 1.7..
[15:51] <lcs> Caryn: welcome to the deep end of the pool.
[15:52] <tdonohue> lcs: yea, you are right there doesn't seem to be a "big switch" -- which could be a good option.
[15:52] <Caryn> lol - so far, i'm treading pretty well...
[15:52] <Caryn> another problem is that emails are generated, and some people don't want to see them
[15:52] <Caryn> so, a big switch would work
[15:52] <mhwood> And further on, I think we may identify several Big Switches that would benefit from finer granularity.
[15:53] <Caryn> mhwood: agreed
[15:53] <lcs> It helps to tag emails consistently (e.g. something in the Subject: header) so people who don't want them can have their user agent flush htem away.
[15:53] <lcs> that is all doable now in the email templates, btw.
[15:54] <tdonohue> i'll make sure to add these good comments to DS-390 -- I think I like the big switch idea for a simple switch...but we can always table this and formally approve/deny it at next weeks meeting (when stuart will hopefully also be in attendance)
[15:55] <tdonohue> Caryn: what do you mean by "some people don't want to see them"? do you have a simple example?
[15:55] <Caryn> many of our collections are project based, so there will be a time when as many as 100+ items are submitted in "rapid fire"
[15:56] <Caryn> the reviewers will know this is happening, and don't necessarily need to see an email per item...
[15:56] <tdonohue> oh. I understand. So, when loading in a big batch of content, those emails can get annoying and unnecessary
[15:56] <Caryn> i'm assuming this would be fixed by a big switch - the submitter takes care of submitting, then notifies the reviewers that a batch of files is ready...
[15:56] <Caryn> exactly!
[15:57] <snail> we are also facing a huge 'peak' of submissions in the run up to the PBRF (called the RAE in the UK), one email per item will be unpleasant
[15:57] <grahamtriggs> Caryn: Some people may not want to see them, but some people (possibly even them!) will NEED to see them, to action the notification. Users can always set up filters in their own email accounts to delete/move incoming messages, so it's generally better to err on the side of sending out more, not less
[15:57] <Caryn> our programmatic setup is a little unique, so we have some "special needs" - the filter idea is a possibility, but i know there have been discussions about turning the notifications off...
[15:57] <mhwood> Move the notification out of the submission flow to a scheduled task, which can batch up notifications?
[15:58] <Caryn> mhwood: that would be nice!
[15:58] <lcs> since email is inherently unreliable, isn't it better to count on mechanisms within DSpace to keep up with changes, e.g. task pools, RSS feeds, etc?
[15:59] <lcs> gee, wouldn't it be nice if we had an asynchronous event manager? http://wiki.dspace.org/index.php/EventSystemPrototype
[16:00] <tdonohue> Caryn: I'm not sure if the "big switch" we are talking about would really solve these problems yet -- though it could be related to a much larger discussion around improving email notifications, etc. So, I think this is a good idea worth some discussion. I'll add it as a Feature Request in our JIRA system and attach this commentary as a note to it.
[16:00] <mhwood> I was just going to ask whether there is enough variation among sites' needs here that we ought to have another plugin point.
[16:01] <Caryn> the big switch would be a work-around, not a complete solution. i think there might enough variation among sites, and among collections within sites that a tool like the asynchronous event manager might be worth the development...
[16:01] <Caryn> imho, of course
[16:01] <grahamtriggs> there are some cases where an asynchronous event manager could be useful, but in keeping track of task pools and dissemination via feeds isn't one of them!!
[16:02] <lcs> with asynchronous events, we could put the submission-email generator in an event consumer, and feed it a batch of events once a day. or give sites the option of firing it synchronously.
[16:02] <mhwood> No, but there are ancillary processes (like sending emails, or alternative notifications) which could be event sinks.
[16:03] <mhwood> I think the point may be that maintaining the task pools etc. is core to DSpace's function and should be inline, while notifying people that things are happening is peripheral and can be pulled out of the flow if it helps us.
[16:04] <mhwood> Just a note that we've passed the formal end of the meeting window.
[16:04] <tdonohue> yep. just about to say the same...but, I didn't want to interrupt discussion
[16:05] <tdonohue> feel free to continue the discussion, but consider the official "meeting" adjorned.
[16:06] <grahamtriggs> but the events are isolated incidents. so you need special logic to batch up the notifications (which you can have with or without an asynchronous event system). the only reason to put an asynchronous event in is in recognising that it isn't that time senstitive
[16:06] <tdonohue> I think these are all great ideas, and it could be useful to set aside a meeting to talk more about this topic and whether we want to look closer at the EventSystemPrototype work , etc
[16:06] <mhwood> And maybe back up to ask, what things are we doing inline that would be better as a separate process?
[16:07] <Caryn> so, tell me if i'm tracking, or if i'm way off... At this point, I can't control email triggers in DSpace (they're connected to task pools, and incorporated into the workflow). I can, however, customize the subject line of the emails, so a typical email filter can handle them as the recipient desires. Possible development issue for future releases, probably not 1.6.
[16:07] <lcs> anything that relies on an email notification shouldn't be time sensitive, and ought to be considered expendable anyway.. i can just see that some sites would want daily "digest" emails rather than one per submission.
[16:07] <mhwood> We already have stuff like the subscription emails that are run separately.
[16:08] <Caryn> seems like that is what we should expect, right? dspace handles the technical tracking, but we can control how our users are exposed to that information via email
[16:08] <lcs> the synchronous event system got integrated in 1.5, and rrodgers was thinking about adding async events as of a year ago or so; we talked about it. fwiw.
[16:09] <tdonohue> Caryn: Yes. I think you have it all. The email subjects can be customized in [dspace]/config/emails/ (just in case you haven't modified those templates before)
[16:09] <Caryn> tdonohue: yep, i'm definitely on those templates...
[16:09] <Caryn> thanks
[16:10] <tdonohue> Caryn: no problem. Thanks for joining the discussion.
[16:10] <Caryn> lcs: can you point me to documentation?
[16:10] <grahamtriggs> lcs: I agree, both about time sensitive, and that some people would want a digest. But creating a digest is it's own task, and entirely orthogonal to having an asynchronous event system (I'm open to it being discussed for inclusion, but for it's own merits)
[16:12] <lcs> Caryn: the wiki page http://wiki.dspace.org/index.php/EventSystemPrototype is close to what got implemented, only with all the asynch stuff left out. Though AFAIK events are mostly used for search and browse updates.
[16:12] <mhwood> Yes, collecting events is just one way to find batches of work.
[16:12] <Caryn> got it - thanks!
[16:13] <Caryn> ok if i ask one more question that might not be straightforward?
[16:14] <Caryn> my user group thinks of the terminology "communities" and "collections" in different ways - it is a little confusing for them...
[16:14] <Caryn> i can relabel those extensively, using manakin, but is there any way to programmatically "rename" these types of things?
[16:15] <lcs> Events are a convenient general way to gather the data, rather than implementing a separate feed for each kind of digest. And it lets the configuration control whether there's a synchronous or batch output (or both). ..but the first step should be to define the whole problem better, and that's more than i have time to think about now.
[16:15] <Caryn> lcs: agreed!
[16:15] <mhwood> Well, anything in the UI should be coming out of the message catalog, so at least it's all collected in one file.
[16:16] <tdonohue> Caryn: mhwood is right...you should be able to change those names in message.xml via a Find & Replace.
[16:17] <lcs> Caryn: as long as they can over look URLs like /community-list, yeah, the contents of the HTML pages can be changed. I had to subsitute "file" for "Bitstream" for the sensibilities of our users.
[16:17] <Caryn> ah ha - thanks!
[16:17] <Caryn> that's perfect - exactly what i need - urls are not a problem, only labels
[16:18] <lcs> If you find any places that can't be changed, please submit a bug, since it's also an i18n issue.
[16:18] <Caryn> will do
[16:19] <Caryn> thanks, everyone, for indulging my questions/comments... i'll definitely log in again! have a great day (and Thanksgiving too)
[16:20] <tdonohue> Caryn: Not a problem. Thanks for joining us, and have a good holiday. (Just an FYI..there are usually developers always in the #dspace IRC room, if questions come up)
[16:20] <tdonohue> (So, most of the time we only tend to use #duraspace for these meetings)
[16:20] * bradmc (n=bradmc@207.172.69.79) Quit (Read error: 131 (Connection reset by peer))
[16:21] <Caryn> thanks - i'll remember that
[16:21] * Caryn (i=80c8e115@gateway/web/freenode/x-eiqyagzgeeicvyht) Quit ("Page closed")
[16:21] * bradmc (n=bradmc@207.172.69.79) has joined #duraspace
[16:22] <tdonohue> All...I'm probably going to head into "lurking" for a bit now. Have a great Thanksgiving (for those of you in the US)!
[16:39] * grahamtriggs (n=grahamtr@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) Quit ()
[16:50] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[16:58] * mhwood (i=mwood@mhw.ulib.iupui.edu) has left #duraspace
[17:36] * justben (n=ben@170.140.210.175) Quit ("Leaving.")
[17:43] * tdonohue (n=tdonohue@98.228.50.55) has left #duraspace
[18:19] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) Quit ()
[20:24] * mdiggory_ (n=mdiggory@cpe-76-176-9-20.san.res.rr.com) has joined #duraspace
[20:24] * mdiggory (n=mdiggory@cpe-76-176-9-20.san.res.rr.com) Quit (Connection reset by peer)
[20:24] * mdiggory_ is now known as mdiggory
[20:31] * michaeldb (n=michaeld@CPE00222d540978-CM00222d540975.cpe.net.cable.rogers.com) Quit ()
[21:07] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[21:09] * mdiggory (n=mdiggory@cpe-76-176-9-20.san.res.rr.com) Quit ()
[21:30] * mdiggory (n=mdiggory@76.176.9.20) has joined #duraspace
[21:49] * bradmc (n=bradmc@207.172.69.79) Quit ()
[22:26] * mdiggory (n=mdiggory@76.176.9.20) Quit ()
[22:29] * mdiggory (n=mdiggory@76.176.9.20) has joined #duraspace
[22:38] * lcs (n=lcs@serenity.hul.harvard.edu) Quit (leguin.freenode.net irc.freenode.net)
[22:38] * mdiggory (n=mdiggory@76.176.9.20) Quit (leguin.freenode.net irc.freenode.net)
[22:38] * greg-g (i=greg@ubuntu/member/greg-g) Quit (leguin.freenode.net irc.freenode.net)
[22:38] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) Quit (leguin.freenode.net irc.freenode.net)
[22:38] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[22:40] * mdiggory (n=mdiggory@76.176.9.20) has joined #duraspace
[22:40] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[22:40] * lcs (n=lcs@serenity.hul.harvard.edu) has joined #duraspace
[22:40] * greg-g (i=greg@ubuntu/member/greg-g) has joined #duraspace
[22:40] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[22:41] * lcs (n=lcs@serenity.hul.harvard.edu) Quit ()
[23:02] * mdiggory (n=mdiggory@76.176.9.20) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.