Timestamps are in GMT/BST.
[2:28] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[3:16] * tdonohue (~tdonohue@dspace/tdonohue) Quit (Quit: Leaving.)
[3:41] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[5:41] * tdonohue (~tdonohue@dspace/tdonohue) Quit (Quit: Leaving.)
[6:28] -barjavel.freenode.net- *** Looking up your hostname...
[6:28] -barjavel.freenode.net- *** Checking Ident
[6:28] -barjavel.freenode.net- *** Found your hostname
[6:28] -barjavel.freenode.net- *** No Ident response
[6:28] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:28] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:28] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[12:33] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[13:24] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:20] * AlexS[zedat] (~Alexander@home.zedat.fu-berlin.de) Quit (Quit: WeeChat 1.9.1)
[14:20] * AlexS[zedat] (~Alexander@home.zedat.fu-berlin.de) has joined #duraspace
[14:20] * AlexS[zedat] (~Alexander@home.zedat.fu-berlin.de) Quit (Client Quit)
[14:21] * AlexS[zedat] (~Alexander@home.zedat.fu-berlin.de) has joined #duraspace
[14:33] <DSpaceSlackBot> <tdonohue> <here>: Reminder that at the top of the hour (~30mins) is our weekly DSpace DevMtg here. Our agenda is light today, so please feel free to bring topics/tickets to discuss. https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-11-29
[14:33] <kompewter> [ DevMtg 2017-11-29 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-11-29
[15:00] <DSpaceSlackBot> <tdonohue> <here>: it's that time again. DSpace DevMtg starts now. Our light agenda is above :point_up:
[15:00] <DSpaceSlackBot> <tdonohue> Let's do a quick roll call first, to see who is joining the discussion today
[15:00] <DSpaceSlackBot> <mwood> Present
[15:01] <DSpaceSlackBot> <hpottinger> here
[15:02] <DSpaceSlackBot> <tdonohue> So, a lot of lurkers here it seems :slightly_smiling_face: Well, at least we have a small quorum of 3...and hopefully others will pop up in discussion
[15:02] <DSpaceSlackBot> <hpottinger> I am also a lurker :slightly_smiling_face:
[15:03] <DSpaceSlackBot> <tdonohue> So, as noted our agenda is a tad light, but I just added a new topic on the end of it. We'll start with some general updates though...
[15:04] <DSpaceSlackBot> <tdonohue> DSpace 7 WG next meets tomorrow (15UTC). The DSpace Entities WG next meets next week (Tues, Dec 5 at 15UTC)
[15:04] <DSpaceSlackBot> <terrywbrady> here
[15:05] <DSpaceSlackBot> <tdonohue> I don't have any major updates to pass along on the DSpace 7 side of things. Cause of the holiday weekend in USA, I'm still catching up a bit. Work is progressing on both Search & Submission, primarily thanks to Atmire & 4Science , respectively. Hopefully more to report next week
[15:05] <DSpaceSlackBot> <tdonohue> On to DSpace 6.3 updates. https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.3+Status
[15:05] <kompewter> [ DSpace Release 6.3 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.3+Status
[15:06] <DSpaceSlackBot> <tdonohue> Is there any updates anyone wants to share on the 6.3 efforts? I'm glad this Status page is here for us to chip away at...but, I admit I've not had much time myself to do so
[15:06] <DSpaceSlackBot> <mwood> "
[15:07] <DSpaceSlackBot> <tdonohue> (I'm assuming that's a "ditto", @mwood? and not a typo?)
[15:07] <DSpaceSlackBot> <terrywbrady> I like the format quite a bit. It was very helpful in our 6.1 release.
[15:07] <DSpaceSlackBot> <mwood> Yes.
[15:07] <DSpaceSlackBot> <tdonohue> just verifying...sometimes it's hard to tell in a text chat ;)
[15:07] <DSpaceSlackBot> <tdonohue> agreed, @terrywbrady... the Status page is a good start & has good organization here
[15:08] <DSpaceSlackBot> <hpottinger> DS-2670 I like quite a bit
[15:08] <kompewter> [ https://jira.duraspace.org/browse/DS-2670 ] - [DS-2670] Restrospectively create DOI's for alle items in archive - DuraSpace JIRA
[15:09] <DSpaceSlackBot> <hpottinger> needs another +1 and we can merge it
[15:09] <DSpaceSlackBot> <tdonohue> @hpottinger: I suspect it mostly needs some testing / verification. A new curation task is quite standalone (not likely to harm anything else), but probably should get a sanity test, if possible
[15:09] <DSpaceSlackBot> <tdonohue> So, if someone can give it a sanity test, I'll gladly add in a second +1 (via code review)
[15:10] <DSpaceSlackBot> <hpottinger> well... I trust @mwood, and the script is mostly just walking the tree and re-running existing code over it
[15:10] <DSpaceSlackBot> <mwood> It works for me, but I haven't heard back from the people here who wanted it.
[15:12] <DSpaceSlackBot> <tdonohue> I just really like to see us testing code, or writing unit tests. I trust it likely works too, but sometimes a second set of eyes / test will bring out a flawed assumption, or similar.
[15:12] <DSpaceSlackBot> <mwood> would also like to see another independent test.
[15:13] <DSpaceSlackBot> <tdonohue> While this PR looks reasonable to me, I still would like us to have a precedence of testing things that are more than an "obvious, one-liner"
[15:14] <DSpaceSlackBot> <hpottinger> this is 78 lines of re-wrapping our own code :slightly_smiling_face: but I understand the impulse... I'm not sure I'm up to the journey of discovery of setting up DOIs
[15:14] <DSpaceSlackBot> <hpottinger> @mwood would you be able to write a quick "how to test" for the PR?
[15:14] <DSpaceSlackBot> <tdonohue> So, let's not rush it. Make sure it's on the 6.3 list, make sure it's clear it just needs a test. Let's see if we can find a tester who already has DOIs setup
[15:15] <DSpaceSlackBot> <mwood> I will look into it.
[15:15] <DSpaceSlackBot> <tdonohue> (And to be clear, the tester need not even be a Committer. It could be anyone)
[15:16] <DSpaceSlackBot> <hpottinger> this script is kinda the first thing someone would need to "set up DOIs" on their existing repository
[15:16] <DSpaceSlackBot> <tdonohue> Keep us honest here though, @hpottinger... and keep pinging us on this. We need to find more testers anyhow, so let's use this as a way to try and do so.
[15:17] <DSpaceSlackBot> <hpottinger> if anything is broken in that script, though... we have bigger worries
[15:17] <DSpaceSlackBot> <mwood> "Set up DOI on an existing collection" is exactly our use case.
[15:18] <DSpaceSlackBot> <tdonohue> So, I think we are in general agreement here. Let's get the use case documented clearly, and perhaps offer hints to testing it (even with a "fake/test" DOI, if that's possible). Then let's look for a tester and try to get this in soon
[15:19] <DSpaceSlackBot> <hpottinger> DS-2687 is also one I like
[15:19] <kompewter> [ https://jira.duraspace.org/browse/DS-2687 ] - [DS-2687] When deleting a collection role the group is also deleted, which is not appropriate for non-system-created groups - DuraSpace JIRA
[15:19] <DSpaceSlackBot> <mwood> Testing used to be easier -- EZID had a common test username/password. Now you have to have credentials to use the test "shoulder".
[15:20] <DSpaceSlackBot> <hpottinger> 2687 just needs a final +1, it's already tested
[15:21] <DSpaceSlackBot> <tdonohue> 2687 looks to have requested changes. If those are deemed no longer necessary, it'd be good to have Tom revert his request and/or approve it
[15:21] <DSpaceSlackBot> <hpottinger> duplicate change requests
[15:22] <DSpaceSlackBot> <mwood> I will review.
[15:22] <DSpaceSlackBot> <tdonohue> I'm simply noting that it shows up with a big red "x" from @tom_desair, which is not something I want to jump in and merge without verifying that Tom is OK with it.
[15:23] <DSpaceSlackBot> <hpottinger> tom's review was "in the future" remark, plus an un-needed import observation, the import has been removed
[15:23] <DSpaceSlackBot> <hpottinger> but, I agree, @tom_desair should un-block it
[15:24] <DSpaceSlackBot> <tdonohue> Right, I agree it looks "ready". But, merging is currently blocked by @tom_desair. So, either he needs to approve it, or we should have a good reason to override his block and merge anyways
[15:25] <DSpaceSlackBot> <hpottinger> the code change he asked for has been made, the "in the future" code change is, presumably, "in the future" :slightly_smiling_face:
[15:25] <DSpaceSlackBot> <tdonohue> Again, this is more a "policy" comment.... our policy should *not* be to override the blocks of other trusted individuals or Committers. I'm not objecting to this PR, persay, but objecting to the overriding a block on the PR ;)
[15:26] <DSpaceSlackBot> <hpottinger> yup, blocks should be un-done by the blocker
[15:26] <DSpaceSlackBot> <tdonohue> We need to be clear that a "block" in this scenario is almost like a temporary "veto" of the code, and per our Voting policy, we are not allowed to override individual vetos
[15:26] <DSpaceSlackBot> <mwood> I agree, we should clear up the block before merging. It should be a simple matter.
[15:27] <DSpaceSlackBot> <hpottinger> @tom_desair is one of our lurkers today, and we're talking in a time-block that's friendly to him, I assume he's busy
[15:27] <DSpaceSlackBot> <tdonohue> Ok, any other tickets to quickly discuss regarding 6.3? Otherwise, I have a last minute agenda item I'd like initial feedback on
[15:28] <DSpaceSlackBot> <mwood> I have no tickets in mind.
[15:28] <DSpaceSlackBot> <tdonohue> Ok, I'll take silence as consent...and move along to my topic ;)
[15:29] <DSpaceSlackBot> <tdonohue> A discussion has begun between @tom_desair and I around the best usage of `@author` tags in our codebase. See this PR comment thread: https://github.com/DSpace/DSpace/pull/1884#pullrequestreview-79593864
[15:29] <kompewter> [ DS-3651: Range header support by tomdesair · Pull Request #1884 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1884#pullrequestreview-79593864
[15:30] <DSpaceSlackBot> <tdonohue> I'd simply like feedback on it... I'm concerned about using `@author` tags to refer to corporations/organizations instead of individuals.
[15:30] <DSpaceSlackBot> <tdonohue> After doing some digging around on what others do, I also found that Apache Foundation recently *banned* usage of `@author` tags in their own codebases
[15:30] <DSpaceSlackBot> <tdonohue> http://www.theinquirer.net/inquirer/news/1037207/apache-enforces-the-removal-of-author-tags
[15:30] <kompewter> [ Apache enforces the removal of author tags | TheINQUIRER ] - http://www.theinquirer.net/inquirer/news/1037207/apache-enforces-the-removal-of-author-tags
[15:31] <DSpaceSlackBot> <terrywbrady> Would it be appropriate to have an author name + affiliation?
[15:31] <DSpaceSlackBot> <tdonohue> So, I'm really just wondering what others think here
[15:32] <DSpaceSlackBot> <tdonohue> My opinion is in line with that, @terrywbrady. I simply think that `@author` tags should reference an individual, or we should leave them out. I don't mind an affiliation on that individual
[15:32] <DSpaceSlackBot> <sulfrian> Shouldn't the git history contain all the author information?
[15:33] <DSpaceSlackBot> <mwood> I would say: anyone who wrote code should be listed, if we use @author at all. I'm not going to list people I talked to.
[15:33] <DSpaceSlackBot> <tdonohue> @sulfrian: yes. My understanding is that is why Apache Foundation banned `@author` tags. Essentially because they are almost useless (often outdated, and take up space), and the real history is in Git/SVN/etc
[15:34] <DSpaceSlackBot> <hpottinger> I think the @author tag would have much higher importance for projects/code that might be incorporated in *other* projects
[15:34] <DSpaceSlackBot> <terrywbrady> I have found it interesting to see some references to past institutional contributors in the code base, but I see your point that it is basically useless info. I have probably added code that contained a clone of old author fields.
[15:35] <DSpaceSlackBot> <terrywbrady> It requires some effort to provide changes with a clean commit history and this is an additional field that may not get populated consistently.
[15:36] <DSpaceSlackBot> <sulfrian> If we want to track the affiliation of the contributors we could add a single file containing all contributors with their email address and affiliation.
[15:36] <DSpaceSlackBot> <terrywbrady> It does seem that when an entire plugin or module is contributed, it would be useful to have a place to share some of that background. Perhaps in a README file.
[15:37] <DSpaceSlackBot> <tdonohue> @sulfrian: good point. We do somewhat have that in this Wiki page: https://wiki.duraspace.org/display/DSPACE/DSpaceContributors (See Contributors at the bottom), but it's not distributed with the code currently
[15:37] <kompewter> [ DSpaceContributors - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpaceContributors
[15:37] <DSpaceSlackBot> <mwood> I'm somewhat inconsistent. I usually don't *add* myself as author to an existing file, but do confess my authorship of a *new* file.
[15:38] <DSpaceSlackBot> <tdonohue> @mwood: I do the same. And sometimes I frankly just forget to add an `@author` tag to things I do ;)
[15:38] <DSpaceSlackBot> <mwood> Well, we have two questions to answer: (1) do we use @author or not? (2) If yes, how do we use it?
[15:39] <DSpaceSlackBot> <mwood> IIRC my IDE adds them automagically. :slightly_smiling_face:
[15:39] <DSpaceSlackBot> <bollini> I'm in favor of the @author tag but it should refer to an individual. I don't think we can put additional limitation about the email address to use or inclusion of the affiliation information
[15:39] <DSpaceSlackBot> <hpottinger> for this project, `git blame` is the appropriate tool for determining authorship. If we were in the business of making libraries that other people use.... I'd feel a lot stronger about @author tags.
[15:41] <DSpaceSlackBot> <bollini> git blame don't give an accurate view on complex refactoring and the migration from one tool (svn to git, git to whats come next) can loose information
[15:41] <DSpaceSlackBot> <terrywbrady> Btw, I have appreciated the way the project recognizes contributors (and their institutions) for each release.
[15:41] <DSpaceSlackBot> <tdonohue> My initial question was simply "Do we care enough about `@author` tags to "police" them? Or is it "anything goes"?" It sounds like we must care though, as this as generated a fair amount of discussion
[15:41] <DSpaceSlackBot> <mwood> That's true: git blame tells you who touched it. @author tells you who designed it.
[15:42] <DSpaceSlackBot> <mwood> I do feel that an @author without an actual author (a person) is not a good idea.
[15:42] <DSpaceSlackBot> <sulfrian> `git log <file>` will tell you the complete history.
[15:43] <DSpaceSlackBot> <mwood> I don't feel strongly about @author yes or no.
[15:43] <DSpaceSlackBot> <hpottinger> me either :slightly_smiling_face:
[15:44] <DSpaceSlackBot> <mwood> I would look for @author if I want to ask "why is it made this way? what is this supposed to do?" But, as has been said, I can go fishing in the log for the answer.
[15:44] <DSpaceSlackBot> <tdonohue> So, summarizing so far... I'm hearing two things that seem to have agreement (please correct me if I'm wrong): 1. `@author` tags should refer to individuals if they exist 2. We don't seem to have strong opinions about either requiring or banning usage of `@author` tags.
[15:45] <DSpaceSlackBot> <mwood> Agreed, on both statements.
[15:46] <DSpaceSlackBot> <tdonohue> Do others agree? Is there a third point I've missed?
[15:46] <DSpaceSlackBot> <terrywbrady> Perhaps a statement that the convention is to add them for new files. Author tags are discouraged for small contributions.
[15:46] <DSpaceSlackBot> <tom_desair> Sorry I’m a bit late. A third point might be: When do you add an `@author` to a file? Not? Or only after a major refactoring or improvement?
[15:46] <DSpaceSlackBot> Action: tdonohue seems to have stumbled on a topic of interest...lots of good discussion here!
[15:47] <DSpaceSlackBot> <terrywbrady> No strong opinions here since I have never intentionally created the tags, but I see the value in some consistent guidance.\
[15:48] <DSpaceSlackBot> <tdonohue> @tom_desair: I'd generally say an `@author` reference is only relevant if you've done something *major* (i.e. major refactor, or new file creation). And even then, you should never remove an existing `@author`
[15:48] <DSpaceSlackBot> <mwood> I wouldn't be surprised to see a new @author appear with a major change in the design of a class.
[15:49] <DSpaceSlackBot> <tdonohue> Minor changes / bug fixes should just be tracked via git commits. Sorry, you aren't an `@author` if you fix a minor bug
[15:50] <DSpaceSlackBot> <tdonohue> That's how I generally see the `@author` tag. It's more about a major contribution
[15:50] <DSpaceSlackBot> <tdonohue> And minor contributions should still be tracked...they should just show up in Git history, and they'll still end up in our Contributors listing
[15:52] <DSpaceSlackBot> <tdonohue> This may be something we could update in our Code Contribution Guidelines (not seeing mention of `@author` there): https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-CodeContributionStandards
[15:52] <DSpaceSlackBot> <tom_desair> While my preference goes to the proposal of @sulfrian, I’m OK with consistent guidance on the `@author` tag.
[15:52] <kompewter> [ Code Contribution Guidelines - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-CodeContributionStandards
[15:53] <DSpaceSlackBot> <tdonohue> Which proposal was that? Having a "Contributors" README file in the code?
[15:53] <DSpaceSlackBot> <mwood> Regarding a file of contacts: that is difficult. Addresses and affiliations change.
[15:53] <DSpaceSlackBot> <tom_desair> Using Git to check the history and contributors.
[15:54] <DSpaceSlackBot> <tdonohue> We use Git to check history & contributors already. I use it to add to the Contributors list on the wiki, for example, and to list the contributors *per* release (in the Release Notes)
[15:54] <DSpaceSlackBot> <tdonohue> So, we wouldn't stop doing that.
[15:55] <DSpaceSlackBot> <tdonohue> As an example, we do have an "Acknowledgements" section *per* release: https://wiki.duraspace.org/display/DSDOC6x/Release+Notes
[15:55] <kompewter> [ Release Notes - DSpace 6.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC6x/Release+Notes
[15:55] <DSpaceSlackBot> <mwood> Come to think of it, @author doesn't show up in apidocs/ by default, so you have to do a bit of work to get authorship out of either the source or git.
[15:55] <DSpaceSlackBot> <tdonohue> That list is generated by Git history
[15:55] <DSpaceSlackBot> <mwood> is a known documentation hawk.
[15:56] <DSpaceSlackBot> <terrywbrady> I need to run to prepare for another meeting. I would like to make another pitch for someone to test my 3 PR's. The following video + tutorial should make it easy to test: https://github.com/terrywbrady/restReportTutorial/blob/master/README.md
[15:56] <kompewter> [ restReportTutorial/README.md at master · terrywbrady/restReportTutorial · GitHub ] - https://github.com/terrywbrady/restReportTutorial/blob/master/README.md
[15:56] <DSpaceSlackBot> <tom_desair> The reason why I added the general “Atmire” author is that some PRs are the result of team discussions and efforts. So it is hard to say “only these two people designed and build this”.
[15:56] <DSpaceSlackBot> <tdonohue> So, the *real* contributors are Git commit history contributors. The `@author` tag has really nothing to do with any of our Contributor lists...it's just there if you want to say "I did this, and feel free to contact me if you have questions"
[15:57] <DSpaceSlackBot> <tom_desair> “So, the *real* contributors are Git commit history contributors.” -> That are the people who wrote the code. Not necessarly the same people that conceived the idea or designed it.
[15:58] <DSpaceSlackBot> <mwood> So, if I call the Atmire general contact number and say "I want to talk to someone who worked on dspace-blah/foo/bar/bas.java" what would be the answer? My guess is "what?"
[15:58] <DSpaceSlackBot> <tom_desair> You check Git
[15:58] <DSpaceSlackBot> <mwood> So why is the doc tag there, then?
[15:59] <DSpaceSlackBot> <hpottinger> the @author tag is just a comment, and has exactly as much "authority" as any other comment, frankly if I needed help with any of our code, I'd ask here
[15:59] <DSpaceSlackBot> <mwood> Is the tag for giving credit, or giving information to someone trying to understand the code? I'd always assumed the latter.
[16:00] <DSpaceSlackBot> <bollini> @mwood imho both
[16:00] <DSpaceSlackBot> <tom_desair> I just doesn’t feel right to put the name of only one or two Atmire employees, and I doesn’t feel right to not add any extra `@author` given the effort we’re putting into this.
[16:00] <DSpaceSlackBot> <tdonohue> The `@author` tag really is a confusing tag...it can mean any number of things. But, I'd also assume either...you can give credit to a designer/idea-maker in the @author tag, or simply say "I wrote this code"
[16:01] <DSpaceSlackBot> <bollini> when you have wide discussion you can always include multiple author tag
[16:02] <DSpaceSlackBot> <bollini> I understood that if a colleague take a customer task and free your time to work on the dspace community you want to reward your colleague but he is not an author
[16:02] <DSpaceSlackBot> Action: tdonohue is starting to wonder if this is why Apache Foundation banned `@author` tags. Too many ideas of how to use them, and too many disagreements ;)
[16:03] <DSpaceSlackBot> <tdonohue> So, I'm realizing we are over time here. It doesn't sound like we have full agreement here. So, my next step may be to bring this to Committers & Developers via email (just to gather more ideas/info).
[16:04] <DSpaceSlackBot> <bollini> on the other hands, if you have had an useful discussion and sharing of idea you should recognize that in the author tag, this also apply for reviewer
[16:04] <DSpaceSlackBot> <tdonohue> After that, we can look to make a decision on `@author` tag policies...that decision would be made by Committers and/or Steering (if Committers cannot come to an agreement)
[16:04] <DSpaceSlackBot> <tdonohue> I'll also ask around in DuraSpace to see if other projects have strict rules on `@author` tags (again, just as a data point)
[16:06] <DSpaceSlackBot> <mwood> http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#@author
[16:06] <kompewter> [ How to Write Doc Comments for the Javadoc Tool ] - http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#@author
[16:06] <DSpaceSlackBot> <tdonohue> So, I'll close up the meeting now (as we are 5 mins over). Expect to see an email thread on dspace-devel later today. All ideas/thoughts/data points are welcome.
[16:06] <DSpaceSlackBot> <mwood> "The @author tag is not critical, because it is not included when generating the API specification, and so it is seen only by those viewing the source code. "
[16:06] <DSpaceSlackBot> <mwood> OK, thanks for organizing it.
[16:07] <DSpaceSlackBot> <tdonohue> Thanks for that data point, @mwood. I'll include that reference in the email thread too
[16:07] <DSpaceSlackBot> <hpottinger> A link to those docs should go into any advice we adopt
[16:08] <DSpaceSlackBot> <tdonohue> Thanks for the interesting discussion all! If folks wish to continue the discussion, you are more than welcome to. But, I'd recommend moving over to dev (as that channel has a broader reach).
[19:09] * dyelar (~dyelar@dyelar.mrb.ku.edu) Quit (Quit: Leaving.)
[20:13] * mhwood (~mhwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:09] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[22:00] * mhwood (~mhwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[22:01] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[22:01] * mhwood (~mhwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[22:42] * tdonohue (~tdonohue@dspace/tdonohue) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.