Timestamps are in GMT/BST.
[6:33] -verne.freenode.net- *** Looking up your hostname...
[6:33] -verne.freenode.net- *** Checking Ident
[6:33] -verne.freenode.net- *** Found your hostname
[6:33] -verne.freenode.net- *** No Ident response
[6:33] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:33] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:33] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[9:07] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[12:31] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:00] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[13:22] * mikeAtUVa (~md5wz@d-137-54-155-161.dhcp.virginia.edu) has joined #duraspace
[13:55] * mikeAtUVa (~md5wz@d-137-54-155-161.dhcp.virginia.edu) Quit (Quit: Leaving)
[14:06] * hpottinger (~hpottinge@162.104.218.179) has joined #duraspace
[16:57] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[17:36] * hpottinger (~hpottinge@162.104.218.179) Quit (Quit: later, taterz!)
[17:50] * dyelar (~dyelar@129.237.45.105) has joined #duraspace
[18:29] * hpottinger (~hpottinge@162.104.218.179) has joined #duraspace
[18:56] * bollini (57145faf@gateway/web/freenode/ip.87.20.95.175) has joined #duraspace
[19:03] * lap82 (5feee2d6@gateway/web/freenode/ip.95.238.226.214) has joined #duraspace
[19:48] * hpottinger (~hpottinge@162.104.218.179) Quit (Quit: later, taterz!)
[19:57] <tdonohue> Friendly reminder that our DSpace DevMtg starts in a few minutes https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-09-28
[19:57] <kompewter> [ DevMtg 2016-09-28 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-09-28
[20:00] <tdonohue> Hi all, welcome. It's time for our weekly DSpace DevMtg. Agenda at https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-09-28
[20:00] <kompewter> [ DevMtg 2016-09-28 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-09-28
[20:01] <tdonohue> Of course, the primary topics for today will be getting 6.0 and 5.6 out the door.
[20:02] <tdonohue> Before we get into that though, I do want to mention that I have a conflict with our *early* meeting next week (supposed to be at 15UTC). Therefore, I'd like to move the meeting back to 20UTC next week (i.e. the same time as this meeting)
[20:03] <tdonohue> This will mean we'll end up having several 20UTC meetings in a row, but I don't see any way around that (unless I miss the meeting altogether)
[20:03] <tdonohue> any objections or major conflicts with rescheduling next week to 20UTC?
[20:03] <mhwood> No objection from me.
[20:03] <bollini> no objections
[20:04] <tdonohue> Ok, consider it rescheduled then. I'll send out a reminder next week as I always do
[20:05] <tdonohue> Now, on to 6.0 and 5.6. Our ticket list for 6.0 is getting quite small (which is great to see). Might be worth quick updates on 6.0 tickets first..then we'll talk 5.6
[20:05] <tdonohue> We have just 5 issues left on our "Must Have" list: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+status+in+%28Received%2C+%22More+Details+Needed%22%2C+%22Volunteer+Needed%22%2C+%22Code+Review+Needed%22%2C+Accepted%2C+%22Awaiting+Documentation%22%29+AND+priority+in+%28Blocker%2C+Critical%2C+Major%29+AND+fixVersion+%3D+6.0+&src=confmacro
[20:05] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+status+in+%28Received%2C+%22More+Details+Needed%22%2C+%22Volunteer+Needed%22%2C+%22Code+Review+Needed%22%2C+Accepted%2C+%22Awaiting+Documentation%22%29+AND+priority+in+%28Blocker%2C+Critical%2C+Major%29+AND+fixVersion+%3D+6.0+&src=confmacro
[20:05] <tdonohue> starting at DS-3315
[20:05] <kompewter> [ https://jira.duraspace.org/browse/DS-3315 ] - [DS-3315] Update mirage 2's building dependencies (nodejs/npm) - DuraSpace JIRA
[20:06] <tdonohue> This one was just merged...just awaiting minor documentation tweaks
[20:06] <tdonohue> so, nothing to discuss here
[20:06] <tdonohue> next is DS-3311 / DSPR#1513
[20:06] <kompewter> [ https://jira.duraspace.org/browse/DS-3311 ] - [DS-3311] New "healthcheck" feature not functioning - DuraSpace JIRA
[20:06] <kompewter> [ https://github.com/DSpace/DSpace/pull/1513 ] - [DS-3311] Fix healthcheck by isido
[20:07] <tdonohue> I tested this and gave it a +1. Needs another review. pbecker had noted (earlier today in IRC) that we might want to have a tiny followup PR to simply disable pre-3.0 embargo checks in the defautl configs
[20:08] <tdonohue> pbecker had implied he'd be willing to do this, but he's already left for the day (and I can followup with him tomorrow)
[20:09] <tdonohue> nonetheless, I think this PR is still worth merging, as the feature is completely broken without it. Changing the default configs to be "better" can come as a separate followup
[20:09] <bollini> I agree. We should merge it now
[20:09] <mhwood> Yes.
[20:10] <tdonohue> Ok, I'll merge it and ping pbecker in a comment in the JIRA ticket
[20:11] <tdonohue> done
[20:12] <tdonohue> next up.. DS-3310
[20:12] <kompewter> [ https://jira.duraspace.org/browse/DS-3310 ] - [DS-3310] HTTP 500 error in the SWORD v2 interface - DuraSpace JIRA
[20:12] <tdonohue> This one is unreproducible and the reporter has been unresponsive
[20:13] <tdonohue> So, I'd suggest de-scheduling it (removing fix for 6.0)
[20:13] <tdonohue> we'll leave the ticket open for now, but it either has been fixed, or we don't have enough info to reproduce
[20:13] <mhwood> That seems sensible.
[20:13] <bollini> yes
[20:13] <tdonohue> descheduled
[20:14] <tdonohue> next up, DS-2623
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-2623 ] - [DS-2623] Integrity error on file uploads - DuraSpace JIRA
[20:14] <tdonohue> aha, this was the bug already fixed in 6.x. lap82 however has backported it to 5.x, and pbecker reopened it to note that
[20:15] <lap82> pbecker has reopened this issue
[20:15] <tdonohue> pbecker reviewed & tested the PR...as did another user
[20:15] <tdonohue> I suspect this PR is ready to merge for 5.6. I haven't tested it myself, but the code looks reasonable, and I have no objections
[20:16] <tdonohue> the new 5.6 PR is DSPR#1531
[20:16] <kompewter> [ https://github.com/DSpace/DSpace/pull/1531 ] - DS-2623 backport set description in the upload step files by lap82 ¡ Pull Request #1531 ¡ DSpace/DSpace ¡ GitHub
[20:16] <lap82> great!
[20:16] <mhwood> Looks like it is +2?
[20:16] <tdonohue> yes, I think it's ready to merge
[20:16] <mhwood> Now +1
[20:17] <mhwood> Er, +3
[20:17] <lap82> I'm lose this review by pbecker... +4
[20:17] <bollini> I have add also my +1 :)
[20:17] <tdonohue> so, lap82, you are welcome to merge it whenever you are ready
[20:17] <tdonohue> (and re-close the ticket 2623)
[20:17] <lap82> immediately!
[20:17] <tdonohue> thanks :)
[20:18] <tdonohue> Ok, last on our 6.0 "Must Have" list... DS-2604
[20:18] <kompewter> [ https://jira.duraspace.org/browse/DS-2604 ] - [DS-2604] Creative Commons license assignment silently fails in JSPUI - DuraSpace JIRA
[20:18] <tdonohue> DSPR#1526
[20:18] <kompewter> [ https://github.com/DSpace/DSpace/pull/1526 ] - DS-2604 port - DSpace 6.x - from XMLUI to JSPUI the approach to queries Creative Commons service (via REST API) by lap82
[20:19] <tdonohue> I admit, I haven't had a chance to look at this one yet (sorry). But, I know the 5.x version was already approved/merged
[20:20] <tdonohue> does this essentially just need testers?
[20:20] <lap82> yes...
[20:21] <bollini> yes, better if from someone that use the XMLUI
[20:21] <tdonohue> anyone here willing/able to do some testing with XMLUI on this one?
[20:22] <mhwood> The test would be to see that the three bitstreams are all created correctly?
[20:22] <mhwood> And dc.rights, dc.rights.uri?
[20:23] <terry-b3> I am happy to test... I may have questions once I dig into it
[20:23] <bollini> mhwood, we don't store anymore three bitstreams. just the rdf and the two metadata
[20:23] <mhwood> Ah.
[20:23] <lap82> no! the XMLUI approach create only bitstream for rdf
[20:24] <tdonohue> terry-b3: that'd be great if you can test it! Sounds like lap82/bollini already detailed some of what to look for
[20:24] <lap82> and fill the additional information into dc.rights and dc.rights.uri
[20:24] <mhwood> I can try it.
[20:24] <mhwood> Noted.
[20:24] <tdonohue> thanks also mhwood. I think a few testers would be nice, if we can get it. There's a lot of code changes here...so it'd be good to get a few opinions
[20:25] <lap82> thanks mhwood!
[20:25] <terry-b3> mhwood, I added both of us as asignees
[20:25] <mhwood> Thanks terry-b3. I didn't know there could be more than one.
[20:25] <terry-b3> That was a recent github development
[20:25] <tdonohue> That's all that is left on our list of "Must Have" tickets for 6.0!
[20:26] <tdonohue> However, I would also like to highlight DS-3345, as I think this is better to fix in a 6.0 than a 6.1
[20:26] <kompewter> [ https://jira.duraspace.org/browse/DS-3345 ] - [DS-3345] "Missing" migration when upgrading 5.6 -> 6.0 - DuraSpace JIRA
[20:27] <tdonohue> as mhwood noted in that ticket, our fix for DS-3097 (from bollini) added two migrations, when we might only need *one*
[20:27] <kompewter> [ https://jira.duraspace.org/browse/DS-3097 ] - ('Unexpected error:', <type 'exceptions.AttributeError'>)
[20:27] <mhwood> Oh, yes, I thought that might deserve a higher priority but was unsure how high to go.
[20:27] <tdonohue> I'm going to bump it up to "major" priority, mhwood, as I think we minimally need to make a *decision* (if not a code change to migrations)
[20:27] <mhwood> OK, thanks!
[20:28] <tdonohue> Does anyone have time to investigate 3345? mhwood offers what sounds reasonable to me. We may be able to simply delete the "V6.0" migration, and forward-port the "V5.6" one over to "master"
[20:29] <mhwood> It's not even a port; just copy it.
[20:29] <bollini> yes, it makes sense
[20:29] <tdonohue> mhwood: true
[20:30] <tdonohue> So, I think we just need a volunteer to create a PR that we can test/verify. IIRC, this issue was encountered during a 5.x -> 6.x test upgrade
[20:30] <mhwood> pbecker noted it today on IRC.
[20:30] <bollini> I can do that tomorrow
[20:31] <tdonohue> thanks bollini!
[20:31] <mhwood> Thanks!
[20:31] <tdonohue> Ok. So, now I'd like to open the floor a bit. Are there other high priority tickets (for 6.0 or 5.6) to discuss?
[20:32] <terry-b3> https://github.com/DSpace/DSpace/pull/1537
[20:32] <kompewter> [ DS-3321 Allow AIP Import of Item with Embargo Date in the Past by terrywbrady · Pull Request #1537 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1537
[20:32] <terry-b3> https://github.com/DSpace/DSpace/pull/1536
[20:32] <kompewter> [ [DS-3322] Prevent concurrent modification exception in Undo Bulk Ingest by terrywbrady · Pull Request #1536 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1536
[20:33] <tdonohue> thanks terry-b3...looks like you've been busy today :)
[20:33] <mhwood> Just one more thing: we all need to keep firmly in mind that migrations are ordered and cumulative. If I'd been thinking straight, I should have spotted this earlier.
[20:33] <tdonohue> mhwood++
[20:33] <terry-b3> And this one from last week https://github.com/DSpace/DSpace/pull/1511
[20:33] <kompewter> [ [DS-3312] Prevent mvn error on xsl override by terrywbrady · Pull Request #1511 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1511
[20:34] <tdonohue> terry-b3: PR 1537 looks pretty small...just catches the error to ignore it. Seems reasonable
[20:35] * tdonohue notes...it'd be good for each of us to do a quick review of these PRs and add notes to the PRs themselves. These mostly look pretty small
[20:35] <terry-b3> The only risk I see is if someone improperly formatted a lift date ... it could go through without the user noticing the error
[20:36] <tdonohue> I gave a +1 to 1536
[20:37] <mhwood> So did I
[20:37] <tdonohue> 1511 also looks obvious to me
[20:39] <mhwood> Yes.
[20:39] <tdonohue> looks like 1536 and 1511 are already at +2
[20:40] <tdonohue> so it's really just 1537. I agree, terry-b3, it would also ignore improperly formatted lift dates. Not sure if there's any other way to achieve this bug fix though (off top of my head)
[20:40] <terry-b3> The other approach would be to throw a different exception for the lift date in the past. Or move that check.
[20:40] <terry-b3> I am not sure how valuable the effort would be
[20:41] <mhwood> Yes, I was just thinking that EmbargoDatePassed could be a separate exception.
[20:42] <mhwood> Or setEmbargo could take a boolean to say whether we care about passed dates. This *is* restoring from backup, after all, and the rules are different.
[20:43] <mhwood> (Or just have a new method restoreEmbargo.)
[20:43] <terry-b3> I like the 3rd option best.
[20:44] <terry-b3> (restoreEmbargo)
[20:44] <terry-b3> if you all concur, I will make the change
[20:44] <tdonohue> So, I notice that setEmbargo *does* have some comments about *restoring* items from Backup... I wonder if it's actually got a bug here
[20:44] <tdonohue> https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/embargo/EmbargoServiceImpl.java#L86
[20:44] <kompewter> [ DSpace/EmbargoServiceImpl.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/embargo/EmbargoServiceImpl.java#L86
[20:45] <tdonohue> I'd lean towards looking closer at setEmbargo code (seems to imply it should support restoration). But, if that's not possible, a restoreEmbargo() method seems fine to me
[20:45] <mhwood> I was just guessing that there are calls where we *do* care about passed dates.
[20:46] <terry-b3> I will look at it more closely and revise the PR. Thanks for the reviews on these
[20:46] <tdonohue> so, it seems like we have a good direction / next step for 1537 then.
[20:47] <tdonohue> Do we want to talk schedule for a moment? how is 5.6 looking, lap82? anything you need?
[20:48] <lap82> no, I think that after https://jira.duraspace.org/browse/DS-3346 I can release the 5.6
[20:48] <kompewter> [ https://jira.duraspace.org/browse/DS-3346 ] - [DS-3346] Remove use of deprecated method setIgnoreAuthorization in favour of turnOff/restore - DuraSpace JIRA
[20:48] <kompewter> [ [DS-3346] Remove use of deprecated method setIgnoreAuthorization in favour of turnOff/restore - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3346
[20:49] <lap82> And e
[20:50] <tdonohue> I recall seeing a small bug posted by helix84 over in #dspace regarding 5.6... is that part of 3346?
[20:50] <lap82> and helix84 reported into dspace channel a problem with a migration from 5.4 to 5.6 ... I investigate
[20:50] <tdonohue> excellent. Sounds good then
[20:50] <lap82> I hope that 3346 resolve the issue encoutered by helix84
[20:51] <tdonohue> Please let us know if you end up needing other support/help in testing, etc. I may be able to find a little time this week... next week might be tougher for me though
[20:52] <lap82> ok thanks all... I try to close tomorrow the release
[20:52] <tdonohue> So, on to the 6.0 schedule. I feel like we are *very close* to being ready for 6.0. Which means it might be time to set a target date and do some final testing (maybe even have a few people test the upgrade with a copy of some "production" data)
[20:53] <tdonohue> There are a handful of tickets that still need a little work...but as far as I see, they all look doable this week (i'd hope)
[20:54] <tdonohue> That means we may be able to aim for 6.0 final in one of the first few weeks of Oct (either next week, or week of Oct 10-14)
[20:55] <mhwood> Should we rule no more 6.0 PRs unless they are Blocker?
[20:56] <tdonohue> The only "catch" here is that.. unfortunately, my own DSpace time may be a little less over the next week or so. So, I'm going to need to find someone who can lead the release, and I can gladly consult along the way and/or help with the 6.0 announcement.
[20:56] <bollini> yes, we need to give away the 6.0 to (re)start the work on the new UI!
[20:56] <tdonohue> mhwood: good point. Perhaps we should aim for an RC4 either on Friday or early next week. THEN we say "this is it, unless we see any blockers"
[20:58] <tdonohue> RC4 also gives us one last "testable" version which we can put in peoples hands for ~one week...so they can help do final tests of the upgrade.
[20:58] <mhwood> Yes, quite a bit has gone in since RC3, we need another.
[20:59] <tdonohue> I'd like to see RC4 happen after we've *closed* all the remaining PRs related to "Must Haves". Then, we do 6.0 Final about 1 week later (assuming no blockers appear)
[21:00] <tdonohue> So, I could possible do an RC4 on Friday (if everything is ready by then). Otherwise, I'd need to hand RC4 over to someone else next week likely.
[21:00] <tdonohue> And, I'll likely need to find another volunteer to "cut" the 6.0 Final release
[21:00] <mhwood> I will see if I can find some time to do one of those.
[21:01] <mhwood> Unless someone else would be disappointed to miss the opportunity.
[21:02] <tdonohue> In any case, that means I'd propose our schedule to be... RC4 this Fri, Sept 30 (assuming all PRs are merged by then). Then, 6.0 Final sometime during the week of Oct 10-14 (needs a volunteer to cut it)
[21:02] <tdonohue> mhwood: if you want to take RC4 it'd be an easy one to "give a try". I'll be around to help as needed.
[21:03] <mhwood> I'll try to clear some time.
[21:03] <tdonohue> Then I can find a volunteer for 6.0 Final during the week of Oct 10-14
[21:03] <tdonohue> Does this schedule sound reasonable to everyone?
[21:03] <mhwood> Assuming no big surprises, yes.
[21:03] <terry-b3> It sounds good to me
[21:04] <tdonohue> Again.. RC4 : Fri, Sept 30 (hopefully). 6.0 Final: Week of Oct 10
[21:04] <tdonohue> excellent. I'll update our 6.0 Release Plan then with those details. We'll check in via IRC...and at our meeting next week.
[21:04] <mhwood> Noted.
[21:05] <mhwood> OK, I must dash now. 'bye all!
[21:05] <tdonohue> Again, a reminder, next week's meeting will ALSO be at 20:00UTC (same time as this week), as I have a scheduling conflict with the earlier time
[21:05] <tdonohue> Thanks all! We'll talk to you on IRC and/or next week
[21:05] <lap82> ok! thank you! bye bye
[21:05] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:07] * lap82 (5feee2d6@gateway/web/freenode/ip.95.238.226.214) Quit (Quit: Page closed)
[21:10] * bollini (57145faf@gateway/web/freenode/ip.87.20.95.175) Quit (Quit: Page closed)
[21:59] * tdonohue (~tdonohue@dspace/tdonohue) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.