Timestamps are in GMT/BST.
[0:36] * Dylan (~Dylan@85.234.195.109.static.edpnet.net) Quit (Remote host closed the connection)
[0:36] * Dylan (~Dylan@85.234.195.109.static.edpnet.net) has joined #duraspace
[0:41] * Dylan (~Dylan@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 260 seconds)
[4:38] * Dylan (~Dylan@85.234.195.109.static.edpnet.net) has joined #duraspace
[4:42] * Dylan (~Dylan@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 260 seconds)
[6:39] * Dylan (~Dylan@85.234.195.109.static.edpnet.net) has joined #duraspace
[6:44] * Dylan (~Dylan@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 260 seconds)
[6:51] -card.freenode.net- *** Looking up your hostname...
[6:51] -card.freenode.net- *** Checking Ident
[6:51] -card.freenode.net- *** Found your hostname
[6:51] -card.freenode.net- *** No Ident response
[6:51] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:51] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:51] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:23] * Dylan (~Dylan@85.234.195.109.static.edpnet.net) has joined #duraspace
[9:01] * tmmguimaraes (~tmg@193.137.88.100) has joined #duraspace
[12:00] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[12:06] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[12:15] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:07] * Dylan (~Dylan@85.234.195.109.static.edpnet.net) Quit (Remote host closed the connection)
[13:07] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) has joined #duraspace
[13:08] * Dylan (~Dylan@86.39.200.115.static.hosted.by.easyhost.be) has joined #duraspace
[13:34] * Dylan_ (~Dylan@85.234.195.109.static.edpnet.net) has joined #duraspace
[13:36] * Dylan (~Dylan@86.39.200.115.static.hosted.by.easyhost.be) Quit (Read error: Connection reset by peer)
[14:46] * hpottinger (~hpottinge@mu-161168.dhcp.missouri.edu) has joined #duraspace
[14:58] * Dylan_ (~Dylan@85.234.195.109.static.edpnet.net) Quit (Remote host closed the connection)
[14:58] * Dylan (~Dylan@85.234.195.109.static.edpnet.net) has joined #duraspace
[15:00] <tdonohue> Hello all, and welcome. It's time for our weekly DSpace Developers Meeting. Agenda at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-07-13
[15:00] <kompewter> [ DevMtg 2016-07-13 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-07-13
[15:01] <hpottinger> greetings
[15:01] <tdonohue> So, as usual, today is all about 6.0 :)
[15:02] <hpottinger> I have a question about the new UI project, but I'll save it for the end
[15:02] <tdonohue> Let's do a quick role call.... hpottinger is here...how about mhwood, helix84, pbecker, terry-b?
[15:02] <mhwood> Here!
[15:02] <tdonohue> hpottinger: if it's a quick question, we can tackle it quickly now. I suspect most of today will be JIRA/PR review (and those tend to go long)
[15:03] <hpottinger> OK, I'm just wondering if there's a plan for when we'll "rebase" the new UI on the 6x REST-API?
[15:03] * Dylan (~Dylan@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 272 seconds)
[15:05] <tdonohue> hpottinger: well, all we have right now is a "proof-of-concept". It's not the "new UI", but we'll probably start building from it at some point. Are you talking about rebasing this project? https://github.com/DSpace-Labs/angular2-ui-prototype
[15:05] <kompewter> [ GitHub - DSpace-Labs/angular2-ui-prototype: An Angular2 (https://angular.io/) prototype UI for DSpace ] - https://github.com/DSpace-Labs/angular2-ui-prototype
[15:05] <hpottinger> Sorry, the agenda refers to it as "New UI Initiatiave"
[15:06] <tdonohue> to be clear, by calling this a "proof-of-concept", I actually mean that it's not necessarily what the "new UI" will even look like, and we may decide to rebuild parts of it (as we were learning Angular2 at the time we built it, it may not be perfect)
[15:06] <hpottinger> Oh, I see the top bullet point "next phase won't begin until 6.0 is released"
[15:06] <tdonohue> But, at this point in time we are "held back" by the fact that 6.0 is not out the door, and I cannot do both of these simultaneously
[15:07] <tdonohue> So, yes, once 6.0 is out the door, we'll move development over to the New UI Initiative (on Angular2)
[15:07] <hpottinger> so, general plan "focus on 6, *then* get the prototype to run on a non-shifting REST-API"
[15:08] <tdonohue> correct
[15:08] <hpottinger> got it, that helps, thanks
[15:09] <tdonohue> So, back to 6.0 stuff. I feel like our momentum on 6.0 has stalled a bit in recent weeks. Not seeing much activity on voting on or merging PRs... so, I'd like to see if we can find a way to kickstart that again
[15:10] <tdonohue> So, one way to try to do that, might be to take our list of 6.0 "Must have" tickets, and look directly at those that are in the "Code Review Needed" status...see if we can get some momentum on those tickets specifically, and hope it carries over into others
[15:11] <tdonohue> Here's that list in JIRA: https://jira.duraspace.org/issues/?jql=project%20%3D%20DS%20AND%20status%20%3D%20%22Code%20Review%20Needed%22%20AND%20priority%20in%20(Blocker%2C%20Critical%2C%20Major)%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%206.0
[15:11] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/issues/?jql=project%20%3D%20DS%20AND%20status%20%3D%20%22Code%20Review%20Needed%22%20AND%20priority%20in%20(Blocker%2C%20Critical%2C%20Major)%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%206.0
[15:11] * pbecker jumps in a little bit late, greets everyone around here.
[15:11] <hpottinger> DSPR#1449 is one vote away from removing a blocker from every workday for me from 23UTC and 24UTC
[15:11] <kompewter> [ https://github.com/DSpace/DSpace/pull/1449 ] - [DS-3217] fix more than one test by hardyoyo
[15:12] <tdonohue> ok, we can start there, hpottinger, even though it's not on that above list (if it will help your momentum!) :)
[15:13] <tdonohue> The code in 1449 looks good to me, and it's just test fixes. Honestly, let's just merge this. I'll add a +1
[15:13] <hpottinger> it will, DS-3217 kinda took the wind out of my sails yesterday
[15:13] <kompewter> [ https://jira.duraspace.org/browse/DS-3217 ] - [DS-3217] testGetCurrent fails if run from 23 UTC to 24 UTC - DuraSpace JIRA
[15:14] <tdonohue> I added my +1
[15:14] <hpottinger> thanks, tdonohue, it's at +2, shall I merge?
[15:14] <tdonohue> yes please
[15:15] <tdonohue> (and close the ticket)
[15:15] <hpottinger> closed
[15:15] <tdonohue> Ok, back to our list of JIRA tickets (see the long link above)... gonna start at the top
[15:16] <tdonohue> DS-3263 / DS-3262 ... both fixed by DSPR#1459
[15:16] <kompewter> [ https://jira.duraspace.org/browse/DS-3263 ] - [DS-3263] Renaming key metadata fields (e.g. dc.title) can result in NullPointerExceptions - DuraSpace JIRA
[15:16] <kompewter> [ https://jira.duraspace.org/browse/DS-3262 ] - [DS-3262] In use metadata fields can be deleted from the metadata registry, resulting in data loss - DuraSpace JIRA
[15:16] <kompewter> [ https://github.com/DSpace/DSpace/pull/1459 ] - Fixes for DS-3262 and DS-3263 (deleting or renaming/missing metadata fields) by tdonohue
[15:16] <tdonohue> I see terry-b volunteered to help test. I've run some tests on this myself locally obviously as well. It'd be good to get others to either test or review the code here (either now or later)
[15:17] <hpottinger> I was testing 1459 yesterday, will jump back in today
[15:18] <tdonohue> As a side-effect, in tracking down this issue, I also noticed that MetadataValues were never actually being *removed* from the database when they are deleted. They were just being disassociated with the object (by setting dspace_object_id=null)
[15:18] <tdonohue> So, I fixed that as well, and all Unit Tests pass, etc
[15:19] <mhwood> Automated testing good.
[15:19] <tdonohue> thanks hpottinger
[15:20] <tdonohue> Ok, so that has a few volunteers...moving on
[15:20] <tdonohue> DS-3259 .. fixed by DSPR#1454
[15:20] <kompewter> [ https://jira.duraspace.org/browse/DS-3259 ] - [DS-3259] DSpace creates unnecessary resource policies containing many null values - DuraSpace JIRA
[15:20] <kompewter> [ https://github.com/DSpace/DSpace/pull/1454 ] - [DS-3259] Prevent generation of resource policies with null values by marsaoua
[15:20] <tdonohue> This one is already at +2 and tested twice. Looks like it should just be merged?
[15:21] <pbecker> please
[15:21] <pbecker> Maras Haoua is my colleague we worked together on this.
[15:21] <tdonohue> merging & closing
[15:21] <pbecker> thanks
[15:21] <tdonohue> done...moving along
[15:22] <tdonohue> DS-3256 ... fixed by DSPR#1453
[15:22] <kompewter> [ https://jira.duraspace.org/browse/DS-3256 ] - [DS-3256] Configuration of metadata fields to show in JSPUI itemdisplay is broken - DuraSpace JIRA
[15:22] <kompewter> [ https://github.com/DSpace/DSpace/pull/1453 ] - DS-3256 by pnbecker
[15:22] <pbecker> I think the next one is really simple
[15:22] <pbecker> The configuration property webui.itemdispaly.default was loaded using getProperty.
[15:22] <tdonohue> this was assigned to me. I just hadn't gotten to it yet (got distracted by the other fix above)
[15:22] <pbecker> With the new Apache config we need to use getArrayProperty.
[15:23] <pbecker> btw, tdonohue: why does getProprety() only return the string till the first comma returns and not the complete list?
[15:23] <tdonohue> oh, yes. of course. I agree, this looks obvious to me. pbecker, have you tested it?
[15:23] <pbecker> And may we have the same problem else-where in the code?
[15:23] <pbecker> I have tested it.
[15:24] <tdonohue> pbecker... getProperty() does that because that's the (unfortunate) behavior of Apache Commons Config. I couldn't find a way to fix that
[15:24] <pbecker> The PR is not just a two liner, as I expected that one method was acting the opposite of what it names suggests.
[15:24] <terry-b> Joining late. Hello everyone
[15:24] <pbecker> And is there any whay to get a string containing all comma and all stuff?
[15:24] <pbecker> hi Terry!
[15:25] <tdonohue> pbecker: and most of the other places in the code *should* be fixed to use getArrayProperty() as I did do some bulk searching on "split(',')" (which was often used to split into arrays)
[15:25] <pbecker> tdonohue: should we grep config/**.cfg for ','?
[15:25] <mhwood> If you find a place where the string must be split, change it to use getArrayProperty and throw away the splitting.
[15:26] <tdonohue> pbecker: The only way I'm aware of in Apache Commons Config to return a string *with* commas, is to actually *escape* the commas in the *.cfg file
[15:26] <pbecker> I'm just afraid of properties that shall contains commas and aren't splitted anywhere.
[15:26] <tdonohue> pbecker: you are welcome to do more grepping. I did a TON (and this was a while ago, though)...and I tried to find all instances of this. I cannot guarrantee 100% coverage though, as it's hard to ensure you've found all of them.
[15:26] <pbecker> tdonohue: do you think it is worth greping and searching again (a lot of work) or are you confident enough, we hit all points?
[15:27] <pbecker> of course, I understand.
[15:27] <tdonohue> pbecker: I feel we've hit the vast majority. Hard to be 100% certain. If someone else has time, it'd be worth double checking I caught them all. But, I feel my time is better spent closing these tickets, instead of searching for things that may all be fixed
[15:27] <pbecker> I'll put it on my list, but I'm not confident to find time within the next days.
[15:28] <pbecker> It is for sure.
[15:28] <tdonohue> In any case, I'll add a +1 to 1453. I honestly think this looks obvious and we should just merge it (unless others object here)
[15:29] <pbecker> then I merge it?
[15:30] <pbecker> 3... 2... 1...
[15:30] <tdonohue> pbecker: the one hint of "good news" here is that if we miss one (or more) of these bugs in 6.0, it will be possible to "work around" the bug by adding "\," (escaped commas) to your local cfg file
[15:30] <tdonohue> I think we merge this. It seems very obvious to me
[15:31] <pbecker> merged, next.
[15:31] <tdonohue> thanks! Next up, DS-3229 fixed by DSPR#1429
[15:31] <kompewter> [ https://jira.duraspace.org/browse/DS-3229 ] - [DS-3229] JSPUI: Submission verify step ignores type binding - DuraSpace JIRA
[15:31] <kompewter> [ https://github.com/DSpace/DSpace/pull/1429 ] - DS-3229: JSPUI: Submission verify step ignores type binding by pnbecker
[15:32] <tdonohue> This has a +1 from tmmguimaraes (who is here today).
[15:32] <tdonohue> most of the code changes here look to be code realignment
[15:32] <pbecker> I (obviously) tested it while fixing the bug.
[15:33] <pbecker> tdonohue: I did two commits.
[15:33] <tdonohue> aha, I see that now. thanks ;)
[15:33] <pbecker> The second one is only fixing indentation, the first one is the one to review.
[15:33] <tdonohue> yes, the first one is quite tiny
[15:33] <tmmguimaraes> i tested it long ago
[15:33] <tmmguimaraes> also, i got to go.
[15:33] <pbecker> (as least if you trust me that I didn't hide something in the first one).
[15:34] <tmmguimaraes> can't remember the details of the test
[15:34] <pbecker> tmmguimaraes: thanks for testing, have a good day!
[15:34] <tmmguimaraes> bye
[15:34] <kompewter> see ya
[15:34] * tmmguimaraes (~tmg@193.137.88.100) Quit (Quit: Leaving)
[15:34] <tdonohue> what do others think here? (gotten quite the last 15 mins, other than pbecker & I)
[15:34] <pbecker> I mainly copied code from the metadata input form (JSPUI submission).
[15:35] <tdonohue> This again looks like a tiny change to me...two testers (pbecker & tmmguimaraes) is also great
[15:35] <pbecker> We already had this fix in our DSpace 4, but I missed to create a PR. Preparing our upgrade to DSpace 6, I notice the bug still exist.
[15:36] <pbecker> I have to run, be back in 5 minutes. sorry
[15:36] <tdonohue> Looking at the code here, I'll give this a +1 via code review. I don't see any issues here, actual code change looks clean and small (outside of the realignment fixes, which obviously touch a bit more, but are realignment only)
[15:38] <mhwood> There are two adjacent calls to ContentServiceFactory.getInstance().getItemService() that could be condensed, but it's not a big deal.
[15:38] <tdonohue> true...pretty minor though
[15:38] <tdonohue> I added my +1 nonetheless. I think this looks good
[15:39] <mhwood> I can't object.
[15:39] <tdonohue> Shall we merge it then? It's at +2 (one was a non-committer vote, but it was a tester).
[15:40] <mhwood> Sure.
[15:40] * pbecker is back
[15:40] <pbecker> sorry.
[15:41] <tdonohue> merged
[15:41] <tdonohue> next up, DS-3209 fixed by DSPR#1399
[15:41] <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:41] <pbecker> great, that helps moving the preparation of our migration towards dspace 6 forward.
[15:41] <kompewter> [ https://github.com/DSpace/DSpace/pull/1399 ] - DS-3209 AIP Import: Extend accepted handles for supports() by mjmarttila
[15:42] <tdonohue> This has had a lot of ongoing discussion. The most recent comments show how to better test/verify it
[15:42] <tdonohue> pbecker, it's assigned to you, are you able to test this one (again)?
[15:42] <terry-b> I can confirm that the fix works, but I did not +1 since our institution submitted the change
[15:42] <pbecker> oh, yes.
[15:43] <terry-b> It would be great to get 1399 and 1396 tested.
[15:43] <pbecker> I'll test 1399 till next Dev Meeting.
[15:43] <terry-b> We will be happy to answer any questions needed for testing.
[15:43] <tdonohue> 1399 code changes look reasonable to me, but would be good to get another tester. So, thanks pbecker for volunteering
[15:44] <terry-b> Could you look at 1396 as well since it is also related to AIP import?
[15:44] <pbecker> may I merge if test is successful?
[15:44] <pbecker> Terry: you gave it a +1, correct?
[15:44] <tdonohue> pbecker: yes, please. I'll add a +1 now to 1399 (as I just reviewed the code)
[15:44] <terry-b> Since we contributed it, I was not sure if I should +1
[15:45] <terry-b> tdonohue, what is your advice on that?
[15:45] <hpottinger> you can infer that committer-provided PRs have a +1 from the contributor
[15:45] <pbecker> I'm not very common with AIP and METS, but if no one else volunteers, I could add 1396 to my list.
[15:45] <tdonohue> terry-b: you can add a +1, but it's good to see if we can get a few external reviewers anyhow
[15:45] <hpottinger> which is where we get the "+2, ggood enough, let's merge this" math
[15:45] <terry-b> Will do. Thanks
[15:47] <tdonohue> So, if we want to jump down to DSPR#1396 for now we can... it's actually assigned to me to test (and I just haven't gotten to it)
[15:47] <kompewter> [ https://github.com/DSpace/DSpace/pull/1396 ] - DS-3140 METSRightsCrosswalk NPE During AIP Restore - No Anonymous Read by mjmarttila ¡ Pull Request #1396 ¡ DSpace/DSpace ¡ GitHub
[15:47] <tdonohue> 1396 is a bug we really need to fix, but the code refactoring is a bit larger here, so it does need verification test(s)
[15:48] <tdonohue> I'm willing to keep 1396 assigned to me. I'll try to test it before next meeting.
[15:49] <terry-b> Thanks tdonohue and pbecker!
[15:49] <tdonohue> moving back to our list..next is DS-3199, fixed by DSPR#1455
[15:49] <kompewter> [ https://jira.duraspace.org/browse/DS-3199 ] - [DS-3199] Editing bitstream generates error when saving - DuraSpace JIRA
[15:49] <kompewter> [ https://github.com/DSpace/DSpace/pull/1455 ] - DS-3199 by PhilipVis
[15:49] <tdonohue> This one, to me is a very obvious one-liner. Still would be good to verify it fixes *all* the issues with editing bitstreams though (I suspect it will though)
[15:50] <tdonohue> Anyone willing to give this a verification test?
[15:50] <tdonohue> To reproduce the issue, simply try to edit a bitstream (metadata or embargo info) from either UI. currently, it won't work at all
[15:51] <hpottinger> I can test 1455
[15:51] <tdonohue> Oh wait, I'm sorry, it's XMLUI specific. My mistake :)
[15:51] <tdonohue> hpottinger: thanks! I'll add a +1 via code review. Once verified, please merge
[15:53] <tdonohue> next up, DS-3146 fixed by DSPR#1406
[15:53] <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:53] <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:54] <tdonohue> This is one I've been testing off and on (and constantly finding other small issues with). I'll give this another test, as there's a new commit now
[15:55] <tdonohue> moving along... DS-3144, fixed by DSPR#1370 and DSPR#1350
[15:55] <kompewter> [ https://jira.duraspace.org/browse/DS-3144 ] - [DS-3144] PubMed integration feature is not working in codebase - DuraSpace JIRA
[15:55] <kompewter> [ https://github.com/DSpace/DSpace/pull/1370 ] - DS-3144 Update of publication-lookup config by jonas-atmire
[15:55] <kompewter> [ https://github.com/DSpace/DSpace/pull/1350 ] - DS-2880: additional javadocs docs and renames for clarity by rradillen
[15:56] <tdonohue> The first PR is pretty obvious here...it's fixing how the PubMed config is loaded/used. The second one though is a massive update (adding missing javadocs and cleaning up method names) which fixes additional bugs with the PubMed integration feature
[15:56] <tdonohue> So, unfortunately, these probably need testing *together* (as it's noted in the comments that they are tightly related)
[15:57] <tdonohue> Considering this feature is new, and currently doesn't work *at all*, these are important fixes to make it work
[15:57] <tdonohue> Anyone here willing to help test or review these?
[16:00] <tdonohue> Ok, I'll see if I can find time here then
[16:00] <terry-b> I will be glad to review, not sure about testing
[16:01] <pbecker> sorry, I have to run.
[16:01] <tdonohue> Ok, thanks terry-b
[16:01] <pbecker> I'll be in #dspace later.
[16:01] <terry-b> have a good day!
[16:02] <terry-b> tdonohue, I assigned you as well
[16:02] <tdonohue> Ok, we're at the end of our hour. There is however one last ticket in this list which would be good to find a volunteer for... DS-2996 fixed by DSPR#1319
[16:02] <kompewter> [ https://github.com/DSpace/DSpace/pull/1319 ] - [DS-2996] Fix retrieval of hierarchical of communities from a collection by KevinVdV
[16:02] <kompewter> [ https://jira.duraspace.org/browse/DS-2996 ] - [DS-2996] Submission collection selection does not show the complete hierarchy - DuraSpace JIRA
[16:03] <tdonohue> This has been open for a long time, and the PR really just needs testing/reviewing
[16:03] <tdonohue> This also has been noted to be related to DS-2750 (a REST API issue)
[16:03] <kompewter> [ https://jira.duraspace.org/browse/DS-2750 ] - [DS-2750] REST API ignores expand=all on communities - DuraSpace JIRA
[16:04] <tdonohue> If someone is willing to give 1319 a test, it'd be another useful fix to analyze for 6.0
[16:04] <terry-b> And possibly https://github.com/DSpace/DSpace/pull/1414
[16:04] <kompewter> [ DS-2766 /rest/collections/xxx?expand=parentCommunityList only returns 1 parent community by terrywbrady · Pull Request #1414 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1414
[16:04] <terry-b> I will take it
[16:04] <tdonohue> thanks terry-b!
[16:04] <mhwood> Should those be linked, then?
[16:05] <tdonohue> yes, they should be linked up
[16:05] <terry-b> I will link them
[16:05] <tdonohue> thanks again terry-b
[16:07] <tdonohue> So, the few other tickets on our list look to be ones that are tightly related to others we talked about.. DS-2880 is only still open cause PubMed feature is broken
[16:07] <kompewter> [ https://jira.duraspace.org/browse/DS-2880 ] - [DS-2880] Pubmed integration into XMLUI submission - DuraSpace JIRA
[16:07] <tdonohue> and DS-2701 has a few sub-tickets still open it seems (which maybe we could review during JIRA backlog review, if folks will be around for that)
[16:07] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[16:08] <tdonohue> Are folks available for a JIRA backlog hour nowish? Or does everyone need to run off to other tasks?
[16:08] <mhwood> I can stay.
[16:08] <hpottinger> I can stay
[16:09] <terry-b> I can stay
[16:09] <tdonohue> Ok, thanks! We can just stay here for the review. I'd like to start with sub-tickets of DS-2701. We need to close those out in order to close 2701.
[16:09] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[16:10] <tdonohue> specifically, DS-2730 is the first still open
[16:10] <kompewter> [ https://jira.duraspace.org/browse/DS-2730 ] - [DS-2730] Remove redundant getName methods - DuraSpace JIRA
[16:10] <tdonohue> Has a PR which was closed. As noted in the comment of this ticket, this seems like a larger refactor, which we might want to wait on
[16:11] <tdonohue> Actually, looking at KevinVdV's comment, he's actually recommending *against* this change. Maybe this should be closed as "won't fix" (at least for now, until we find a better reason to do this)
[16:11] <tdonohue> thoughts?
[16:11] <mhwood> Noting is actually broken now, right?
[16:12] <tdonohue> correct. nothing is broken. this is discussion of a code refactor
[16:12] <tdonohue> and KevinVdV noted in his comment on the ticket that he doesn't think this change is even necessary
[16:12] <mhwood> So it would be good to do something about it, but we can separate it from 2701.
[16:13] <tdonohue> actually not sure it's even "good" .. see this comment: https://jira.duraspace.org/browse/DS-2730?focusedCommentId=44439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-44439
[16:13] <kompewter> [ https://jira.duraspace.org/browse/DS-2730 ] - [DS-2730] Remove redundant getName methods - DuraSpace JIRA
[16:13] <kompewter> [ [DS-2730] Remove redundant getName methods - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-2730?focusedCommentId=44439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-44439
[16:13] <tdonohue> I'm leaning towards closing this as "won't fix". If we find a good reason for this, we should create a new (separate) ticket and describe the reasons better
[16:13] <mhwood> I thought that the PR took that into account.
[16:14] <tdonohue> mhwood: that comment from KevinVdV is noting that the change suggested in this ticket is not necessary *because* KevinVdV already "linked" things up in the referenced PR
[16:15] <tdonohue> (PR #1037 that is)
[16:15] <tdonohue> I'm going to close this. If someone ends up disagreeing, reopen it and tell us why please ;)
[16:15] <mhwood> He says we shouldn't remove the method from DSpaceObject, but not about the subclasses, which is what the PR is about.
[16:17] <mhwood> Still, no reason why 2701 must wait on this.
[16:18] <tdonohue> I think that's a typo... If you read that comment, he says he doesn't think we should replace the 300 usages of getName(). So, I think he meant to say: "I'm not sure we should remove getName() form the DspaceObject *classes*" (plural)
[16:19] <tdonohue> Either way, as a subticket, I cannot pull this out into a separate ticket (limitation of JIRA it seems, just tried it). So, I have to either leave it open or close it. I'm opting for the latter. If a new ticket needs to be created, I'll ask someone else to create it and describe this change more fully
[16:19] <mhwood> If you edit, you can follow the "moving" link.
[16:20] <mhwood> Ugh, but for some reason it won't let you change the type, right.
[16:21] <mhwood> Jira is not cooperating, so close it.
[16:21] <tdonohue> closed for now. Added a comment
[16:21] <tdonohue> next open subticket: DS-2775
[16:21] <kompewter> [ https://jira.duraspace.org/browse/DS-2775 ] - [DS-2775] Correct "update-sequences" documentation / notes - DuraSpace JIRA
[16:23] <tdonohue> This still needs fixing. The update-sequences.sql script (and docs around it) are a bit inaccurate now.
[16:23] <mhwood> I'll take this one if nobody else want it.
[16:23] <tdonohue> mhwood: please, feel free. I'm actually trying to figure out if we should fix the update-sequences.sql script as well (to remove all unused sequences in there), or leave it as-is
[16:24] <mhwood> Got it.
[16:24] <tdonohue> i.e. not sure if update-sequences.sql will even *work* for 6.0. I think it's still needed for *handles* only. But, everything else might need to be deleted from that scrip
[16:25] <tdonohue> scipt
[16:25] <tdonohue> script (can I type?) ;)
[16:25] <mhwood> scrip U scipt = script?
[16:25] <tdonohue> mhwood: if you are willing, could you test update-sequences.sql as well? My gut is telling me we should remove everything from this script *except* the Handle_seq
[16:26] <mhwood> I will look into it.
[16:26] <tdonohue> And then we'd need to update the documentation to make it clear that it's only needed to update handle_seq
[16:26] <tdonohue> Thanks!
[16:26] <hpottinger> DSPR#1459 is now at +2 and tested, mind if I merge it?
[16:26] <kompewter> [ https://github.com/DSpace/DSpace/pull/1459 ] - Fixes for DS-3262 and DS-3263 (deleting or renaming/missing metadata fields) by tdonohue
[16:27] <tdonohue> I have no objections :) But, I wrote & tested it. mhwood any thoughts on 1459 from you at all?
[16:27] <mhwood> Looking again.
[16:28] <hpottinger> tdonohue: your +1 is inferred, there are two more +1s, it has met the threshold
[16:28] <terry-b> I haven't had a chance to test, but the code looked good to me
[16:29] <tdonohue> hpottinger: right, I understand. terry-b's +1 was added prior to the last two commits (fixing Unit tests and another bug) though
[16:29] <mhwood> It looks sensible. Definitely better error reporting.
[16:29] <tdonohue> So, I was just wanting to double check this looks right to all. :)
[16:29] <hpottinger> it's actually pretty nice to have the system made a bit more resilient, I like the new error message if you rename an important field
[16:31] <tdonohue> ok, sounds like it's good to go then. merge it & close the tickets (or I will in a bit)
[16:31] * mhwood dislikes having the "important field" knowledge scattered, but this is significant improvement and I dunno how to gather that knowledge together.
[16:31] <tdonohue> mhwood: i agree, but there was no other way I could find to centralize that easily, until we make the "Title" a configurable field somehow (so it's not hardcoded all over as dc.title)
[16:32] <hpottinger> merged
[16:32] <terry-b> mhwood, I will put in a new ticket for the "important field" issue. I assume this will get tackled in the future.
[16:33] <mhwood> There is the issue of whether one should be allowed to edit DC at all.
[16:33] <tdonohue> back to our subtickets for 2701...there's one more (unresolved): DS-3013
[16:33] <kompewter> [ https://jira.duraspace.org/browse/DS-3013 ] - [DS-3013] OAI import slow after migration to Hibernate - DuraSpace JIRA
[16:33] <tdonohue> mhwood: right, that too
[16:33] <hpottinger> I also closed DS-3263 and DS-3262
[16:33] <kompewter> [ https://jira.duraspace.org/browse/DS-3263 ] - [DS-3263] Renaming key metadata fields (e.g. dc.title) can result in NullPointerExceptions - DuraSpace JIRA
[16:33] <kompewter> [ https://jira.duraspace.org/browse/DS-3262 ] - [DS-3262] In use metadata fields can be deleted from the metadata registry, resulting in data loss - DuraSpace JIRA
[16:34] <tdonohue> 3013: Oh, I see KevinVdV is now noting this is the same issue as described in https://jira.duraspace.org/browse/DS-3086?focusedCommentId=49448&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-49448
[16:34] <kompewter> [ [DS-3086] OAI Harvester is broken (NPEs around several classes) - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3086?focusedCommentId=49448&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-49448
[16:34] <mhwood> Looks like 3013 just needs retesting?
[16:34] <kompewter> [ https://jira.duraspace.org/browse/DS-3086 ] - [DS-3086] OAI Harvester is broken (NPEs around several classes) - DuraSpace JIRA
[16:34] <mhwood> I wondered if it has already been fixed.
[16:35] <tdonohue> I suspect this should be closed. 3086 did major performance improvements to OAI import, and 3013 was created before those changes were made
[16:36] <terry-b> Created https://jira.duraspace.org/browse/DS-3265 as a follow up to our earlier discussion
[16:36] <kompewter> [ https://jira.duraspace.org/browse/DS-3265 ] - [DS-3265] Consolidate logic that defines or restricts changes to "important" metadata fields - DuraSpace JIRA
[16:36] <kompewter> [ [DS-3265] Consolidate logic that defines or restricts changes to "important" metadata fields - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3265
[16:37] <tdonohue> 3013: I think I'm going to just close this, unless someone wants to give this another test. It was tested over in the solution for 3086 though as well.
[16:37] <mhwood> If it's already re-tested then close it.
[16:38] <tdonohue> closed & linked up to 3086
[16:39] <tdonohue> So, that's it for sub-tickets of 2701. We have one left open (the update-sequences one). Once that is closed, then 2701 is also ready to finally close
[16:40] <tdonohue> Are there other tickets/PRs that folks would like attention on (for 6.0)?
[16:40] <mhwood> I made a note to close 2701 when closing 2775.
[16:40] <tdonohue> thanks mhwood
[16:41] <tdonohue> One that needs verification that it "exists" seems to be DS-3255 (found by mhwood, but unverifiable by KevinVdV)
[16:41] <kompewter> [ https://jira.duraspace.org/browse/DS-3255 ] - [DS-3255] 'dspace structure-builder' silently fails, logging Hibernate errors - DuraSpace JIRA
[16:41] <terry-b> https://github.com/DSpace/DSpace/pull/1414 should be simple to close out
[16:41] <kompewter> [ DS-2766 /rest/collections/xxx?expand=parentCommunityList only returns 1 parent community by terrywbrady · Pull Request #1414 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1414
[16:42] <tdonohue> mhwood: any chance you know the exact steps you used to find 3255 (as it sounds like KevinVdV cannot reproduce it yet)
[16:42] <mhwood> Not anymore. I'd have to test it as if I'd only just learned of it. Which perhaps I should do, to verify that I still get it.
[16:43] <mhwood> It's on my list.
[16:43] <tdonohue> mhwood : yes, it would be good to try and "re-learn" it. If it's gone now, maybe it isn't something that is truly reproduceable. Thanks :)
[16:44] <tdonohue> terry-b: didn't you note that 1414 is related to another ticket earlier...about returning hierarchical collections at the API level. Is 1414's solution affected by that other ticket at all?
[16:44] <tdonohue> terry-b: I'm talking about DSPR#1319
[16:44] <kompewter> [ https://github.com/DSpace/DSpace/pull/1319 ] - [DS-2996] Fix retrieval of hierarchical of communities from a collection by KevinVdV
[16:45] <terry-b> You are right, it could change the approach.
[16:45] <tdonohue> I guess 1414 looks small, but I wasn't sure if it's being caused by / affected by 1319 :)
[16:45] <tdonohue> ok, so we probably should wait on 1414 then...and link it up with 1319
[16:45] * mhwood wonders if applying 1319 and testing for 1414 (without applying it) would show the problem vanished.
[16:46] <tdonohue> that'd be worth testing for as well
[16:46] <terry-b> I can provide an update after I have a chance to test
[16:46] <tdonohue> thanks, terry-b! I think we definitely want to fix both...but 1319 seems to be the first priority, then seeing if 1414 is even necessary (or if it needs minor updates)
[16:47] <terry-b> sounds good
[16:48] <mhwood> In fact, if 1319 affects Ds-2996 then it might break 1414.
[16:49] <tdonohue> As we have only about 10 mins left here, are there other tickets we want to jump to (that need eyes, volunteers, help, etc)
[16:50] <tdonohue> One more I found to mention... DS-3154. This won't get fully "fixed" in 6.0 (too many bad javadocs in our code). But, to allow us to use Java 8 fully, I'm going to recommend we temporarily *disable* doclint (not ideal, but necessary) to avoid Javadocs errors for 6.0 releases
[16:50] <kompewter> [ https://jira.duraspace.org/browse/DS-3154 ] - [DS-3154] Maven release process fails when using Java 8 because of Javadocs errors - DuraSpace JIRA
[16:51] <tdonohue> Otherwise, anyone with Java 8 installed won't be able to successfully release DSpace at all. You'd *have* to have Java 7.
[16:52] <tdonohue> Just noting that, so anyone can add your complaints to the ticket if needed :)
[16:52] <terry-b> tdonohue, your plan makes sense to me
[16:54] <mhwood> I've put 3154 back on my list as low priority.
[16:55] <tdonohue> Ok, I think we'll stop there for today. I would encourage folks to find time to look at the "needs volunteer" tickets still open. Many of these just need *re-testing* (as they might be solved)
[16:55] <mhwood> IIRC XMLUI is done and API is close. The rest are much smaller.
[16:55] <tdonohue> here's that list of "needs volunteer": https://jira.duraspace.org/issues/?jql=project%20%3D%20DS%20AND%20status%20%3D%20%22Volunteer%20Needed%22%20AND%20priority%20in%20(Blocker%2C%20Critical%2C%20Major)%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%206.0
[16:55] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/issues/?jql=project%20%3D%20DS%20AND%20status%20%3D%20%22Volunteer%20Needed%22%20AND%20priority%20in%20(Blocker%2C%20Critical%2C%20Major)%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%206.0
[16:56] <tdonohue> mhwood: API javadocs are actuallly not that close..it is the biggest in terms of problems. XMLUI & Services were fixed. API had so many issues that I never found the "endpoint" (only the first 100 get reported IIRC).
[16:56] <tdonohue> So, while we made a big "dent" in fixing Javadocs, I don't have a good sense of how many more are broken.
[16:57] <tdonohue> And 'dspace-api' is definitely the one that has had the most issues (as one might expect anyhow)
[16:57] <terry-b> I looked at https://jira.duraspace.org/browse/DS-2964 and I did not add enough detail into the initial ticket to verify this issue.
[16:57] <kompewter> [ https://jira.duraspace.org/browse/DS-2964 ] - [DS-2964] Null pointer exception in Shibb Authentication - DuraSpace JIRA
[16:57] <kompewter> [ [DS-2964] Null pointer exception in Shibb Authentication - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-2964
[16:58] <terry-b> Perhaps this one can be closed. I was confused by the comment added/removed by Andrea.
[16:58] <tdonohue> In any case, please keep at it with 6.0 tickets/PRs! We are nearing the endpoint, and I think many of our still open tickets just need someone to sit down with them for 30 mins or an hour to retest or solve or whatever. None seem major
[16:58] <mhwood> BTW hpottinger has been doing interesting things with a FIndBugs plugin for sniffing out security concerns.
[16:58] <hpottinger> heh, thanks for the plug, mhwood :-)
[16:59] <hpottinger> https://github.com/hardyoyo/DSpace/tree/try-findsecbugs-plugin
[16:59] <kompewter> [ GitHub - hardyoyo/DSpace at try-findsecbugs-plugin ] - https://github.com/hardyoyo/DSpace/tree/try-findsecbugs-plugin
[16:59] <mhwood> Well, we were talking about gadgets that complain about our code.
[16:59] <tdonohue> If there are changes worth bringing back into Travis CI or similar, that'd be wonderful
[16:59] * Dylan (~Dylan@85.234.195.109.static.edpnet.net) has joined #duraspace
[16:59] <tdonohue> Please make sure to create a ticket and/or PR if you feel it's getting close (or just needing more help/eyes)
[17:00] <hpottinger> tdonohue: unfortunately, the findsecbugs plugin is a bit of a hog, so it's not something we can run in Travis
[17:00] <tdonohue> well, even if it's something we can add to the Release Procedure to run, that's fine too
[17:00] <hpottinger> it's a plugin for findbugs, which we also don't run in Travis
[17:01] <mhwood> We probably don't want Travis broadcasting security holes anyway.
[17:01] <tdonohue> Either way, report it back as you look into it, create a PR or whatever
[17:01] <hpottinger> mhwood++
[17:01] <hpottinger> FWIW, on a quick skim I didn't find anything particularly interesting
[17:01] <tdonohue> mhwood: assuming you fix them all first... it'd be good to have Travis report security holes in specific PRs! ;)
[17:02] <tdonohue> mhwood: by which I mean..once you have general security holes fixed...having them found in specific PRs would be a nice thing
[17:02] <tdonohue> but, if it's a hog, then it'd not be possible anyways. So, no worries
[17:03] <hpottinger> yeah, it was a struggle getting it to run at all
[17:03] <tdonohue> I have to step away shortly, so keep us in the loop on the work, etc.
[17:03] <terry-b> Have a good day!
[17:04] * Dylan (~Dylan@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 264 seconds)
[17:04] <hpottinger> will do... I would like to at least get my branch in shape enough to get it to the level of how we are currently implementing findbugs, with a Maven profile, though mhwood was talking about a way to call a plugin for findbugs from the command line... which sounded intriguing... perhaps we could just document a process?
[17:54] * hpottinger (~hpottinge@mu-161168.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[18:12] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[19:52] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[20:07] * luizsan (~luizsan@2601:148:c100:2d0f:5823:fc19:b7a5:dd0e) has joined #duraspace
[20:08] * luizsan (~luizsan@2601:148:c100:2d0f:5823:fc19:b7a5:dd0e) has left #duraspace
[20:08] * luizsan (~luizsan@c-24-126-30-91.hsd1.md.comcast.net) has joined #duraspace
[20:55] * luizsan (~luizsan@c-24-126-30-91.hsd1.md.comcast.net) Quit (Quit: Leaving...)
[21:01] * Dylan (~Dylan@85.234.195.109.static.edpnet.net) has joined #duraspace
[21:01] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:05] * Dylan (~Dylan@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 246 seconds)
[21:08] * helix84 (~ctenar@unaffiliated/helix84) Quit (Ping timeout: 260 seconds)
[21:09] * helix84 (~ctenar@unaffiliated/helix84) has joined #duraspace
[21:53] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) has left #duraspace
[23:02] * Dylan (~Dylan@85.234.195.109.static.edpnet.net) has joined #duraspace
[23:07] * Dylan (~Dylan@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 260 seconds)
[23:59] * Dylan (~Dylan@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.