Timestamps are in GMT/BST.
[6:36] -sinisalo.freenode.net- *** Looking up your hostname...
[6:36] -sinisalo.freenode.net- *** Checking Ident
[6:36] -sinisalo.freenode.net- *** Found your hostname
[6:36] -sinisalo.freenode.net- *** No Ident response
[6:36] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:36] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:36] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:19] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:16] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) has joined #duraspace
[13:46] * hpottinger_ (d86a3376@gateway/web/freenode/ip.216.106.51.118) has joined #duraspace
[13:47] * hpottinger_ (d86a3376@gateway/web/freenode/ip.216.106.51.118) Quit (Client Quit)
[13:48] * hpottinger (d86a3376@gateway/web/freenode/ip.216.106.51.118) has joined #duraspace
[15:10] -hitchcock.freenode.net- *** Looking up your hostname...
[15:10] -hitchcock.freenode.net- *** Checking Ident
[15:10] -hitchcock.freenode.net- *** Found your hostname
[15:10] -hitchcock.freenode.net- *** No Ident response
[15:10] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[15:10] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[15:10] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[17:29] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[17:59] * hpottinger (d86a3376@gateway/web/freenode/ip.216.106.51.118) Quit (Quit: Page closed)
[18:37] * terry-b (~chrome@97-126-116-1.tukw.qwest.net) Quit (Remote host closed the connection)
[19:01] * bollini (4f2c0dcb@gateway/web/freenode/ip.79.44.13.203) has joined #duraspace
[19:49] * lap82 (5feed229@gateway/web/freenode/ip.95.238.210.41) has joined #duraspace
[20:01] <tdonohue> Hi all, it's time for our weekly DSpace DevMtg https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-08-17
[20:01] <kompewter> [ DevMtg 2016-08-17 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-08-17
[20:02] <tdonohue> The main topic for today is obviously updates on 6.0... in the last week we had many issues closed out, but also a few more pop up
[20:03] <tdonohue> Before we jump into reviewing "Must Have" issues though, I wanted to pause to see if there's any other pressing topics to be discussed today? (Otherwise, we'll do the usual quick reviews of where each ticket stands)
[20:04] <tdonohue> Ok, not hearing anything...we'll review "must have" tickets then. Here they are: https://jira.duraspace.org/issues/?jql=project%20%3D%20DS%20AND%20priority%20in%20(Blocker%2C%20Critical%2C%20Major)%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%206.0
[20:04] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/issues/?jql=project%20%3D%20DS%20AND%20priority%20in%20(Blocker%2C%20Critical%2C%20Major)%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%206.0
[20:05] <tdonohue> starting at the top with a few new ones...first up, DS-3292
[20:05] <kompewter> [ https://jira.duraspace.org/browse/DS-3292 ] - [DS-3292] Delete item doesn't work well in JSPUI - DuraSpace JIRA
[20:05] <tdonohue> has PR: DSPR#1494 (from lap82)
[20:05] <kompewter> [ https://github.com/DSpace/DSpace/pull/1494 ] - [DS-3292] Delete the Item from EditItemServlet doesn't work well by lap82
[20:05] <lap82> hi all I'm here
[20:06] <tdonohue> To me, this looks like an obvious bug...and the PR from lap82 looks like the correct fix. We shouldn't be looping through all Collections simply to delete one item.
[20:07] <mhwood> Agreed.
[20:07] <tdonohue> my suspicion is this was done this way to "work around" some other earlier issue in the API refactor that has since been fixed. So, glad we stumbled on this issue
[20:07] <mhwood> ItemService ought to know how to delete an Item.
[20:08] <mhwood> Certainly UI code should not need to know those details.
[20:08] <lap82> No, I think that we have follow the old code style
[20:09] <tdonohue> lap82: perhaps...I didn't compare it with the old 5.x code :)
[20:09] <bollini> I suspect that there is an additional bug that this fix will hide
[20:09] <bollini> if I remove an item from the unique collection where this item belong, the item should be deleted
[20:10] <bollini> this is the logic behind the "old code" that iterate over all the collection, if it doesn't work we probably have a bug in the collection.removeItem
[20:10] <mhwood> Either that or the removal should fail.
[20:11] <bollini> the old logic was to remove the item, we should be backward compatible here
[20:11] <tdonohue> bollini: possibly, but I would expect that scenario *should be* tested in Unit Tests (or maybe we should check and add a Unit Test for this scenario)
[20:12] <mhwood> Good enough. We should have documentation somewhere of the expected interactions between model objects as they are created and deleted.
[20:13] <bollini> Ok, I will try to put a junit here and verify the behaviour. lap82 PR still introduce a performance improvement other than make the code more clean
[20:14] <tdonohue> I still agree this new logic looks right...the way deletions occur (in general) is a bit more automated via Hibernate (i.e. tighter relationships). So, I'm hoping that there is not an additional hidden bug here :)
[20:14] <mhwood> I like the way it DRYs up the details of item deletion.
[20:14] <tdonohue> It would be nice to add a Unit and/or Integration test if you are concerned about specific scenarios. I admit, I've been trying to make it a habit to do the same thing in my recent PRs
[20:15] <tdonohue> mhwood ++
[20:15] <tdonohue> Ok, moving along for now. It sounds like we have a plan for 3292, may just need a quick tester (and/or unit tests)
[20:16] <tdonohue> DS-3287 is next (another new one this past week)
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-3287 ] - [DS-3287] ElasticSearch fails (does not work at all) - DuraSpace JIRA
[20:16] <tdonohue> I wrote some notes into the comments here as to what the problem is (and one possible solution). Unfortunately, I'm not very knowledgeable on Elasticsearch, and haven't had time to dig into this (and may not have time this week)
[20:17] <tdonohue> I've pinged PeterDietz (who wrote this code), but haven't heard from him yet
[20:17] <tdonohue> Anyone else here have much experience with Elasticsearch and/or want to look into this further?
[20:18] <bollini> unfortunately, the lack of general understanding is one of the reason why we have deprecated the ES code
[20:18] <tdonohue> bollini++
[20:18] <mhwood> Sorry, I'm not really up to speed on Solr, let alone ES.
[20:19] <tdonohue> My goal here would be to implement a "fix" here that essentially just lets you "export" your ES Stats to CSV...that way the "fix" can also be our migration tool to Solr Stats. I just don't (yet) know how to do such an export from ES, so I'm hoping PeterDietz reappears to help us ;)
[20:19] <bollini> I think that we should wait for peter here. If we cannot fix it for 6.0 we can add it as known bug
[20:20] <lap82> bollini++
[20:20] <tdonohue> bollini: true, we could just warn ES Stats users that 6.0 won't work for them. Please wait for 6.1
[20:20] <mhwood> Do we know of any sites actually using ES currently?
[20:21] <tdonohue> Ohio State does (where Peter Dietz worked when he wrote this). Unsure of others...but we could ask on dspace-devel perhaps
[20:22] <tdonohue> for now, we'll wait on Peter a bit longer. If he doesn't respond, perhaps I'll email dspace-devel to see if we can find a different volunteer to help out. In the meantime, I agree, we could simply release 6.0 and warn folks that ES Stats doesn't work yet
[20:22] <tdonohue> moving along, DS-3277
[20:22] <kompewter> [ https://jira.duraspace.org/browse/DS-3277 ] - [DS-3277] Change in behavior: Handles are now minted based on `handle_id` internal table ID - DuraSpace JIRA
[20:23] <tdonohue> DSPR#1479
[20:23] <kompewter> [ https://github.com/DSpace/DSpace/pull/1479 ] - DS-3277 : Create new 'handle_id_seq' for handle_id column. Use 'handle_seq' to mint new handles. by tdonohue
[20:23] <tdonohue> and I just noticed lap82's review this morning..thanks for the test!
[20:23] <lap82> :-)
[20:25] <tdonohue> So, anyone else have feedback on this? Do we feel this is ready to go? I know I've done some extensive testing when I wrote this, and lap82 did testing too... do we want to test other scenarios?
[20:27] <mhwood> I think I read this through, but I'm doing that again now.
[20:27] <bollini> just a question as I'm ignorant about the Hibernate ReturningWork, are we sure that there are not possibility of connection leaks here https://github.com/DSpace/DSpace/pull/1479/files#diff-f522b694f74437578f2fe677599c5999R115
[20:27] <kompewter> [ DS-3277 : Create new 'handle_id_seq' for handle_id column. Use 'handle_seq' to mint new handles. by tdonohue · Pull Request #1479 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1479/files#diff-f522b694f74437578f2fe677599c5999R115
[20:27] <tdonohue> feel free. We also can move along if folks want more time to look at this (now or later). Just thought I'd ask if others have had a chance to look at this
[20:28] <tdonohue> bollini: that area of the code is using "try with resources" (i.e. the PreparedStatement and ResultSet objs should be closed automatically)
[20:29] <tdonohue> bollini: is there a specific part that worries you?
[20:29] <bollini> tdonohue: perfect this was exactly what I need to know ;)
[20:30] <tdonohue> Just for reference... ;) try-with-resources: https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
[20:30] <kompewter> [ The try-with-resources Statement (The Java™ Tutorials > Essential Classes > Exceptions) ] - https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
[20:31] <tdonohue> In any case, we can move along for now. I would appreciate further feedback on 1479 PR though...as I think this *must* be in 6.0 (otherwise we'll end up with Handle assignment issues)
[20:31] <tdonohue> next up, DS-3269
[20:31] <kompewter> [ https://jira.duraspace.org/browse/DS-3269 ] - [DS-3269] Flyway "Out-of-order" migrations is enabled by default - DuraSpace JIRA
[20:32] <tdonohue> mhwood was working on testing this, and we talked about this one extensively in backlog hour :)
[20:32] <mhwood> :-)
[20:32] <tdonohue> Not sure there's anything else to touch on. Just needs testers/reviewers
[20:32] <tdonohue> moving along, DS-3209
[20:32] <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
[20:32] <tdonohue> DSPR#1399
[20:33] <kompewter> [ https://github.com/DSpace/DSpace/pull/1399 ] - DS-3209 AIP Import: Extend accepted handles for supports() by mjmarttila
[20:33] <tdonohue> This PR has undergone many different "iterations" (based on feedback). terry-b updated it yet again. I think this seems like the best version yet, but I admit I haven't tested it yet.
[20:34] <tdonohue> I did just notice though that it still needs updates to it's Unit Test scenarios.
[20:35] <tdonohue> (I'll ping terry-b on that...he said he won't be here today though)
[20:36] <mhwood> Anyone who is worried about some specific identifier pattern that should or should not match ought to add it to the pattern file and run the test suite. That was the original motivation for the test code.
[20:37] <tdonohue> Any other comments here? I think this is getting close...just need to work out the Unit Tests, and ensure this gets a good review.
[20:38] <tdonohue> ok, moving along for now. (I pinged terry in comments in the PR)
[20:38] <tdonohue> next up, DS-3190
[20:38] <kompewter> [ https://jira.duraspace.org/browse/DS-3190 ] - [DS-3190] org.dspace.rdf.RDFConfiguration throws IllegalAccessException - DuraSpace JIRA
[20:38] <mhwood> Awaiting documentation.
[20:39] <tdonohue> This one just needs docs. pbecker emailed me to let me know he's out of the office for a while. I believe he's back next week though, so hopefully he'll have time to get to this. If not, he can update when he's back
[20:39] <tdonohue> next, DS-3157
[20:39] <kompewter> [ https://jira.duraspace.org/browse/DS-3157 ] - [DS-3157] browse by author displays authority key instead of value - JSPUI Test Plan Ref DISC6 - XMLUI DISC8 - DuraSpace JIRA
[20:39] <tdonohue> bollini claimed this one. Any updates to share here? Or is this still in progress?
[20:39] <bollini> I'm looking to it. My issue here is that the author authority just work in xmlui and I'm not able to have the xmlui working inside eclipse
[20:40] <bollini> anyway, now I have access to the demo website and I can investigate further on the data to see if I'm able to catch the bug
[20:40] <tdonohue> ok, sounds good. Let us know if you need help along the way, and thanks!
[20:41] <mhwood> Would it be difficult to write a test for it, to drive the code in a debugger if that's what you need?
[20:42] <tdonohue> might be possible to write a test for, but we probably first need to figure out how to semi-reliably trigger it. It is rampant on demo.dspace.org, so that might be the best place to find out what is going on
[20:42] <bollini> I guess that we need to understand which are the step to reproduce the bug to be able to write an unit test
[20:42] <mhwood> True.
[20:42] <tdonohue> In any case, let us know if you need help. Moving along for now
[20:43] <tdonohue> DS-3154
[20:43] <kompewter> [ https://jira.duraspace.org/browse/DS-3154 ] - [DS-3154] Maven release process fails when using Java 8 because of Javadocs errors - DuraSpace JIRA
[20:43] <bollini> btw, anyone here can confirm that xmlui 6 works inside eclipse?
[20:43] <tdonohue> this (3154) is just waiting on RC3 to "prove" it is fixed
[20:44] <tdonohue> bollini: XMLUI 6 works in *NetBeans* (what I use)... I'd assume it should also work in Eclipse. Some things that occasionally help... running "mvn clean install" (to ensure ~/.m2/ is fully populated)...and I think XMLUI needs a "dspace.dir" property passed in
[20:45] <tdonohue> So, in NetBeans, I have to right click on the XMLUI project and ensure I set a "dspace.dir" property for that. I'm not sure how to do the same in Eclipse
[20:46] <tdonohue> in any case, moving along..
[20:46] <bollini> tdonohue yes I do that also for jspui in the context.xml file of the server. Ok I will try again
[20:46] <tdonohue> DS-3097
[20:46] <kompewter> [ https://jira.duraspace.org/browse/DS-3097 ] - ('Unexpected error:', <type 'exceptions.AttributeError'>)
[20:47] <tdonohue> This one was discussed in the backlog hour. bollini will be creating a patch
[20:47] <tdonohue> moving along.. DS-3086
[20:47] <kompewter> [ https://jira.duraspace.org/browse/DS-3086 ] - [DS-3086] OAI Harvester is broken (NPEs around several classes) - DuraSpace JIRA
[20:47] <tdonohue> Still just needs updated docs for OAI harvesting
[20:47] <tdonohue> Atmire folks have been pinged several times recently
[20:48] <tdonohue> next, DS-2948
[20:48] <kompewter> [ https://jira.duraspace.org/browse/DS-2948 ] - [DS-2948] Filter-media-> file metadata indexed in full text - DuraSpace JIRA
[20:48] <tdonohue> DSPR#1488
[20:48] <kompewter> [ https://github.com/DSpace/DSpace/pull/1488 ] - DS-2948 : Set Solr captureAttr to true when indexing full text by robintaylor
[20:48] * lap82 (5feed229@gateway/web/freenode/ip.95.238.210.41) Quit (Quit: Page closed)
[20:48] <tdonohue> Has a recent PR from robint. It's a tiny change to Solr configs, but probably could use more testing
[20:50] <tdonohue> Anyone interested in helping test this out? It's probably not a "must have" for 6.0 anymore...we could wait if we are worried about implications. But if we can get it tested, it's a small important change
[20:50] <bollini> I will try
[20:50] <tdonohue> Thanks bollini
[20:51] <tdonohue> moving along, DS-2895
[20:51] <kompewter> [ https://jira.duraspace.org/browse/DS-2895 ] - ('Unexpected error:', <type 'exceptions.AttributeError'>)
[20:51] <tdonohue> has a PR for 6.x...PR coming for 5.x. I'd be willing to test the PR for 6.x just to verify (code looks good though)
[20:53] <tdonohue> next up, DS-2687
[20:53] <kompewter> [ https://jira.duraspace.org/browse/DS-2687 ] - [DS-2687] When deleting a collection role the group is also deleted, which is not appropriate for non-system-created groups - DuraSpace JIRA
[20:53] * lap82 (5feed229@gateway/web/freenode/ip.95.238.210.41) has joined #duraspace
[20:54] <tdonohue> This one seems like we might want to downgrade if it doesn't get a PR soon. The major issue (described in related DS-3024) was already fixed. What remains is still an issue, but less severe
[20:54] <kompewter> [ https://jira.duraspace.org/browse/DS-3024 ] - [DS-3024] "Administrator" and "Anonymous" groups can be renamed, which would cause them to no longer function in 6.x - DuraSpace JIRA
[20:56] <tdonohue> Added a comment to ping hpottinger on this one
[20:56] <tdonohue> next up, DS-1929 / DSPR#1476
[20:56] <kompewter> [ https://github.com/DSpace/DSpace/pull/1476 ] - DS-1929 Permit bitstream embargo edit only via Edit Policy by cwilper
[20:56] <kompewter> [ https://jira.duraspace.org/browse/DS-1929 ] - [DS-1929] editing bitstream description changes bitstream resourcepolicies - DuraSpace JIRA
[20:56] <tdonohue> This one just needs testing...and I just realized I assigned this to myself (and forgot about it) :)
[20:57] <tdonohue> So, I'll try and get this tested this week. Other reviews also welcome, of course
[20:57] <lap82> Sorry guys I'm left the chat now, I have update the https://github.com/DSpace/DSpace/pull/896 just now. Tomorrow I try to investigate in depth.
[20:57] <kompewter> [ DS-1814: Allow submitter to create new version of their items. by pnbecker · Pull Request #896 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/896
[20:58] <lap82> Bye bye
[20:58] * lap82 (5feed229@gateway/web/freenode/ip.95.238.210.41) Quit (Quit: Page closed)
[20:58] <tdonohue> Last one is DS-1814 / DSPR#896 (which lap82 just mentioned)
[20:58] <kompewter> [ https://github.com/DSpace/DSpace/pull/896 ] - DS-1814: Allow submitter to create new version of their items. by pnbecker
[20:58] <kompewter> [ https://jira.duraspace.org/browse/DS-1814 ] - [DS-1814] Allow submitter to create a new version of an item - DuraSpace JIRA
[20:59] <bollini> ok, so we have a plan for this one
[20:59] <tdonohue> So, it sounds like we have good movement here overall for 6.0. We have PRs for most everything (or at least plans for PRs soon), it's just a matter of getting them all reviewed/tested
[21:01] <tdonohue> I think the goal for the next week is to get this list down to <10 (currently at 15)...ideally we find time to get these all done (except docs), but I realize our group is still a bit small these days (lots of inactive committers)
[21:02] <tdonohue> I'd *really* like to get an RC3 released next week (or end of Aug at the latest)...but I'd like to get a few more of the major PRs ready to go, so we can announce RC3 for testing (even if it has a few "known" minor issues left)
[21:03] <bollini> which is the plan for a 5.6? after or before the 6.0?
[21:04] <tdonohue> My anticipation right now is that 5.6 would likely be around the same time as 6.0 (there's still a few tickets left for that, but not many). If someone wants to help get that released *sooner*, I'm fine with that, but I'd need help from others (to get everything prepped and ready)
[21:05] <mhwood> Sorry, I've got to leave now.
[21:05] <tdonohue> otherwise, I might be able to find cycles myself to "cut" 5.6 around the same time as 6.0.
[21:05] <mhwood> 'bye, all.
[21:05] <tdonohue> So, currently, my plan is to do them both around the same time...unless someone else is willing to take 5.6 and help move it forward more rapidly
[21:05] <tdonohue> thanks mhwood. bye!
[21:06] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:06] <bollini> ok tim, I cannot promise more at the moment. If we find more time for the 5.6 I will let you know
[21:07] <tdonohue> My personal priority right now is getting 6.0 out the door, as I want to get work on the new 7.0 UI kicked off (before momentum on that starts to subside). 5.6 is still important, but it's fallen off my plate a bit as of late.
[21:07] <tdonohue> thanks bollini!
[21:08] <tdonohue> Since it seems like everyone else has left already (except bollini and I), we'll close things up for today. See you next week. Thanks bollini for sticking around late!
[21:09] <bollini> bye
[21:09] <kompewter> see ya
[21:09] * bollini (4f2c0dcb@gateway/web/freenode/ip.79.44.13.203) Quit (Quit: Page closed)
[21:34] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.