Timestamps are in GMT/BST.
[0:01] * kshepherd2 (~kim@n119237205199.netvigator.com) Quit (Ping timeout: 240 seconds)
[0:01] * kshepherd2 (~kim@n119237205199.netvigator.com) has joined #duraspace
[0:08] * kshepherd2 (~kim@n119237205199.netvigator.com) Quit (Ping timeout: 252 seconds)
[5:35] * kshepherd2 (~kim@210.177.145.245) has joined #duraspace
[6:05] * kshepherd2 (~kim@210.177.145.245) Quit (Ping timeout: 276 seconds)
[6:05] * kshepherd2 (~kim@210.177.145.245) has joined #duraspace
[6:48] -leguin.freenode.net- *** Looking up your hostname...
[6:48] -leguin.freenode.net- *** Checking Ident
[6:48] -leguin.freenode.net- *** Found your hostname
[6:48] -leguin.freenode.net- *** No Ident response
[6:48] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:48] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:48] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[9:16] * aboutGod (~aboutGod@static-72-66-66-50.washdc.fios.verizon.net) has joined #duraspace
[9:21] * aboutGod (~aboutGod@static-72-66-66-50.washdc.fios.verizon.net) has left #duraspace
[12:14] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:19] * pbecker (~pbecker@ubwstimac016.ub.tu-berlin.de) has joined #duraspace
[12:20] * pbecker (~pbecker@ubwstimac016.ub.tu-berlin.de) Quit (Client Quit)
[12:21] * pbecker (~pbecker@ubwstimac016.ub.tu-berlin.de) has joined #duraspace
[12:27] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has joined #duraspace
[14:13] * vtkeithg (~vtkeithg@vtkeithg.lib.vt.edu) has joined #duraspace
[14:47] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has joined #duraspace
[15:01] <tdonohue> Hello all! It 15UTC and time for our weekly DSpace Developers Meeting. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-06-04
[15:01] <kompewter> [ DevMtg 2014-06-04 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-06-04
[15:01] <hpottinger> small group today
[15:02] <tdonohue> First off, a few quick announcements.
[15:02] <tdonohue> There will be NO IRC developers meeting next Weds (June 11), as many of us will be at OR14 in Helsinki
[15:03] <tdonohue> If you *will* be in Helsinki at OR14, there will instead be a face-to-face meeting on Monday (which I've mentioned before). The agenda for that meeting is now up at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-06-09+-+OR14+Meeting
[15:03] <kompewter> [ DevMtg 2014-06-09 - OR14 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-06-09+-+OR14+Meeting
[15:04] <tdonohue> 5.0 Release Team members: We now have two RT members. We are still looking for a few more..so, get in touch if you are interested!
[15:05] <hpottinger> and remember, we decided community members can join the RT, so, if you're interested, do let us know
[15:06] <tdonohue> That's it for the quick announcements... We are a bit of a "small group" today, but I suspect part of that is that OR14 is next week (and folks may be prepping for presentations, posters. etc)
[15:07] <tdonohue> Good point, hpottinger. If there is a non-Committer interesting in joining the 5.0 Release Team, you are also welcome. You'd work with Committers to help plan out the Release, etc. Get in touch if you are interested.
[15:08] * tdonohue also notes...I have a "hard stop" at 16:00UTC. I have another meeting then. So, I'm going to need to leave right at 1 hour
[15:08] <tdonohue> The agenda is a bit light today. Again, mostly wanting to do some "status checks", especially on 3.3 which seems "almost complete": https://jira.duraspace.org/browse/DS/fixforversion/11841
[15:08] <kompewter> [ DSpace: 3.3 - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS/fixforversion/11841
[15:09] <pbecker> If there is time left, I would like to talk about deletion of EPerson.s
[15:09] <hpottinger> same here, I have a field trip with my daughter's kindergarden class I have to run off to right after this meeting
[15:09] <tdonohue> pbecker: yea, I think we should have time in a bit
[15:09] <pbecker> would be great. :-)
[15:10] <tdonohue> Regarding 3.3: should we schedule this for just *after* OR14? E.g. June 19th or 20th? It seems nearly ready, but I'd hate to release while everyone is at OR14
[15:10] <mhwood> 3.3 is waiting on me getting my Oracle environment arranged to test DS-2013. Difficult to have more than one set of tables with the same names, unlike most other RDBMSs I know.
[15:10] <kompewter> [ https://jira.duraspace.org/browse/DS-2013 ] - [DS-2013] JSPUI with Oracle DB - Browse items with THUMBNAILS unimplemented - DuraSpace JIRA
[15:11] <mhwood> Yes, I see your timing argument. (Gives me more time to do the testing, too. :-)
[15:12] <hpottinger> mhwood: you just need a new "schema" (which is what Oracle calls users)
[15:12] <tdonohue> So, does June 19th or 20th make sense for 3.3? That'd get that one done...then we can (hopefully) work to wrap up 4.2 in very late June or early July. I'm hoping that post-OR14, we all may have more time (self included) for the final 4.2 push.
[15:13] <hpottinger> late June would be my preference, I have a vacation scheduled for early July
[15:13] <mhwood> That last part is what took so much research. Other products' schemas actually *contain* tables and are part of the tables' names. Got this difference through my head now and will create another user (*sigh*).
[15:14] <hpottinger> yeah, it's dumb, mhwood, I hear ya.
[15:14] <mhwood> Yes, dates for 3.3 sound okay.
[15:15] <mhwood> It's not too soon to test the 3_x branch if you are interested in an issue that is already included.
[15:15] <hpottinger> +1 testing of either maintenance branch
[15:15] <mhwood> I need to bring the 3_x release page up to date.
[15:16] <tdonohue> excellent. I'll put the 3.3 dates on my own calendar as well. I agree that, with 4.2, I'd prefer to try and get it done in late June...if we can push that quickly post-OR14.
[15:17] <tdonohue> Ok. Any other status notes on 3.3 or 4.2? Obviously if anyone has time to grab a ticket (esp. for 4.2) or do some extra testing, it'd help ensure we can get these released in June!
[15:19] <tdonohue> Ok, not hearing anything else...so, we'll move on to other topics...
[15:19] <hpottinger> I don't have a status note, but maybe now is an OK time to talk about self-merging small changes?
[15:20] <tdonohue> hpottinger: go ahead. :)
[15:20] <hpottinger> it's just, leading up to release deadlines, we always find ourselves with handfuls of PRs to review
[15:21] <hpottinger> and we almost always decide to trust small PRs, especially ones from committers, and just merge them
[15:21] <hpottinger> and, prior to our migration to GitHub, it was very commong for commiters to just merge small changes with Subversion
[15:21] <hpottinger> but, with GitHub's baked-in review step... we pause now
[15:22] <tdonohue> I agree. In general, if changes are small / minor, and especially if you've thoroughly tested those minor changes, Committers please feel free to *merge your own changes* to "master". As hpottinger mentions, it leaves less work for the Release Team...and those minor changes will be thoroughly tested during our next Testathon.
[15:23] <mhwood> When I have high confidence, I'll only let one of my PRs sit in review state for a week or so, then just pull it.
[15:23] <hpottinger> I am hoping to encourage my fellow committers to push their own merge button :-) Or, if there is truly a concern about the change, and you need a reviewer, please chase down a fellow committer (perhaps one who owes you a beer or two) and ask them to review it on your behalf.
[15:24] <tdonohue> i.e. leaving a ton of "minor changes" in open PRs means that the Release Team has a lot more to dig through during the 5.0 review process... minor changes (typos, spelling, obvious bugs, tiny tweaks) should just be merged (you are welcome to wait for a week if you want, like mhwood mentions)
[15:25] <tdonohue> I realize we're a small group here today though...so hopefully other Committers are reading these logs later on :)
[15:25] <pbecker> can we go ahead with the deletion of EPersons?
[15:25] <tdonohue> With that, we'll go ahead and move along to other topics now
[15:25] <tdonohue> pbecker had noted that he wanted feedback on "deletion of EPersons". See this dspace-devel email: http://dspace.2283337.n4.nabble.com/Deletion-of-EPersons-with-submitted-Item-td4673220.html
[15:25] <kompewter> [ DSpace - Devel - Deletion of EPersons with submitted Item ] - http://dspace.2283337.n4.nabble.com/Deletion-of-EPersons-with-submitted-Item-td4673220.html
[15:26] <pbecker> tdonohue: thanks for the link
[15:28] <pbecker> I think everything important is in the mail. We have to delete EPersons, even those how submitted Items. DSpace currently don’t want to delete those EPersons and I don’t see any reason for this behaviour.
[15:28] <tdonohue> So, my own opinion...I think this *would* be of interest to others, and would be a good addition to DSpace. It probably is a rather significant change (and it'd need some thorough testing)...but it looks like pbecker has started a good brainstorm of how it might be done
[15:29] <tdonohue> (I've heard of other institutions also being frustrated about this limitation)
[15:30] <mhwood> This seems sensible to me as well.
[15:30] <tdonohue> Just a quick question though... are you required to *delete* the EPerson/DSpace account? Or is *disabling it* also a possible solution? (Just curious, cause disabling might be easier to do quickly)
[15:31] <pbecker> We are required to *delete* them.
[15:31] <mhwood> Well, you can disable an EPerson right now. But it keeps personal information (phone, email, etc.) that could be stolen.
[15:31] <pbecker> We are not allowed to store data as their name or email address, even if the mail address does not exist anymore.
[15:32] <pbecker> only exception is to store bibliographic information, so we wouldn’t have to touch the provenance data.
[15:32] <pbecker> I think there are two points left, we should talk about:
[15:32] <tdonohue> Ok, just wanted to check to better understand the requirements. I think DSpace probably should allow this deletion of Epersons idea...but I was just curious about the policies :)
[15:33] <pbecker> It was the first idea I had, when I heared about it. ;-)
[15:33] <hpottinger> so, deleting an ePerson is necessary to remove the e-mail address, but the e-mail address is the actual concern, correct?
[15:34] <pbecker> We have to remove „the account“ and are „not allowed to store the data anymore".
[15:34] <pbecker> But we can safe the data that is part of the bibliographic discription of an Item.
[15:34] <pbecker> So the provenance data shoudln’t be a problem.
[15:34] <tdonohue> makes sense
[15:35] <mhwood> So, these two points?
[15:36] <pbecker> I currently have two questions: 1) Are there any reasons to keep unsubmitted workflow Items? 2) How to handle the situation were a workflow task is put back in the pool but no other person ist part of the „pool-team"?
[15:37] <pbecker> s/were/where
[15:37] <kompewter> pbecker meant to say: I currently have two questions: 1) Are there any reasons to keep unsubmitted workflow Items? 2) How to handle the situation where a workflow task is put back in the pool but no other person ist part of the „pool-team"?
[15:37] <mhwood> There has been discussion of empty workflow groups in connection with "special groups". (Was that you as well?)
[15:37] <pbecker> yes, it was me as well. ;-)
[15:37] <tdonohue> 1) no. Those are associated with the acccount, so unsubmitted items should be removed with the account
[15:37] <pbecker> okay, so there is already a ticket for this.
[15:37] <tdonohue> 2) mhwood is right...sounds related to the other ticket
[15:38] <pbecker> great.
[15:38] <pbecker> So I’m going on a two weeks vacation as of tomorrow, but my collegues will start working on this. As soon as I am back, I will create a ticket in jira.
[15:39] <mhwood> Putting a workflow item back in the pool should be no problem. The problem is how DSpace notifies an administrator that items cannot proceed through workflow.
[15:40] <pbecker> I’ll have a look on the hole workflow proccess. G.e. it might be good, to inform other administrators that a task is going back to the pool….
[15:41] <tdonohue> yea, I agree. Anytime you delete an account, we'd probably want to inform the Administrator of what changes will happen (e.g. a few unsubmitted items may be deleted, a task may go back into the pool, etc.)
[15:41] <mhwood> Yes, if a step can resolve email addresses, they should be notified when an item returns to the pool. Otherwise send to the site admin.
[15:42] <pbecker> okay, thanks for your feedback!
[15:43] <tdonohue> pbecker: thanks for all your hard work on investigating & fixing these various issues!
[15:43] <pbecker> :-)
[15:44] <tdonohue> So, it looks like we have about 15mins left here. Any other topics to bring up? Or anything that anyone feels I should be sure to bring up with developers at OR14?
[15:45] <hpottinger> early PRs for 5.0, please, and bring the docs, too
[15:45] <tdonohue> good point!
[15:47] <hpottinger> if you need help with the docs, we can totally help, just push your feature branch to your fork on github and send a link so we can tinker with it.
[15:49] <mhwood> Yes, although the more you can set down in advance, no matter how unpolished or incomplete, would be helpful.
[15:50] <tdonohue> And, a reminder to anyone who is reading this later. Docs can be added directly to https://wiki.duraspace.org/display/DSDOC5x (Or you are welcome to just create a page in "DSpace" wiki that we'll move over once the PR is merged)
[15:50] <kompewter> [ DSpace 5.x Documentation - DSpace 5.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC5x
[15:52] <tdonohue> So, mhwood & hpottinger...we'll miss you both next week at OR14! But, we'll try to take good notes at the face-to-face meeting...and let us know if you have questions/comments on the agenda topics, etc.
[15:52] <mhwood> Thank you.
[15:53] <hpottinger> I'd be up for a google hangout if anyone wants to do that from the meeting
[15:53] <tdonohue> hpottinger: you sure about that? The Face-to-face meeting starts at 9:00am in Helsinki (1:00am CT)
[15:54] <tdonohue> I don't expect either one of you wants to be up in the middle of the night, just for a meeting :)
[15:54] <hpottinger> sure, sounds like fun!
[15:56] <tdonohue> Ok, as we don't seem to have anything else pressing to discuss, I'd like to end this meeting early. I have another meeting in <4mins to run off to. Talk to you all again in a few weeks!
[15:57] <mhwood> Thanks.
[15:57] <hpottinger> Safe travels to all you jet-setters
[15:57] <mhwood> Seconded.
[15:58] <pbecker> thanks for the feedback again. bye.
[15:59] <hpottinger> and somebody who will be there, log your notebook into G+, OK? I'm not staying up Sunday night just so I can see a bunch of yellow lights
[15:59] * pbecker (~pbecker@ubwstimac016.ub.tu-berlin.de) has left #duraspace
[16:00] <tdonohue> hpottinger: you're serious? You might want to ping someone specifically on that. My laptop will likely be projecting stuff
[16:00] <tdonohue> pick someone from attendees list: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-06-09+-+OR14+Meeting
[16:00] <kompewter> [ DevMtg 2014-06-09 - OR14 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-06-09+-+OR14+Meeting
[16:03] <hpottinger> I'm serious, I'll miss you all, and I don't mind staying up late
[16:11] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has left #duraspace
[17:02] * tdonohue1 (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has joined #duraspace
[17:02] * tdonohue2 (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has joined #duraspace
[17:04] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) Quit (Ping timeout: 240 seconds)
[17:06] * tdonohue1 (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) Quit (Ping timeout: 252 seconds)
[17:26] * tdonohue2 is now known as tdonohue
[20:58] * vtkeithg (~vtkeithg@vtkeithg.lib.vt.edu) Quit (Quit: vtkeithg)
[21:00] * kshepherd2 (~kim@210.177.145.245) Quit (Ping timeout: 255 seconds)
[21:05] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[22:14] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has left #duraspace
[22:26] * kshepherd2 (~kim@210.177.145.245) has joined #duraspace
[23:23] * kshepherd2 (~kim@210.177.145.245) Quit (Ping timeout: 265 seconds)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.