Timestamps are in GMT/BST.
[2:08] * misilot (~misilot@p-body.lib.fit.edu) Quit (Remote host closed the connection)
[4:09] * srobbins_ (~srobbins@libstfsdg02.library.illinois.edu) has joined #duraspace
[4:11] * srobbins (~srobbins@libstfsdg02.library.illinois.edu) Quit (Read error: Connection reset by peer)
[4:11] * srobbins_ is now known as srobbins
[6:50] -leguin.freenode.net- *** Looking up your hostname...
[6:50] -leguin.freenode.net- *** Checking Ident
[6:50] -leguin.freenode.net- *** Found your hostname
[6:50] -leguin.freenode.net- *** No Ident response
[6:50] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:50] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:50] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[10:57] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[13:17] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:40] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[14:41] * awoods (~awoods@c-98-245-50-182.hsd1.co.comcast.net) has joined #duraspace
[14:57] * tdonohue Reminds everyone the DSpace DevMtg starts in just a few minutes!
[14:57] <tdonohue> Agenda at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-11-04
[14:57] <kompewter> [ DevMtg 2015-11-04 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-11-04
[15:00] <tdonohue> Hello all, it's time for our DSpace Developers Mtg. (Agenda pasted above)
[15:01] <tdonohue> Since both North America & Europe just exited daylight savings, this is an hour earlier...so I'm going to ping the usual suspects/committers (helix84, mhwood, pbecker, peterdietz, terry-b)
[15:01] <pbecker> hi tdonohue, hi *
[15:01] <mhwood> Zzzzz...uh, here!
[15:02] <tdonohue> Ok, so, the first topic for today is trying to finalize things for 5.4, and get a sense of whether we think we can release it this week, or if we need to recommend a delay to aschweer (who won't be here, as it's middle of the night for her)
[15:03] <tdonohue> Here's our still open PRs for 5.4...there's still 10 open, but most of these are rather small: https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A5.4
[15:03] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A5.4
[15:03] <pbecker> First I want to thank tdonohue for fixing DS-2736, DS-2737 and DS-2738!
[15:03] <kompewter> [ https://jira.duraspace.org/browse/DS-2736 ] - ('Unexpected error:', <type 'exceptions.AttributeError'>)
[15:03] <kompewter> [ https://jira.duraspace.org/browse/DS-2737 ] - ('Unexpected error:', <type 'exceptions.AttributeError'>)
[15:03] <kompewter> [ https://jira.duraspace.org/browse/DS-2738 ] - ('Unexpected error:', <type 'exceptions.AttributeError'>)
[15:04] <tdonohue> you're welcome. Hopefully the fixes are all correct (I don't tend to work with the JSPUI, but these all seemed like low-hanging fruit) ;)
[15:04] <pbecker> I just merged his PR against the first two of them into our dspace-5_x branch. Currently I'm porting the fix to dspace-3_x dspace-4_x and master.
[15:05] <pbecker> I'm not sure about DS-2738 yet, as it might affect with community/collection admins. But I hope to be able to test it today.
[15:05] <kompewter> [ https://jira.duraspace.org/browse/DS-2738 ] - ('Unexpected error:', <type 'exceptions.AttributeError'>)
[15:05] <pbecker> s/with/
[15:05] <kompewter> pbecker meant to say: I'm not sure about DS-2738 yet, as it might affect community/collection admins. But I hope to be able to test it today.
[15:05] <tdonohue> So, for 5.4, I suspect it would be useful to go through the remaining PRs today (either now or during JIRA review...or a bit of both). Any objections to looking at some of these now?
[15:05] <peterdietz> i can review
[15:06] <mhwood> OK
[15:06] * pbecker is slightly distracted by rebasing the fix for 2736 and 2737. But please go on.
[15:06] <tdonohue> Here's the list..https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A5.4
[15:06] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A5.4
[15:06] <tdonohue> I'm going to *skip* the top one (#1147) as pbecker will be testing & reviewing and it might need a small update
[15:07] <tdonohue> so, DSPR#1146 is next
[15:07] <kompewter> [ https://github.com/DSpace/DSpace/pull/1146 ] - DS-2542: Fix bug for day granularity (from zuki's PR#912) by tdonohue
[15:07] <tdonohue> This is a tiny fix, initially from zuki for DS-2542. However, as noted in the final comments of that ticket, it doesn't solve *everything*...just 99% of it
[15:07] <kompewter> [ https://jira.duraspace.org/browse/DS-2542 ] - [DS-2542] XOAI does not support non granular YYYY-MM-DD harvesting properly - DuraSpace JIRA
[15:08] <tdonohue> So, the question here is really.... is this "good enough" for now/5.4? We can log a ticket for the remaining issue for post-5.4 (as it'll require a bigger XOAI fix)
[15:09] <mhwood> 99% better is a lot better. :-)
[15:09] <tdonohue> yea, that's my feeling too. See my comment here: https://jira.duraspace.org/browse/DS-2542?focusedCommentId=46502&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-46502
[15:09] <kompewter> [ [DS-2542] XOAI does not support non granular YYYY-MM-DD harvesting properly - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-2542?focusedCommentId=46502&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-46502
[15:09] <kompewter> [ https://jira.duraspace.org/browse/DS-2542 ] - [DS-2542] XOAI does not support non granular YYYY-MM-DD harvesting properly - DuraSpace JIRA
[15:09] <mhwood> Who knows? XOAI 4 may fix this, or make the necessary changes different.
[15:10] <tdonohue> mhwood: yes, I was thinking the same thing. We might want to first work on upgrading to XOAI 4 instead of concentrating too much more effort on major issues in XOAI 3
[15:10] <mhwood> Indeed.
[15:11] <tdonohue> So, with PR #1146, any objections to merging this for 5.4 and closing 2542 & opening a new ticket for the remaining "midnight issue"? (I'll open the new ticket)
[15:11] <mhwood> None here.
[15:11] <peterdietz> It looks like its progress on this front
[15:12] <tdonohue> ok, I'll consider that approval (along with cjuergen's tests + aschweer's comments on the ticket). I'll press the green button, close the existing ticket & open up a new one post-mtg
[15:13] <tdonohue> merged
[15:13] <tdonohue> next in our list: DSPR#1122
[15:13] <kompewter> [ https://github.com/DSpace/DSpace/pull/1122 ] - DS-2831 connections cleanup and context reuse by arnodb
[15:14] <tdonohue> This code looks right/obvious to me...and it's a necessary cleanup of a Context that is just left open/hanging
[15:14] <peterdietz> yep
[15:15] <mhwood> Nothing obviously wrong.
[15:15] <peterdietz> This is also very related to DSPR#1134, so whatever we vote on this, should also apply the other
[15:15] <kompewter> [ https://github.com/DSpace/DSpace/pull/1134 ] - DS-2831 connections cleanup, context reuse (master) by arnodb
[15:16] <tdonohue> peterdietz: did you give 1134 a test? Just curious, as they are the same fix (for master vs 5.x)
[15:16] <peterdietz> unfortunately no, i haven't run this. So hopefully no spooky side effects
[15:16] <tdonohue> would one of you be willing to give these a really quick test today. They look obvious, but I wonder if it's worth testing one/both
[15:17] <terry-b> tdonohue, just signing on
[15:17] <peterdietz> Yes, I can give them a run really quick. (quick means ~ 20 minutes)
[15:18] <tdonohue> peterdietz: thanks. Once they are tested, please merge! They have approval it sounds like
[15:18] <tdonohue> moving along then.. DSPR#1121
[15:18] <kompewter> [ https://github.com/DSpace/DSpace/pull/1121 ] - DS-2830 add proper synchronization in TokenHolder by arnodb
[15:19] <tdonohue> This is a REST specific issue. It looks reasonable, but I don't know this area of the code so well (yet)
[15:19] <tdonohue> It definitely *seems* right...a generation of a token should be synchronized :)
[15:19] <mhwood> Hm, is this one finished? Or is there an open question?
[15:20] <peterdietz> I haven't encountered this issue, but Arnaud's been doing some refined interactions with DSpace via REST. i.e. Using WADL, generating code. So perhaps he also has been profiling login/logout to discover this
[15:20] <tdonohue> mhwood: I think the open question was about porting this forward to "master"? Maybe peterdietz can clarify
[15:20] <peterdietz> 1121 is good, for 5x
[15:21] <peterdietz> For 6x, the code is ever so different, we have a different data structure that contains the tokens, we could replace it with a Synchronized data structure, or manually have a synchronized block
[15:22] <tdonohue> peterdietz: do you want to go ahead and merge this one too then? Maybe open up a new ticket for moving it forward to "master"? Or would you rather wait to see a solution for "master" too?
[15:22] <peterdietz> he hasn't filed a proper PR, but he has a branch for master https://github.com/DSpace/DSpace/compare/master...arnodb:DS-2830-rest-authentication-safety-master
[15:22] <kompewter> [ Comparing DSpace:master...arnodb:DS-2830-rest-authentication-safety-master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/compare/master...arnodb:DS-2830-rest-authentication-safety-master
[15:22] <kompewter> [ https://jira.duraspace.org/browse/DS-2830 ] - [DS-2830] REST API login/logout thread-safety - DuraSpace JIRA
[15:22] <peterdietz> Would it be strange to create PR on his behalf? I know he suggested it to us
[15:23] <tdonohue> peterdietz: oh, I see. So, it sounds like this one should be merged, and you should prompt him to create a PR for "master". If he doesn't create it, you could, but I bet he'd be willing
[15:24] <mhwood> Just leave the ticket open and attach the second PR? I think it would be sensible.
[15:24] <tdonohue> In any case, it sounds like you have these in hand, peterdietz. I'd say merge them once you are satisfied
[15:24] <peterdietz> I have just made a PR, from his suggestion. https://github.com/DSpace/DSpace/pull/1150
[15:24] <kompewter> [ DS-2830 (Master) add proper synchronization in TokenHolder by peterdietz · Pull Request #1150 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1150
[15:24] <peterdietz> Okay. I will merge this to 5x and master
[15:24] <tdonohue> moving along then... DSPR#1120
[15:24] <kompewter> [ https://github.com/DSpace/DSpace/pull/1120 ] - DS-2823: Limit Solr text field size to 10,000 tokens by tdonohue
[15:25] <tdonohue> Oh, this one. So, I'm seriously considering just withdrawing this PR until we figure out a way to get Solr configs to be easier to manage
[15:25] <tdonohue> It turned out to be a "red herring" to my other Solr memory issues...and now, the 10K token thing doesn't matter too much (doesn't affect memory really)
[15:26] <tdonohue> It still might be a worthwhile config for "some day", but I'm less interested in forcing it into 5.4... thoughts?
[15:26] <mhwood> That seems reasonable.
[15:26] <peterdietz> What was the one that you discovered it was putting the fulltext inside, or loading it
[15:26] <peterdietz> 1124
[15:27] <tdonohue> peterdietz: yes, this PR (1120) was a "red herring" for the other PR (1124) which fixed the issue of loading the fulltext of every doc in memory
[15:27] <tdonohue> So, 1120 really doesn't do anything to help with memory issues
[15:27] <tdonohue> as those were fixed in 1124
[15:27] <tdonohue> I'll leave 1120 open for now, but I'm "descheduling" it from 5.4
[15:28] <mhwood> So, it would be nice to make this more readily configurable, but perhaps it should be rolled into a general "make Solr configuration easier" effort.
[15:28] <tdonohue> mhwood: yes, likely it should
[15:28] <tdonohue> ok, done. taken this one off of 5.4
[15:28] <tdonohue> next, DSPR#1107
[15:29] <kompewter> [ https://github.com/DSpace/DSpace/pull/1107 ] - DS-2699 Only escape colon-space, not other characters by aschweer
[15:29] <tdonohue> this one looks right to me, but I admit to not having tested it yet. Looks like it may need JSPUI testing too
[15:30] <tdonohue> It *was* tested by other users (who commented on DS-2699)
[15:30] <kompewter> [ https://jira.duraspace.org/browse/DS-2699 ] - [DS-2699] Search not working as expected - DuraSpace JIRA
[15:31] <tdonohue> pbecker: any chance you can give 1107 a test for JSPUI today as well?
[15:32] <mhwood> The rationale is sound, and the code seems to follow it.
[15:32] <tdonohue> Or anyone else have time to run a quick test here?
[15:32] <pbecker> one moment please
[15:33] <pbecker> I doubt that. Will have to leave in two hours and have to mutch left open. Sorry.
[15:34] <tdonohue> ok, I'll try and run a quick test then today...this looks right to me though
[15:34] <tdonohue> next up, DSPR#1056
[15:34] <kompewter> [ https://github.com/DSpace/DSpace/pull/1056 ] - DS-2750 REST API ignores expand=all on communities by helix84
[15:34] <peterdietz> I'm -1 on this
[15:35] <peterdietz> 1) It won't do what you think it will, and 2) I could be a performance disaster on large sites.
[15:35] <peterdietz> A positive would be for smaller sites that want to grab data of your entire site in one request
[15:36] <tdonohue> peterdietz: so, you initially added a +1 here...do you want to update your vote here with a comment?
[15:36] <terry-b> Eventually, we will need a way to efficiently pull the comm/coll hierarchy as a hierarchy
[15:36] <mhwood> I think he did?
[15:36] <peterdietz> look below
[15:36] <tdonohue> Oh, wait, I see...your last one did :)
[15:36] <tdonohue> sorry, I missed the final comment
[15:36] <peterdietz> final thought helix84 ?
[15:37] <tdonohue> Ok, it sounds like 1056 should minimally be de-scheduled from 5.4. Needs more work
[15:37] <peterdietz> terry-b: Yes, I agree. So, I'm not entirely opposed to the idea, but if you could figure out an efficient way to grab everything
[15:37] <peterdietz> ..this pr wouldn't accomplish that
[15:38] <peterdietz> I{'m going to close this one then?
[15:38] <tdonohue> So, should we... (1) close the PR, (2) deschedule this ticket from 5.4, and (3) change ticket to "needs volunteer" status again?
[15:38] <terry-b> peterdietz, we could create a minimal structure to hold hierarchy... unless hibernate caching would make things so fast it isn;t needed
[15:39] <tdonohue> peterdietz: feel free to close the PR. I'll update the ticket
[15:39] <peterdietz> okay
[15:40] <peterdietz> In my former life, I had made a LiteCollection, to minimize how much data got pulled: https://github.com/osulibraries/DSpace/blob/osukb/dspace-api/src/main/java/org/dspace/content/LiteCollection.java
[15:40] <kompewter> [ DSpace/LiteCollection.java at osukb · osulibraries/DSpace · GitHub ] - https://github.com/osulibraries/DSpace/blob/osukb/dspace-api/src/main/java/org/dspace/content/LiteCollection.java
[15:40] <peterdietz> But.. If hibernate could be efficient / lazy about things, that would be great
[15:41] <peterdietz> Even caching. Hey, here is another of the same request, has the underlying data changed, such that you need to redo the query, or do you have the data already available
[15:41] <tdonohue> ok, moving along for now... next up, DSPR#1050
[15:41] <kompewter> [ https://github.com/DSpace/DSpace/pull/1050 ] - DS-1207: Stop throwing ResourceNotFoundException for redirects by cwilper
[15:42] <tdonohue> This to me, looks like a very obvious/beneficial fix +1
[15:42] <peterdietz> yeah, looks good from inspection
[15:42] <mhwood> Sensible.
[15:43] <tdonohue> Ok, I'll merge this one post-meeting & cherry-pick to 5.x (as it needs to be in both places)
[15:45] <tdonohue> next up, DSPR#1028
[15:45] <kompewter> [ https://github.com/DSpace/DSpace/pull/1028 ] - DS-2719 fix /{collection_id}/items to properly process offset parameter by akinom
[15:45] <peterdietz> So many REST issues
[15:45] <peterdietz> travis fails on this one
[15:45] <mhwood> Ran afoul of the nexus.codehaus.org problem.
[15:45] <tdonohue> well, REST is still "new" :) It's actually a good thing though, as it means people are *using* REST
[15:46] <tdonohue> I'll restart that build
[15:47] <tdonohue> so, in reality, this is a one-liner it seems... rest of the PR is "cleanup" https://github.com/DSpace/DSpace/pull/1028/files
[15:47] <kompewter> [ DS-2719 fix /{collection_id}/items to properly process offset parameter by akinom · Pull Request #1028 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1028/files
[15:47] <peterdietz> interesting.. This is the same PR (sort of) as: https://github.com/DSpace/DSpace/pull/992
[15:47] <kompewter> [ Fix bug DS-2655 REST api collection items 'offset' does not function … by edgo914 · Pull Request #992 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/992
[15:48] <tdonohue> peterdietz is one preferrable to the other?
[15:48] <tdonohue> They do look to touch the same bit of code, but make a very different change?
[15:48] <terry-b> I feel like there was a similar issue that I reported and Kevin resolved
[15:49] <peterdietz> What does this mean? (void) dspaceItems.nextID();
[15:49] <tdonohue> Sounds like we need testing/verification between DS-2719 and DS-2655
[15:49] <kompewter> [ https://jira.duraspace.org/browse/DS-2719 ] - [DS-2719] rest /colections/<id>/items ignores offset parameter - DuraSpace JIRA
[15:49] <kompewter> [ https://jira.duraspace.org/browse/DS-2655 ] - [DS-2655] REST api collection items 'offset' does not function correctly - DuraSpace JIRA
[15:50] <tdonohue> peterdietz: I'm not entirely sure what the "(void)" does there...I had assumed it was something in REST that I wasn't familiar with
[15:50] <terry-b> I was thinking of https://github.com/DSpace/DSpace/pull/1073/files
[15:50] <peterdietz> I think it means don't waste memory storing the returned value.
[15:50] <kompewter> [ [DS-2764] CollectionDAOImpl - Parameters Switched by KevinVdV · Pull Request #1073 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1073/files
[15:50] <mhwood> My guess would be to quiet the compiler concerning an unused return value.
[15:50] <peterdietz> They are just incrementing
[15:50] <peterdietz> The other is org.dspace.content.Item dspaceItemx = dspaceItems.next();
[15:51] <tdonohue> My recommendation here would be that we test the solutions here and choose one. They look like they are doing essentially the same thing
[15:52] <tdonohue> peterdietz: are you willing/up for this one as well? It looks like there *is* a bug here...it's just a matter of which PR to choose for 5.4 (and then closing out the other PR/Ticket as well)
[15:53] <peterdietz> I'm thinking to go with Monika's. It will be a tad better performance, as nextid doesn't hit the DB
[15:53] <peterdietz> And then we need to link these PR's/JIRA as duplicate
[15:53] <tdonohue> peterdietz: sounds fine. I linked up the JIRA tickets as duplicates. So, once this is merged, feel free to close everything out
[15:54] <peterdietz> do i ignore the nexus.codehaus.org issues with travis?
[15:54] <peterdietz> because travis builds her exact code, but the 5.4 code has updated poms
[15:56] <tdonohue> I'd recommend cherry-picking her commit & running tests locally, since Travis is having issues. Chances are things *should* be fine on latest master/5.x, but it'd be good to verify
[15:56] <tdonohue> it's either that or rebasing her PR & then seeing what Travis says
[15:56] <tdonohue> I'd be nervous about just merging anyways, in case there *are* some other issues that are being 'hidden' (doubtful though in this case)
[15:57] <tdonohue> one LAST PR for 5.4: DSPR#1014
[15:57] <kompewter> [ https://github.com/DSpace/DSpace/pull/1014 ] - Revert "DS-1821 Internationalize the bitstream access icon alt text" by helix84
[15:58] <tdonohue> aschweer reviewed this and said it's likely "the way to go"
[15:58] <tdonohue> It's just undoing an old change, so it seems like something to just merge
[15:58] <mhwood> Yes.
[15:58] <tdonohue> Ok, I'll merge this one & cherry-pick as well. Assigning the PR to me
[15:59] <tdonohue> BTW... I just assigned all the PRs except the first one: https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A5.4
[15:59] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A5.4
[15:59] <tdonohue> So, looks like we are VERY near to 5.4 and just need to merge/backport these last few PRS
[16:00] <tdonohue> And unfortunately, that took the entire meeting...but I think it was worth our time today nonetheless
[16:00] <mhwood> We need to get 5.4 over and done with so we can think about 6.0.
[16:01] <tdonohue> So, I'm going to save the 6.0 topics for next week. Especially the "teaser" about possibly deprecating Elastic Search stats in 6.0. So, please do gather your thoughts on whether you think that's a good idea (both folks here & any reading this later on)
[16:01] <tdonohue> mhwood++
[16:01] <tdonohue> As for 5.4, it sounds like it still *might* be possible to release it *this week*...if we can knock out these final PRs today
[16:02] <tdonohue> Any other final thoughts/comments/questions for today before we close out the meeting?
[16:03] <mhwood> None here.
[16:03] <tdonohue> Ok, hearing none. We'll consider today's meeting closed! Thanks all
[17:25] * helix84 (~ctenar@195.178.95.132) Quit (Ping timeout: 250 seconds)
[17:32] * helix84 (~ctenar@195.178.95.132) has joined #duraspace
[18:22] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[21:14] * bram___ (~bram@62-205-65-213.access.telenet.be) has joined #duraspace
[21:17] <bram___> hi
[21:41] * bram___ (~bram@62-205-65-213.access.telenet.be) Quit (Quit: bram___)
[22:02] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:38] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.