Timestamps are in GMT/BST.
[6:56] -adams.freenode.net- *** Looking up your hostname...
[6:56] -adams.freenode.net- *** Checking Ident
[6:56] -adams.freenode.net- *** Found your hostname
[6:56] -adams.freenode.net- *** No Ident response
[6:56] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:56] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:56] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[9:01] * circ-user-BLlXE (~circuser-@186.2.47.179) has joined #duraspace
[9:03] * circ-user-BLlXE (~circuser-@186.2.47.179) Quit (Remote host closed the connection)
[12:13] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:05] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[13:52] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[14:00] * DSpaceSlackBot (~DSpaceSla@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[19:00] * ntorres (5e3dc204@gateway/web/freenode/ip.94.61.194.4) has joined #duraspace
[19:07] * ntorres (5e3dc204@gateway/web/freenode/ip.94.61.194.4) Quit (Quit: Page closed)
[19:55] <DSpaceSlackBot> <tdonohue> @here: The DSpace Developers Meeting begins here at the top of the hour. https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-04-12
[19:55] <kompewter> [ DevMtg 2017-04-12 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-04-12
[20:01] <DSpaceSlackBot> <tdonohue> @here: Hi all, welcome to the our DSpace Developers Meeting. Agenda is above
[20:02] <DSpaceSlackBot> <tdonohue> First, a quick sidenote... I've been a bit out of the loop the last few weeks here, but I think I've mostly caught up from my two weeks out.
[20:03] <DSpaceSlackBot> <tdonohue> That said, if there's something that is awaiting my feedback, send me a reminder this week or next ;)
[20:03] <DSpaceSlackBot> <tdonohue> A quick reminder here that our next DSpace 7 UI meeting is tomorrow in *Slack* at 16:00 UTC (12pm EDT)
[20:03] <DSpaceSlackBot> <tdonohue> I'll send out an email reminder to dspace-devel as well after this meeting
[20:05] <DSpaceSlackBot> <tdonohue> Our list of "high priority" tickets is a bit big these days... looking to narrow to 6.1 tickets here
[20:05] <mhwood> There be very few here today.
[20:06] <DSpaceSlackBot> <tdonohue> Here's the 6.1 high priority listing: https://jira.duraspace.org/issues/?jql=filter%20%3D%2013904%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20%20fixVersion%20DESC%2C%20priority%20DESC%20%20%20
[20:06] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/issues/?jql=filter%20%3D%2013904%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20%20fixVersion%20DESC%2C%20priority%20DESC%20%20%20
[20:06] <DSpaceSlackBot> <tdonohue> @mwood: There's (seemingly) a few more here in Slack attending...or at least 6 folks show as "online" here
[20:08] <DSpaceSlackBot> <tdonohue> So, in terms of the 6.1 high priority tickets, I'd like to run through this list quickly...as my goal is still to close out this 6.1 release as soon as we can (or at least start to get towards setting a goal for a release date)
[20:08] <DSpaceSlackBot> <tdonohue> First up on my list is DS-3552
[20:08] <kompewter> [ https://jira.duraspace.org/browse/DS-3552 ] - [DS-3552] Select Collection step and submissions page load very slow on large repositories due to Hibernate - DuraSpace JIRA
[20:08] <DSpaceSlackBot> <tdonohue> This one has a PR... DSPR#1694
[20:09] <kompewter> [ https://github.com/DSpace/DSpace/pull/1694 ] - Ds 3552 read only context and hibernate improvements by tomdesair ¡ Pull Request #1694 ¡ DSpace/DSpace ¡ GitHub
[20:10] <DSpaceSlackBot> <tdonohue> There are quite a few changes in this PR...but at a glance they seem reasonable. Nonetheless, I could use some help reviewing & testing this
[20:10] <DSpaceSlackBot> <tdonohue> So, if anyone is interested in volunteering to help with either in the coming week, let me know (or assign yourself as a reviewer on the PR)
[20:12] <DSpaceSlackBot> <tdonohue> As a sidenote, I noted this in the PR, but there's a related (new) ticket around performance of OAI indexing on large sites: DS-3559 / DSPR#1704 that could also use more eyes/testing
[20:12] <kompewter> [ https://jira.duraspace.org/browse/DS-3559 ] - [DS-3559] OAI Indexing extremely slow and memory inefficient for bigger amount of items - DuraSpace JIRA
[20:12] <kompewter> [ https://github.com/DSpace/DSpace/pull/1704 ] - DS-3559 Allow creation of OAI index for large repositories (V2) by christian-scheible
[20:13] <DSpaceSlackBot> <tdonohue> Next up in the list is DS-3558 (which is new to this list) / DSPR#1707
[20:13] <kompewter> [ https://github.com/DSpace/DSpace/pull/1707 ] - DS 3558 Case-insensitive bot matching option by Frederic-Atmire
[20:13] <kompewter> [ https://jira.duraspace.org/browse/DS-3558 ] - [DS-3558] Case-insensitive bot user agent matching can have performance impact - DuraSpace JIRA
[20:14] <DSpaceSlackBot> <tdonohue> I gave the PR here a quick review and noted one minor comment. But again, I'd appreciate more eyes/reviews/testing here
[20:15] <DSpaceSlackBot> <tdonohue> I'm not sure if this really is a "critical" bug, but it does sound annoying in terms of performance. So, I'm willing to try and get this into 6.1 too
[20:16] <DSpaceSlackBot> <tdonohue> Next up is DS-3447
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-3447 ] - [DS-3447] Transition ORCID integration to ORCID API 2.0 - DuraSpace JIRA
[20:16] <DSpaceSlackBot> <tdonohue> This one is still waiting for a volunteer. So, it seems likely to miss 6.1, unless someone moves on it quickly
[20:17] <DSpaceSlackBot> <tdonohue> next is DS-3389.... which is just awaiting docs from @hpottinger , it seems?
[20:17] <kompewter> [ https://jira.duraspace.org/browse/DS-3389 ] - [DS-3389] Replication Task Suite add-on doesn't work with DSpace 6 API - DuraSpace JIRA
[20:18] <DSpaceSlackBot> Action: tdonohue notes that our attendance is quite sparse...or everyone is very quiet ;)
[20:18] <DSpaceSlackBot> <tdonohue> I'm just going to keep moving though and hopefully folks read the notes
[20:19] <DSpaceSlackBot> <tdonohue> DS-3287 also needs a volunteer & is likely to miss 6.1
[20:19] <mhwood> 3447 likely will need to shift to 6.later. It doesn't become urgent until Fall.
[20:19] <kompewter> [ https://jira.duraspace.org/browse/DS-3287 ] - [DS-3287] ElasticSearch fails (does not work at all) - DuraSpace JIRA
[20:19] <DSpaceSlackBot> <tdonohue> mhwood: true, it's not highest priority yet...but soon(ish)
[20:19] <mhwood> Sorry, falling behind pondering these.
[20:21] <DSpaceSlackBot> <tdonohue> next up on this list is DS-2877. I'm not sure this belongs here. There's a new comment on it, but it sounds too big to consider for 6.1 at this point
[20:21] <kompewter> [ https://jira.duraspace.org/browse/DS-2877 ] - [DS-2877] Import of ScienceDirect metadata including embargo and linking to or embedding of the final version - DuraSpace JIRA
[20:22] <DSpaceSlackBot> <tdonohue> I'm going to remove "Fix Version" 6.1 from this one. It's probably more of a 6.later as well
[20:23] <mhwood> Another 6.later. It's big and I for one haven't looked at it for some time, so it will take a while to re-familiarize.
[20:23] <DSpaceSlackBot> <tdonohue> done
[20:24] <DSpaceSlackBot> <tdonohue> next is DS-3406
[20:24] <kompewter> [ https://jira.duraspace.org/browse/DS-3406 ] - [DS-3406] Sub-communities and collections not sorted alphabetically - DuraSpace JIRA
[20:24] <DSpaceSlackBot> <tdonohue> It has two PRs... but Tom Desair recommended the DSPR#1684 approach for 6.1
[20:24] <kompewter> [ https://github.com/DSpace/DSpace/pull/1684 ] - DS-3406: Sort communities and collections in-memory using a comparator by tomdesair
[20:25] <DSpaceSlackBot> <tdonohue> This one needs review / testing help as well. We are lacking on testers for several of these outstanding PRs
[20:26] <DSpaceSlackBot> <tdonohue> Finally, in our 6.1 High Priority list is DS-3564...another new entry
[20:26] <kompewter> [ https://jira.duraspace.org/browse/DS-3564 ] - [DS-3564] Change default value for db.maxidle - DuraSpace JIRA
[20:27] <mhwood> Sounds reasonable. Needs volunteer.
[20:27] <DSpaceSlackBot> <tdonohue> I'm not against this concept and it seems like a small change.
[20:28] <mhwood> One of a number of things where we could move from "works..." to "works well".
[20:28] <mhwood> OK, I took it.
[20:29] <DSpaceSlackBot> <tdonohue> Ok, thanks mhwood! Don't forget to update the comments around that setting based on the new default ;)
[20:29] <mhwood> Yup. "Documentation: needed"
[20:30] <DSpaceSlackBot> <tdonohue> That's it for our list
[20:31] <DSpaceSlackBot> <tdonohue> So, we have about a 1/2 hour remaining. Are there other topics that folks want to discuss? Should we stick around and look at some recent PRs?
[20:32] <mhwood> I'd just like to mention DS-3505 since I think it won't get more attention without me begging. I think it's an unpopular configuration.
[20:32] <kompewter> [ https://jira.duraspace.org/browse/DS-3505 ] - [DS-3505] Bad redirection from logout action - DuraSpace JIRA
[20:33] <mhwood> I need to port it to v4/5....
[20:33] <DSpaceSlackBot> <tdonohue> Thanks for the note here, mhwood. I hadn't gotten to reviewing this. Looks like Tom Desair tested/approved the DSPR#1671 associated with it
[20:33] <kompewter> [ https://github.com/DSpace/DSpace/pull/1671 ] - [DS-3505] Bad redirection from logout action by mwoodiupui
[20:35] <DSpaceSlackBot> <tdonohue> Looking at the PR, it seems this is essentially a "one-liner" (with some alignment / minor refactoring of existing code)
[20:35] <mhwood> Yes.
[20:35] <DSpaceSlackBot> <tdonohue> This looks good to me. I'll give a +1 and merge it (since it was also already tested)
[20:36] <mhwood> Thanks! I'll back-port it to 4/5.
[20:36] <DSpaceSlackBot> <tdonohue> I think it's optional to backport to 5.x or 4.x...you are welcome to do so if you want to, but this isn't a significant bug or security issue. So, backporting is optional
[20:36] <mhwood> It appears that we have a potential tester (other than me).
[20:37] <mhwood> Now that I think about it, we are running a 5.2 version here so I just need to tidy it up.
[20:38] <DSpaceSlackBot> <tdonohue> Again, I'll leave that up to you. If you want you can also simply backport to 5.x and skip over 4.x. The only times we require a backport is for security issues or significant bugs...otherwise, it's optional
[20:38] <mhwood> OK, thanks.
[20:38] <DSpaceSlackBot> <tdonohue> It's merged into 6.x now. I'll leave the ticket open for now until you decide on backporting it. If you want to backport, I'll gladly review & merge that one too (just let me know)
[20:39] <mhwood> OK, I'll keep in touch.
[20:40] <DSpaceSlackBot> <tdonohue> Any other specific tickets or PRs that folks @here would like discussed today?
[20:41] <DSpaceSlackBot> <tdonohue> Ok, not hearing any. In that case, I'll throw in a few recent PRs that could use a quick review
[20:41] <mhwood> I could draw attention to DS-2799, which needs a decision as to how we want it to behave.
[20:41] <kompewter> [ https://jira.duraspace.org/browse/DS-2799 ] - [DS-2799] Blue lock icon is misleading when logged into system - DuraSpace JIRA
[20:42] <mhwood> Can't really decide now, with so few present. I just wanted to mention it.
[20:43] <DSpaceSlackBot> <tdonohue> mhwood: for what it's worth, I think I like your last comment...except I'm not sure why we need a "PLOS Open Access un-lock icon" if it's downloadable to all. It seems like you'd just not have an icon there at all in that scenario
[20:44] <mhwood> Fair enough. Here we just replaced the lock with a transparent 64x64 blank image to wait for final resolution.
[20:46] <DSpaceSlackBot> <tdonohue> I believe the only scenario that is *wrong* currently in the codebase is when a file is locked down but you are authenticated with access. Currently, that displays a locked padlock (instead of the proposed open padlock)
[20:46] <DSpaceSlackBot> <tdonohue> The other scenarios (anonymously accessible, or locked without access to you) are already how DSpace behaves (IIRC)
[20:47] <mhwood> Well, if people can agree on what it should do then someone can make it do that. The business logic is wrong in any case.
[20:49] <DSpaceSlackBot> <tdonohue> I think we do agree... if you want to update your comment, I think that'd be great. The ticket itself never discussed the "anonymous access" scenario as it was only about access restricted files.
[20:49] <DSpaceSlackBot> <tdonohue> But, it's worth noting that for anonymous access, we should display no lock icon (as currently)
[20:50] <DSpaceSlackBot> <hpottinger> sorry, am lurking but am quite distracted by other things
[20:50] <DSpaceSlackBot> <hpottinger> I've just now caught up, and have copied down a list of things that need help testing, and docs
[20:50] <mhwood> OK: open to all = no icon; open to you but not to all = open lock; closed to you = closed lock.
[20:51] <DSpaceSlackBot> <tdonohue> +1 mhwood
[20:51] <mhwood> I will note that in the ticket.
[20:51] <DSpaceSlackBot> <hpottinger> mhwood++
[20:51] <DSpaceSlackBot> <tdonohue> And the first & third in that list are both current behavior. The only new behavior is the middle one ;)
[20:51] <mhwood> That OA un-lock was a rights mystery anyway.
[20:52] <DSpaceSlackBot> <tdonohue> Ok, we are getting short on time here...but, here's a PR that looks pretty straightforward to me. DSPR#1708
[20:52] <kompewter> [ https://github.com/DSpace/DSpace/pull/1708 ] - DS-3568. UTF-8 characters are now supported in configuration files by christian-scheible ¡ Pull Request #1708 ¡ DSpace/DSpace ¡ GitHub
[20:52] <DSpaceSlackBot> <tdonohue> Anyone willing to give this one a quick verification test (that no other issues result in reading all our configs as UTF-8)? It seems like the correct behavior, but I want to ensure no side effects here
[20:55] <mhwood> Supposing that I understand what that attribute does, this patch looks simple enough. I can try it.
[20:55] <DSpaceSlackBot> <tdonohue> Though, I guess ISO-8859-1 is a subset of UTF-8, IIRC...so, since our configs currently are read as ISO-8859-1, per DS-3568, this seems like it just "should work"
[20:55] <kompewter> [ https://jira.duraspace.org/browse/DS-3568 ] - [DS-3568] Configuration files like dspace.cfg don't support UTF-8 encoding - DuraSpace JIRA
[20:55] <DSpaceSlackBot> <tdonohue> Thanks mhwood
[20:56] <mhwood> Yes. But there is a test suggested, and it should be a good enough test.
[20:56] <DSpaceSlackBot> <tdonohue> I honestly think this "looks obvious"...just wanted to be sure that I'm also not overlooking anything here
[20:56] <DSpaceSlackBot> <tdonohue> (as breaking configs would be bad, obviously) ;)
[20:56] <mhwood> Yes.
[20:58] <DSpaceSlackBot> <tdonohue> Ok, we are nearing the top of the hour, so I think I'll close things up for today. I'd encourage everyone to help continuing to review PRs especially (outside of these meetings)
[20:59] <DSpaceSlackBot> <tdonohue> there seems to be a lot of smaller PRs coming in these days that could use extra code reviews and/or testers. I've been trying to keep up with them myself, but could use your help. I've also been trying to flag the things that look like "quick win" PRs (to encourage folks with little time to just look at them)
[20:59] <mhwood> Appreciated.
[21:00] <DSpaceSlackBot> <tdonohue> We'll leave it at that. Thanks all! Remember, the next DSpace 7 UI meeting is tomorrow at 16UTC (in Slack). Reminders will be going out via email in just a bit
[21:00] <mhwood> Must go. Thanks all!
[21:02] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:28] <DSpaceSlackBot> Action: tdonohue just realized I've been saying the DSpace 7 UI Meeting is tomorrow at 16UTC. That's wrong. It's at *15UTC*. The correct info going to dspace-devel shortly
[21:56] * tdonohue (~tdonohue@dspace/tdonohue) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.