Timestamps are in GMT/BST.
[0:19] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Remote host closed the connection)
[2:19] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[2:25] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 246 seconds)
[3:18] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 244 seconds)
[3:20] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[4:18] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 260 seconds)
[4:21] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[4:26] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 260 seconds)
[6:22] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[6:26] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 244 seconds)
[6:55] -adams.freenode.net- *** Looking up your hostname...
[6:55] -adams.freenode.net- *** Checking Ident
[6:55] -adams.freenode.net- *** Found your hostname
[6:55] -adams.freenode.net- *** No Ident response
[6:55] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:55] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:55] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:08] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[7:09] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Remote host closed the connection)
[7:10] * Insanity_ (~Insanity@86.39.200.115.static.hosted.by.easyhost.be) has joined #duraspace
[8:45] * cwilper (~cwilper@54.213.30.97) Quit (Ping timeout: 250 seconds)
[10:37] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[11:57] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[12:12] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:06] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) has joined #duraspace
[13:12] * Insanity_ is now known as dmeeus
[15:01] <tdonohue> Hi all, welcome. It's time for our weekly DSpace Developers Meeting. https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-05-18
[15:01] <kompewter> [ DevMtg 2016-05-18 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-05-18
[15:01] <pbecker> hi
[15:01] <tdonohue> Pinging Committers (to wake folks up if they are lurking)... helix84, mhwood, pbecker, terry-b
[15:01] <terry-b> I'm in a meeting, so I will just be lurking today.
[15:01] <mhwood> zzzzz.... Oh, hi.
[15:02] * pbecker woke up more then ten hours ago.
[15:03] <tdonohue> So, the main topic for today is obviously 6.0. Before that, I did post a few reminders on the agenda... the usual one about the New UI Initiative work (and link to overview videos)... and a reminder for topics for our OR16 face-to-face meeting
[15:03] * dmeeus (~Insanity@86.39.200.115.static.hosted.by.easyhost.be) Quit (Remote host closed the connection)
[15:03] <tdonohue> Obviously, if you are attending OR16, I'd recommend attending our face-to-face on Monday. Agenda ideas are already forming at https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-06-13+-+OR16+Meeting But, I'd encourage more ideas for topics
[15:03] <kompewter> [ DevMtg 2016-06-13 - OR16 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-06-13+-+OR16+Meeting
[15:04] <tdonohue> (I cannot guarantee we'll have enough time to cover everything, but I do want to hear what folks are interested in talking about!)
[15:05] <pbecker> After the face-to-face meeting I'll give a workshop about DSpace's Linked Data support within the same room.
[15:05] <tdonohue> In any case, just wanted to post those quick reminders. Please do send topics my way, etc... and/or add your thoughts to the wiki page
[15:05] <tdonohue> Oh, and yes, attend pbecker's DSpace Linked Data / RDF workshop too! :)
[15:05] <pbecker> :-)
[15:06] <tdonohue> So, on to 6.0! Obviously we had a very successful Testathon....lots of diligent testers found lots of bugs for us to fix ;)
[15:07] <tdonohue> As Committers saw, I've already asked other Committers for more support on this. We also do welcome testing, PRs, etc from non-Committers (for anyone lurking or reading this later). We could use your help too!
[15:08] * pmarrone (~pmarrone@200.16.16.13) has joined #duraspace
[15:08] <tdonohue> Today though, it seems like we may want to do some more triage of outstanding issues..to see if we can get volunteers or close PRs
[15:09] <tdonohue> I wonder if we should start at the PR level...my hope is that the more of these we can test and close quickly, the more we can free people up to help fix other issues that still need volunteers
[15:09] <mhwood> Sounds well.
[15:10] <tdonohue> So, here's where we stand with 6.0 PRs...all of them that are currently still open: https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A6.0
[15:10] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A6.0
[15:11] <tdonohue> I'm going to just start at the top and see if we can find testers/reviewers: DSPR#1406
[15:11] <kompewter> [ https://github.com/DSpace/DSpace/pull/1406 ] - DS-3146 NPE when starting a new JSPUI submission with BTE metadata import enabled by PhilipVis
[15:11] <tdonohue> This looks like a small fix. Code looks reasonable. Might need a small test, perhaps?
[15:12] <mhwood> So who here has used BTE?
[15:13] <tdonohue> I haven't, but I found this bug by simply enabling it and trying to run JSPUI. DS-3146
[15:13] <kompewter> [ https://jira.duraspace.org/browse/DS-3146 ] - [DS-3146] NPE when starting a new JSPUI submission with BTE metadata import enabled - DuraSpace JIRA
[15:13] * tmmguimaraes (~tmg@193.137.88.100) has joined #duraspace
[15:13] <tdonohue> So, I could claim this to see if it fixes the issue...still would need another +1 from another developer though (e.g. code review)
[15:14] <tdonohue> I'll assign 1406 to me
[15:14] <pbecker> just got it
[15:14] <mhwood> I read it earlier this morning and just scanned it again. I can give a formal review.
[15:14] <tdonohue> moving along (I'll test 1406 later to validate it)
[15:15] <tdonohue> DSPR#1405
[15:15] <kompewter> [ https://github.com/DSpace/DSpace/pull/1405 ] - DS-3110 DSpace itemupdate does not read local schemas (only dublin_core.xml) by terrywbrady
[15:15] <tdonohue> from terry-b... needs a review/test. Code looks reasonable again
[15:15] <tdonohue> DS-3110
[15:15] <kompewter> [ https://jira.duraspace.org/browse/DS-3110 ] - [DS-3110] DSpace itemupdate does not read local schemas (only dublin_core.xml) - DuraSpace JIRA
[15:15] <mhwood> Agreed/
[15:16] <pbecker> one question
[15:17] <pbecker> the pr checks the start of the filename. People more often change the end of the filename if they want to create a copy that shouldn't be used (something like .bak).
[15:17] <pbecker> Shouldn't we extend the filename check?
[15:17] <pbecker> I think something like metadata_*.xml?
[15:17] <mhwood> Yes.
[15:18] <tdonohue> pbecker: good point. yes
[15:18] <terry-b> If we make that change, we will need to update ItemImport as well
[15:18] <terry-b> I copied the logic from there
[15:18] <tdonohue> terry-b: did this code come from there?
[15:18] <tdonohue> oh, ok
[15:18] <pbecker> then I would suggest to take this as it is and to create a new ticket about that.
[15:19] <pbecker> terry-b: as you know better where this logic is used, would you mind to create a short jira issue about that?
[15:19] <terry-b> sure
[15:19] <tdonohue> thanks terry-b
[15:19] <tdonohue> anyone volunteer to run a quick test on this PR? It looks right, but might be worth a quick test
[15:20] <pbecker> thanks terry-b
[15:22] <tdonohue> no volunteers. Ok, we'll need to find a tester. terry-b, did you test this out, or just copy code from ItemUpdate?
[15:22] <terry-b> I tested locally
[15:23] <tdonohue> ok, good to know (might want to update the PR to note that, and also note where you borrowed this code from)
[15:23] <terry-b> Will do
[15:23] <tdonohue> hopefully that'll help us get this in quickly
[15:23] <tdonohue> moving along
[15:23] <tdonohue> DSPR#1403
[15:23] <kompewter> [ https://github.com/DSpace/DSpace/pull/1403 ] - DS-3169 CC license is not preserved when creating a version of an item by PhilipVis
[15:23] <tdonohue> DS-3169
[15:23] <kompewter> [ https://jira.duraspace.org/browse/DS-3169 ] - [DS-3169] Side bar text at community & sub-community level does not appear on the side - DuraSpace JIRA
[15:24] <tdonohue> hmmm...that's not the right ticket
[15:24] <tdonohue> oh, it's DS-3191
[15:24] <kompewter> [ https://jira.duraspace.org/browse/DS-3191 ] - [DS-3191] CC license is not preserved when creating a version of an item - DuraSpace JIRA
[15:24] <tdonohue> I already gave this a +1, looks obvious
[15:25] <pbecker> I was wondering why you just haven't merged. It is so obvious.
[15:26] <tdonohue> this might have been the last one I reviewed last night (before I left)..may have forgotten ;)
[15:26] <tdonohue> I'll just merge it
[15:26] <tdonohue> done. Next DSPR#1401
[15:26] <kompewter> [ https://github.com/DSpace/DSpace/pull/1401 ] - [DS-3202] OAI-PMH broken on demo.dspace.org by mwoodiupui
[15:27] <tdonohue> mhwood is this still a WIP? It looks small
[15:27] <mhwood> I was trying to remember why it is WIP.
[15:27] <tdonohue> It looks like some obvious checks for null values, which doesn't seem like it should be a WIP, unless I'm missing something
[15:28] <mhwood> I think I ran out of time that day and had not tested it yet.
[15:28] <tdonohue> mhwood, in any case, I gave this a +1. I think this is ready to merge, as soon as you are "done" with it :)
[15:28] <mhwood> OK, will test and merge.
[15:28] <tdonohue> thanks
[15:28] <tdonohue> next, DSPR#1400
[15:28] <kompewter> [ https://github.com/DSpace/DSpace/pull/1400 ] - fixed DS-2751 by checking for null by tmguimaraes
[15:29] <tdonohue> tiny fix..check for a null
[15:29] <tdonohue> Oh, and I see tmmguimaraes is here today. Has this been tested on your end?
[15:29] <tmmguimaraes> there might be another and possible better fix, checking out why that list and null strings, it's weird
[15:30] <tmmguimaraes> *has
[15:30] <tmmguimaraes> I tested it on my end, it worked, tested it on the pre production machine of comum.rcaap.pt
[15:31] <tdonohue> yes, it does seem a bit odd that it'd have null values in the list. but this fix seems tiny and non-controversial (i.e. good enough for now)
[15:31] <pbecker> tmmguimaraes: you mean the ISSNItemExtractor is probably wrong?
[15:32] <pbecker> Actually it is a good question: why does he include null values into the list?
[15:32] <mhwood> Yes, better not to produce nulls in the first place. getISSNs() should also return an empty List if there are no ISSNs.
[15:32] <pbecker> I think we should be careful not to cover up a deeper lying problem....
[15:32] <tmmguimaraes> exactly
[15:33] <pbecker> tmmguimaraes: do you have time to dig in deeper?
[15:33] <tdonohue> So, then the other route is to find all classes implementing ISSNItemExtractor, and ensure they are not adding "nulls" to the getISSNs() list
[15:33] <tmmguimaraes> well, not today, but i might have tomorrow or something
[15:33] <tmmguimaraes> still i think that my small fix should be in untill a better solution is found
[15:33] <tdonohue> Looks like there are only a few classes that would need changing
[15:34] <tdonohue> I'll add a comment to this PR with the details
[15:35] <mhwood> So should we merge this one and have a separate ticket to fix the extractors?
[15:36] <pbecker> tmmguimaraes: where you using the MetadataAuthorityISSNExtractor or the M*V*ISSNExctractor?
[15:36] <tdonohue> If we want to fix this at the source, then maybe we wait and try that first. Then there's no need for this PR to check for nulls in list
[15:36] <pbecker> I think I already have a bold guess of the problem.
[15:36] <pbecker> https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/app/sherpa/submit/MetadataAuthorityISSNExtractor.java#L40
[15:36] <kompewter> [ DSpace/MetadataAuthorityISSNExtractor.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/app/sherpa/submit/MetadataAuthorityISSNExtractor.java#L40
[15:36] <tdonohue> I added a comment to DSPR#1400
[15:36] <kompewter> [ https://github.com/DSpace/DSpace/pull/1400 ] - fixed DS-2751 by checking for null by tmguimaraes
[15:37] <pbecker> expects a metadata value to *always* have a authority value.
[15:37] <pbecker> But most metadata values doesn't.
[15:38] <tdonohue> In any case, it seems like the null checks should happen in the getISSNs() methods
[15:38] <pbecker> two possibilities to solve: either ignore metadata values that misses authority or fall back to their values.
[15:38] <tdonohue> so, lets leave this PR open for now, and see if we can get a better fix. Moving along for now
[15:38] <tdonohue> DSPR#1399
[15:38] <kompewter> [ https://github.com/DSpace/DSpace/pull/1399 ] - DS-3209 AIP Import: Extend accepted handles for supports() by mjmarttila
[15:38] <pbecker> tdonohue: can we just stay here for one more minute?
[15:38] <pbecker> I don't know this part of the code well, but I think we are close to a solution.
[15:39] <tdonohue> pbecker: ok...is there a reason we cannot just add these comments to the PR?
[15:39] <terry-b> We have tested this on our end
[15:39] <tmmguimaraes> pbecker i was using both MetadataValueISSNExtractor and MetadataAuthorityISSNExtractor for different fields
[15:39] <terry-b> 1399
[15:39] <tdonohue> terry-b: could you add a +1 to that PR then? Or did this come from you?
[15:39] <pbecker> I just need an advise if want to fall back or to ingore md fields without authorities.
[15:40] <terry-b> It came from my team
[15:40] <terry-b> There are 2 PR's we submitted because we were unable to perform an AIP restore.
[15:41] <terry-b> These issues will only appear if someone attempts to recreate a test instance from AIP
[15:42] <tdonohue> pbecker: I think we simply need a null check. The issue is nulls are getting into the list, and we need to filter out the nulls
[15:42] <pbecker> tdonohue: thanks
[15:42] <tdonohue> terry-b: thanks, again, it'd be good to note on the PR when you've tested a solution, etc. It's hard to tell otherwise ;)
[15:43] <tdonohue> 1399 code seems reasonable to me
[15:44] <terry-b> Will do
[15:45] <mhwood> 1399 also looks well to me.
[15:46] <terry-b> I added a comment to 1399 and 1396
[15:46] <tdonohue> 1399 looks to just be restoring code from 5.4 which was stripped out (but seems to be needed). So, this looks like one we should get merged for sure
[15:46] <tdonohue> see comments in DS-3209
[15:46] <kompewter> [ https://jira.duraspace.org/browse/DS-3209 ] - [DS-3209] Runtime Exception (Can't Create Identifier) on Items During AIP Restore - Restore Fails - DuraSpace JIRA
[15:46] <pbecker> I check if this should apply to VersionedHandleIdentifierProviderWithCanonicalHandles too.
[15:47] <tdonohue> pbecker: do you want to claim this PR? I already gave it a +1, but if you want to double check, that'd be good
[15:47] <pbecker> I claim it.
[15:47] <tdonohue> thanks!
[15:48] <tdonohue> next up, DSPR#1396 / DS-3140
[15:48] <kompewter> [ https://jira.duraspace.org/browse/DS-3140 ] - [DS-3140] METSRightsCrosswalk NPE During AIP Restore - No Anonymous Read - DuraSpace JIRA
[15:48] <kompewter> [ https://github.com/DSpace/DSpace/pull/1396 ] - DS-3140 METSRightsCrosswalk NPE During AIP Restore - No Anonymous Read by mjmarttila
[15:48] <tdonohue> (the other one from terry-b's team)
[15:48] <terry-b> This was also a 5x (and probably a 4x issue)
[15:49] * hpottinger (~hpottinge@mu-161168.dhcp.missouri.edu) has joined #duraspace
[15:50] <tdonohue> huh. There's some code stripping here... might need to look at this closer
[15:51] <tdonohue> just not sure I understand why so much code was removed... unless it's duplicated elsewhere?
[15:52] <terry-b> Please provide suggestions on this one. We were unable to get this to run without updating the code.
[15:53] <tdonohue> terry-b: I'm not sure I have any suggestions. I'm just noting there's a lot of code removed, and it's seemingly not replaced. It just looks odd, but it's possible a different function duplications that logic (need to look)
[15:53] <tdonohue> *duplicates*
[15:53] <mhwood> Yes, even side-by-side I'm having trouble understanding the changes.
[15:54] <tdonohue> So, if someone on your end could add notes/description, it might help. It's possible we were unnecessarily duplicating logic in this class, and your staff discovered it. But, it's unclear in the "diff". Need to dig in deeper here
[15:55] <tdonohue> I'll add some inline comments. For now, moving along
[15:55] <terry-b> I will ask Mike to add additional notes to this. We anticipated that changes would be needed to the PR.
[15:55] <tdonohue> DSPR#1394
[15:55] <kompewter> [ https://github.com/DSpace/DSpace/pull/1394 ] - DS-3162 all existing export displayed in every user home page by PhilipVis
[15:56] <tdonohue> wow, this is another tiny obvious check for a null
[15:56] <tdonohue> merging it
[15:57] <tdonohue> done
[15:57] <tdonohue> next, DSPR#1389
[15:57] <kompewter> [ https://github.com/DSpace/DSpace/pull/1389 ] - Ds 3175 Testathon XMLUI VIEW14 RSS feeds are empty by PhilipVis
[15:58] <tdonohue> This seems like an easy one to test (just see if RSS feeds now work for XMLUI). Needs a tester
[15:58] <tdonohue> code changes look reasonable at a glance
[16:00] <tdonohue> Ok, I'll see if I can give it a test then if there are no takers
[16:00] <tdonohue> we're now at one hour.
[16:01] <tdonohue> Do folks have time to continue this PR review? I feel like we're making some progress on finding testers or PRs to merge.
[16:01] <mhwood> I can remain.
[16:01] <hpottinger> I'm lurking, can continue to lurk
[16:01] <tdonohue> Or are there any other topics of high priority that anyone wants to be sure we discuss today?
[16:03] <pbecker> like hpottinger: lurking.
[16:03] <tdonohue> ok. so, I'm going to keep going then. I think this is the highest priority thing we can do. I hope some lurkers will still help claim PRs to test though ;)
[16:04] <hpottinger> I'll test 1389
[16:04] <tdonohue> hpottinger, ok, claim it from me then please :) I'll give it to you, and provide a +1 code review
[16:04] <tdonohue> thanks!
[16:05] <hpottinger> I've stolen 1389
[16:05] <hpottinger> can't have it back
[16:05] <tdonohue> haha, feel free. Believe me, I have *plenty* on my plate right now :)
[16:05] <tdonohue> next up, DSPR#1387
[16:05] <kompewter> [ https://github.com/DSpace/DSpace/pull/1387 ] - Ds 2962 Robots.txt disallows site /discovery but not /handle/*/disover by PhilipVis
[16:06] <mhwood> +2, tested
[16:06] <hpottinger> I suspect that may also be the case for me... however, you've caught me on the day I've returned from traveling, and thus I'm likely to volunteer for all sorts of stuff today
[16:06] <tdonohue> this is at +2 already. needs to just be merged it seems
[16:07] <terry-b> I merged it
[16:07] * jm__ (57c568d1@gateway/web/freenode/ip.87.197.104.209) has joined #duraspace
[16:07] <hpottinger> merging stuff! woohoo!
[16:07] <tdonohue> thanks terry-b. Don't forget to close the ticket too, please :)
[16:07] <terry-b> Will do
[16:07] <tdonohue> next up, DSPR#1385
[16:07] <kompewter> [ https://github.com/DSpace/DSpace/pull/1385 ] - DS-3167 empty list of metadataformat in JSPUI and XMLuUI by LuizClaudioSantos
[16:08] <tdonohue> as noted in the PR, the first commit is from a second PR: DSPR#1381
[16:08] <kompewter> [ https://github.com/DSpace/DSpace/pull/1381 ] - DS-3198 - NullPointException in OAIHarvester by LuizClaudioSantos
[16:08] <tdonohue> (But, assuming both of these look good, we can just merge 1381 first)
[16:09] <tdonohue> 1381 looks like an obvious fix to me
[16:10] <hpottinger> 1381 is at +2 now
[16:10] <mhwood> I wonder why configurationService is null.
[16:11] <tdonohue> although, yea...looking at this closer. configurationService isn't initialized?
[16:11] <tdonohue> It looks like it should be initialized in the Constructor but isn't
[16:11] <mhwood> Yes.
[16:11] <tdonohue> https://github.com/LuizClaudioSantos/DSpace/blob/733960ac2448f1110d3ad66f6f0db2cd2f9861c5/dspace-api/src/main/java/org/dspace/harvest/OAIHarvester.java#L118
[16:11] <kompewter> [ DSpace/OAIHarvester.java at 733960ac2448f1110d3ad66f6f0db2cd2f9861c5 · LuizClaudioSantos/DSpace · GitHub ] - https://github.com/LuizClaudioSantos/DSpace/blob/733960ac2448f1110d3ad66f6f0db2cd2f9861c5/dspace-api/src/main/java/org/dspace/harvest/OAIHarvester.java#L118
[16:12] <mhwood> There are four other dereferences.
[16:13] <tdonohue> yep, I see that too. This PR needs fixing. I'll change my comment
[16:14] <hpottinger> deleted my +1, will defer to your judgement on that
[16:14] <tdonohue> These PRs are both "close" but not quite right
[16:15] <hpottinger> do we await the author to fix, or do we fix on our own?
[16:15] <tdonohue> we could fix on our own if someone has time to do it quickly. both seem like obvious bugs, easy to fix.
[16:16] <tdonohue> volunteer?
[16:17] <tdonohue> I added a comment to 1381 noting the necessary change
[16:18] <hpottinger> does the constructor need any *more* cleanup?
[16:18] <tdonohue> hpottinger: not to my knowledge. The obvious failure is that we have a global variable named "configurationService" that *never* gets initialized anywhere in the class
[16:19] <hpottinger> well... if the original author doesn't fix these two PRs, I can look into it later this week
[16:20] <hpottinger> if I keep volunteering for stuff, somebody slap me, OK? :-)
[16:20] <tdonohue> Ok, thanks. Maybe I can find time later as well.
[16:20] <tdonohue> moving along.. DSPR#1383
[16:20] <kompewter> [ https://github.com/DSpace/DSpace/pull/1383 ] - [DS-3201] DIM crosswalk exports only dc metadata by kosarko
[16:21] <tdonohue> tiny, obvious fix to Xpath query in XSLT
[16:21] <mhwood> Yes.
[16:22] <tdonohue> I'm just merging this, it's very obvious
[16:22] <hpottinger> +1
[16:22] <hpottinger> I managed to get you a +1 before you hit merge
[16:23] <tdonohue> next up, DSPR#1382
[16:23] <kompewter> [ https://github.com/DSpace/DSpace/pull/1382 ] - [DS-3179] Collection admin, edit item no authorization to remove file by KevinVdV
[16:24] <tdonohue> Needs testers. KevinVdV fixed the integration test failures
[16:24] <tdonohue> Anyone willing to do some testing as requested by KevinVdV (see his final comment)
[16:24] <tdonohue> ?
[16:24] <hpottinger> ooh ooh me me
[16:25] <hpottinger> how about we see if anyone can beat me to volunteering for stuff?
[16:25] <mhwood> "bitstream is linked to multiple bundles". How is that accomplished?
[16:27] <pbecker> by item level versioning f.e.
[16:27] <mhwood> Ah.
[16:27] <tdonohue> DS-3179 has more info on the root issue as well
[16:27] <kompewter> [ https://jira.duraspace.org/browse/DS-3179 ] - [DS-3179] Collection admin, edit item no authorization to remove file - JSPUI Test Plan Ref COL§ - DuraSpace JIRA
[16:28] <hpottinger> new integration tests that pass... sounds pretty good to me already...
[16:28] * pmarrone (~pmarrone@200.16.16.13) Quit (Remote host closed the connection)
[16:29] <pbecker> did hpottinger already volunteered to test this? Or can I still beat him? ;)
[16:29] <tdonohue> Anyone else also willing to give this a test? I agree with KevinVdV that since this has to do with *removing* content (bitstreams) mainly, we should test this out more. But, the fact it passes Unit & Integration tests is promising
[16:29] <hpottinger> better run, pbecker
[16:29] <pbecker> I'll test this tomorrow!
[16:29] <tdonohue> pbecker: I'd actually like to have multiple testers here :)
[16:29] <tdonohue> thanks, pbecker!
[16:29] <tdonohue> thanks, hpottinger
[16:30] <pbecker> hpottinger will you second me?
[16:30] <hpottinger> sure
[16:30] <pbecker> great
[16:30] <hpottinger> testing PRs in Vagrant-DSpace is kind fun, honestly, I'm looking forward to it
[16:30] <tdonohue> ok, moving along...skipping 1381 (we reviewed that already above). Next is DSPR#1379
[16:30] <kompewter> [ https://github.com/DSpace/DSpace/pull/1379 ] - [DS-3154] Maven release process fails when using Java 8 because of Javadocs errors by mwoodiupui ¡ Pull Request #1379 ¡ DSpace/DSpace ¡ GitHub
[16:31] <tdonohue> oh, this one. It's not ready yet
[16:31] <mhwood> Actually, it's big enough that maybe I should take the WIP off it and start another.
[16:32] <tdonohue> Yea, this is a deep deep pit of JavaDocs issues
[16:32] <tdonohue> Perhaps we should just merge this one (and the one I had started) and keep creating new PRs
[16:32] <mhwood> I think so. Otherwise they'll be too big to review.
[16:33] <hpottinger> how does one review a JavaDocs refactor?
[16:33] <mhwood> Look it over to make sure I didn't break something unrelated?
[16:33] <hpottinger> this almost looks like a "we trust you" kinda thing
[16:34] <tdonohue> hpottinger: it's hard to do so, honestly. We do have to trust the changes look sane
[16:34] <hpottinger> like the "findbugs-a-thon" that grahamtriggs did a few years ago
[16:34] <tdonohue> mhwood: one piece of feedback here though. While I know it's tempting, it looks like you did code refactoring in this PR which claims to just deal with JavaDocs
[16:34] <tdonohue> mhwood: I actually would recommend we try to avoid code refactoring in these types of PRs
[16:35] <tdonohue> (I know it's just so tempting to clean up the code, but it makes it easier to trust/review if you see it's all comment changes *only*)
[16:35] <mhwood> OK, I will resist the temptation.
[16:35] <hpottinger> maybe keep notes, though?
[16:36] <hpottinger> it'll be a long journey, you'll see some exciting things
[16:36] <tdonohue> In some cases, this code will be gone soon enough anyway (UI level code is obviously being replaced by a new UI soonish). So, just realize it also may not be worth the effort too much
[16:37] <mhwood> Yeah, I just hate all those little yellow flags the IDE throws up.
[16:37] <tdonohue> In the case of 1379, I've scanned it. It looks reasonable. Should we just merge it?
[16:37] <mhwood> I'll take the WIP off it. Yes.
[16:39] <hpottinger> validity changes, sometimes you use "theValidity" sometimes "newValidity"...
[16:40] <mhwood> I won't be using either for a while.
[16:40] <tdonohue> I merged it
[16:40] <hpottinger> I belatedly cast a +1
[16:40] <tdonohue> next up, is my massive PR on the same topic: DSPR#1377
[16:40] <kompewter> [ https://github.com/DSpace/DSpace/pull/1377 ] - DS-3154: Fix dspace-services Javadocs and some in dspace-api by tdonohue
[16:41] <tdonohue> This one is *just* Javadocs...it fixes ALL of dspace-services and a tiny portion of dspace-api
[16:41] <tdonohue> And yes, it's massive. But, it's all comment changes, no code changes
[16:41] <hpottinger> I can't quite bring myself to type "by inspection"
[16:42] <tdonohue> Sorry. In the future, these probably should be smaller PRs
[16:42] <mhwood> It's too big for Github to display.
[16:42] <tdonohue> We just have a LOT of JavaDocs issues :(
[16:42] <hpottinger> heh, yup
[16:42] <hpottinger> tdonohue: I trust you
[16:42] <tdonohue> any objections to merging? I guarrantee it's just Javadocs. I was very careful on that
[16:43] <mhwood> OK by me. Set a good example.
[16:43] <terry-b> go for it
[16:43] <tdonohue> merged
[16:44] <hpottinger> gotta run to lunch, sorry to skip out
[16:44] <hpottinger> if you come up with a list of more things that need a volunteer, send them to me?
[16:44] <tdonohue> well, that's *some* JavaDocs issues fixed. :) We'll have to see though if we can achieve them all before 6.0 (if not, we may have to temporarily disable JavaDocs tests in Java 8 until we can fix them all)
[16:44] <tdonohue> hpottinger: sounds good, we'll auto assign you to all PRs ;)
[16:44] <tdonohue> (kidding)
[16:45] <hpottinger> heh, just send me a list, it's the same thing
[16:45] <mhwood> Some of the artifacts have far less trouble. One has none.
[16:45] <tdonohue> next up, DSPR#1373
[16:45] <kompewter> [ https://github.com/DSpace/DSpace/pull/1373 ] - [DS-3170] Allow Password Auth to be enabled for Rest Reports by terrywbrady
[16:45] <pbecker> gotta run for dinner, sorry to skip out. ;-)
[16:45] <tdonohue> (mhwood: yea, but dspace-api is full of JavaDocs issues. I barely made a dent in that one)
[16:45] <terry-b> It will be a fun one for someone to test
[16:46] <tdonohue> sounds like a job for hpottinger to test ;)
[16:46] <pbecker> tdonohue: I can cut the release using java 7 if this helps.
[16:46] <mhwood> I have no idea how many there are in XMLUI, since the toolchain only reports 100 at a time. :-(
[16:46] <pbecker> have to run, see you tomorrow!
[16:46] <tdonohue> pbecker: yes, for 6.0 we might just want to cut the release with Java 7. We'll see how far we get with the JavaDocs issues
[16:46] <pbecker> +1
[16:47] <pbecker> 'bye everyone!
[16:47] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[16:48] <tdonohue> 1373 looks good / reasonable to me... just really needs a tester
[16:49] <tdonohue> a lot of the chnages look to just be code realignment (at a glance)
[16:49] <mhwood> That's what I see.
[16:49] <terry-b> That was the suggestion from our last review
[16:49] <tdonohue> yep, just noting that again out loud :)
[16:50] <tdonohue> I gave a +1, assigned to hpottinger (since it looks easy to test and he expressed interest in things easy to test)
[16:51] <tdonohue> next up, DSPR#1371
[16:51] <kompewter> [ https://github.com/DSpace/DSpace/pull/1371 ] - [DS-3166] bin/make-handle-config script is broken by mwoodiupui
[16:52] <tdonohue> at +1. Some discussion in the PR, but pbecker even noted none of that should stop merging it
[16:52] * jm__ (57c568d1@gateway/web/freenode/ip.87.197.104.209) Quit (Quit: Page closed)
[16:54] <tdonohue> So, the changes here look rather obvious to me. I agree they aren't perfect, but they fix a broken part of the script. The other issues are future ones (upgrading to Handle server 7 which is already a ticket, and creating a windows script)
[16:54] <mhwood> As noted in the PR, probably what we ought to do eventually is stop trying to do this all in shell script.
[16:55] <tdonohue> yes, I can agree with that. This shell script isn't exactly a major feature, it's more of a convenience. But, technically you can do all this using the directions from handle.net instructions
[16:55] <mhwood> Some distro.s like to add the hostname to the loopback address, and others don't, so the current code behaves differently in different installations.
[16:57] <mhwood> It's at +1 now. Anybody wish to throw a +/-1?
[16:57] <tdonohue> I'm wondering if we are the only two left ;)
[16:58] <terry-b> I'm partially here, but I have not digested the issues with this one.
[17:01] <tdonohue> Ok, I flagged this as "quick win". I think this is an obvious fix, but will wait for another +1
[17:02] <tdonohue> I'm going to stop there for today. I have a few other tasks I need to jump to (unfortunately). But, I encourage folks to keep reviewing/testing PRs and adding feedback. We made a nice dent in our list, but there's more to review...and we still have some tickets needing PR volunteers too!
[17:03] <tdonohue> As a reminder to anyone listening/reading. The 6.0 open PRs are at: https://github.com/DSpace/DSpace/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+milestone%3A6.0
[17:03] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+milestone%3A6.0
[17:03] <tdonohue> And the 6.0 Testathon unresolved issues are at: https://jira.duraspace.org/issues/?jql=status%20in%20(Received%2C%20%22Volunteer%20Needed%22)%20AND%20resolution%20%3D%20Unresolved%20AND%20labels%20%3D%20testathon
[17:03] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/issues/?jql=status%20in%20(Received%2C%20%22Volunteer%20Needed%22)%20AND%20resolution%20%3D%20Unresolved%20AND%20labels%20%3D%20testathon
[17:03] <terry-b> tdonohue, I replied to the thread about Collection getParentList(), let me know if you have any suggestions on how to move that issue forward.
[17:04] <tdonohue> Please keep helping us move these along so we can get 6.0 re-tested & out the door! A huge thanks to everyone who has been helping thus far!
[17:04] * dmeeus (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[17:05] * th5 (~th5@unaffiliated/th5) has joined #duraspace
[17:08] * dmeeus (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 244 seconds)
[17:27] * tmmguimaraes (~tmg@193.137.88.100) Quit (Quit: Leaving)
[20:17] * th5 (~th5@unaffiliated/th5) Quit (Remote host closed the connection)
[21:05] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:06] * dmeeus (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[21:10] * dmeeus (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 246 seconds)
[21:56] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[21:59] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) has left #duraspace
[22:08] * hpottinger (~hpottinge@mu-161168.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[23:05] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 250 seconds)
[23:07] * dmeeus (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[23:09] * kshepherd (~kim@wireless-nat-21.auckland.ac.nz) has joined #duraspace
[23:12] * dmeeus (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 250 seconds)
[23:21] * kshepherd (~kim@wireless-nat-21.auckland.ac.nz) Quit (Ping timeout: 240 seconds)
[23:29] * kshepherd (~kim@wireless-nat-21.auckland.ac.nz) has joined #duraspace
[23:47] * kshepherd (~kim@wireless-nat-21.auckland.ac.nz) Quit (Ping timeout: 276 seconds)
[23:47] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[23:59] * dmeeus (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.