Timestamps are in GMT/BST.
[6:40] -verne.freenode.net- *** Looking up your hostname...
[6:40] -verne.freenode.net- *** Checking Ident
[6:40] -verne.freenode.net- *** Found your hostname
[6:40] -verne.freenode.net- *** No Ident response
[6:40] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:40] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:40] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:00] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[13:21] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:30] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[15:03] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[15:04] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[15:06] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[17:08] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[17:59] * hpottinger (~hpottinge@mu-162038.dhcp.missouri.edu) has joined #duraspace
[19:49] * kohts (~kohts@109.252.50.1) has joined #duraspace
[20:01] <tdonohue> Hi all, welcome to this week's DSpace DevMtg. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-02-03
[20:01] <kompewter> [ DevMtg 2016-02-03 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-02-03
[20:02] <tdonohue> (A friendly ping to wake up Commiters: helix84, hpottinger, mhwood, peterdietz, terry-b)
[20:02] <hpottinger> I'm here
[20:02] <tdonohue> So, before we jump into 6.0 (the primary topic), I did want to remind folks about the DSpace UI Prototype Challenge status: https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge
[20:02] <kompewter> [ DSpace UI Prototype Challenge - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge
[20:03] <tdonohue> That wiki page includes links to (nearly) all the slidedecks describing prototypes, and (soon) will include all the video recordings of the talks/discussion (most are already there)
[20:03] <helix84> pong!
[20:04] <tdonohue> Starting next week (emails forthcoming), we will begin to ask EVERYONE (who is willing) to add feedback on prototypes to the Evaluation Form at https://docs.google.com/spreadsheets/d/1XWxEERh0UXCOo7LhocMMaqbY2u4b6oI11oWOjSp_aSQ/edit
[20:04] <kompewter> [ DSpace UI Prototype Evaluation Form - Google Sheets ] - https://docs.google.com/spreadsheets/d/1XWxEERh0UXCOo7LhocMMaqbY2u4b6oI11oWOjSp_aSQ/edit
[20:04] <terry-b> I have been impressed at the quality of the prototypes!
[20:05] <tdonohue> The Evaluation Form has one tab per prototype, and there's now a simple "Public Comments" table at the top of each page. We ask that everyone please take some time in the next week or so to add in your comments, as we *will* use these comments in the evaluation
[20:05] <tdonohue> I agree with terry-b, we've had a lot of great prototypes, which makes our decision even harder ;) But, that's also why we really need folks to enter your feedback
[20:06] <hpottinger> any chance you can ping us when all the video links are there?
[20:06] <tdonohue> When the video links are all there, I will be pinging the *entire community* on this (all major lists). Right now, you can get started early :)
[20:07] <tdonohue> We also will be scheduling some followup discussions/meetings (next week) for Committers and UI Working Group members to talk through opinions, etc. An email about that will be going out later today (after this mtg)
[20:08] <tdonohue> Any other immediate questions here? I'll be sending a timeline of next steps to Committers / UI working group members (later today), and get them sent publicly once all videos are available.
[20:09] <tdonohue> I'll also briefly mention that we had one more prototype presentation scheduled for tomorrow. That one has been canceled (the developer has withdrawn his prototype). Again, that will go out in an email later today
[20:10] <tdonohue> Sounds like no questions here..so, we can move along to 6.0 topics
[20:10] <helix84> which one has been withdrawn?
[20:11] * jcreel (~jcreel@jcreel.tamu.edu) has joined #duraspace
[20:11] <tdonohue> The recently "withdrawn" prototype is #5 : Java API + Jersey + Twirl (I'll be sending that out to Committers/UI Working group folks / other prototype creators later today)
[20:11] <helix84> thanks
[20:12] <tdonohue> Ok, moving along to 6.0 topics now.
[20:13] <tdonohue> Obviously, we need to get to 6.0 Feature Freeze ASAP, but we still need to finish getting in last features / major improvements and stabilize things (there's a few larger bugs we likely should squash)
[20:13] <tdonohue> First and foremost though, we have one outstanding feature: DSPR#1162
[20:13] <kompewter> [ https://github.com/DSpace/DSpace/pull/1162 ] - DS-2877 Import of ScienceDirect metadata including embargo and linking to or embedding of the final version by LetitiaMukherjee
[20:14] <tdonohue> It sounds like it's *still* buggy (I gather)?
[20:14] <helix84> yep
[20:14] <tdonohue> yep, looks like helix84 is doing good testing here (thanks!)
[20:15] <helix84> I'd love that one to go in, but it needs some more clean up from the submitter(s)
[20:15] <helix84> I hope they can get to it in the next few days
[20:15] <helix84> They've been very active in other PRs
[20:15] <tdonohue> Ok. So, I think we'll need to make a decision how much longer we wait (but they have been responsive/quick)
[20:16] <helix84> well we still have improvements go go through
[20:17] <tdonohue> yes, we do..which is where I was going to go next
[20:17] <tdonohue> https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A6.0+label%3Aimprovement
[20:17] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A6.0+label%3Aimprovement
[20:17] <helix84> 19 open (though some of them have fallen behind master and need small updates)
[20:17] <hpottinger> is KevinVdV the RC for 6?
[20:18] <tdonohue> we don't really have an RC. No one stepped forward (and I cannot honestly even claim that role in its entirety, with everything else going on in parallel), so we are working much more "ad hoc" as a Committers Group
[20:18] <tdonohue> regarding the improvements though, I did a quick check of them today to see which have merge conflicts & flagged them & added a comment
[20:19] <tdonohue> There's 6 in that group, which leaves us with the other 13
[20:20] <tdonohue> Shall we go through them today (from the top) for a quick status/update check, and see if we can find volunteers (as needed)?
[20:20] <mhwood> sure
[20:20] <hpottinger> good plan
[20:20] <helix84> then we also have a couple of refactoring/technical debt tasks: https://github.com/DSpace/DSpace/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+milestone%3A6.0+label%3A%22code+task%22
[20:20] <tdonohue> from the top then, DSPR#1253
[20:20] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+milestone%3A6.0+label%3A%22code+task%22
[20:20] <kompewter> [ https://github.com/DSpace/DSpace/pull/1253 ] - DS-3009 Allow classpath definition of command line tools by rradillen
[20:21] <tdonohue> So this one is newer, no comments/testers yet on the code itself or the idea
[20:22] <tdonohue> To me, this seems like a nice idea. Would need docs though, and I admit to not having tested it
[20:22] <mhwood> Interesting, not urgent.
[20:24] <tdonohue> yep, agreed. It would be nice to be able to "inject" these commands via Spring, instead of having the flat XML....so, that's the big benefit here
[20:24] <tdonohue> If anyone is interested, please assign yourself to the PR / test it.
[20:24] <helix84> I claimed the next one - StartTLS in LDAP
[20:24] <tdonohue> moving along, DSPR#1248
[20:24] <kompewter> [ https://github.com/DSpace/DSpace/pull/1248 ] - [DS-1518] Support of StartTLS in LDAPAuthentication. by christian-scheible
[20:24] <tdonohue> thanks helix84
[20:25] <tdonohue> One note helix84, just scanning the code...that will need fixes to the new config added to authentication-ldap...it'll need prefixing with "authentication-ldap.". I'll add a comment
[20:26] <helix84> Got it. I've already been playing with it.
[20:26] <tdonohue> moving along, next up DSPR#1226 (terry-b you around?)
[20:27] <kompewter> [ https://github.com/DSpace/DSpace/pull/1226 ] - [DS-2898] Add support for all authentication methods in the rest api by KevinVdV
[20:27] <terry-b> I am here
[20:27] <terry-b> I need to resolve the other issues I have encountered with Shibb in XMLUI before I can resume testing on this.
[20:27] <tdonohue> any updates to share on this? I know you and KevinVdV have been working hard at getting this functional for all AuthN (Shib, esp)
[20:27] <terry-b> Kevin suggested some additional diagnostics to add to this, but I feel like I have been going in circles on this issue
[20:28] <tdonohue> Oh, that's right. Thanks, terry-b. I'll be glad to help look over your Shibb fixes for master (as at least some of them are related to Commons Config)
[20:28] <tdonohue> Is anyone else using Shib and could help test 1226 (once the other Shib issues are resolved on master)?
[20:29] <jcreel> Shibboleth is in use at Texas A&M and would be very useful for us in the REST API.
[20:29] <hpottinger> I'm using Shib, however I'm not currently running master on any machine that uses Shib
[20:30] <tdonohue> jcreel: perhaps you all could help test out 1226 then, once we get the Shib configs fixed on master? I'll try to ping you via GitHub once we are ready again
[20:30] <hpottinger> I can pitch in with help testing, though, and really *should* stand up a test instance of master.
[20:31] <tdonohue> hpottinger: your help would also be appreciated. It sounds like we may just need more help testing to see if it's *one Shib* or *all Shibs* that are affected. Maybe it'd help us narrow down what may be wrong
[20:32] <tdonohue> ok, I'm going to move along for now then. We've got a few possible helpers/testers we can ping once basic Shib auth is fixed up again (hopefully very soon)
[20:32] <tdonohue> next up, DSPR#1214
[20:32] <kompewter> [ https://github.com/DSpace/DSpace/pull/1214 ] - [DS-1494] Facilitate use of jndi.properties instead of DSpace configuration for LDAP credentials by mwoodiupui
[20:33] <tdonohue> helix84: any interest in this one, since you claimed the other LDAP one?
[20:33] <mhwood> Just needs another +1. The original poster hasn't been heard from in a while.
[20:33] <helix84> tdonohue: I haven't looked at that one, but sure, I'll take a look
[20:33] <mhwood> Thanks!
[20:34] <tdonohue> Just glancing at the code, it looks like we *might* end up with some (possibly minor) code conflicts betweeen 1214 and 1248 anyhow...so it'd be good to test them together somewhat
[20:34] <tdonohue> thanks helix84!
[20:34] <helix84> mhwood: meanwhile, I posted some feedback on your DSPR/1257
[20:35] <tdonohue> moving along, DSPR#1211 (terry-b should this be closed in favor of 1226 above)?
[20:35] <kompewter> [ https://github.com/DSpace/DSpace/pull/1211 ] - Process headers to allow shibb and ip authentication by terrywbrady
[20:35] <mhwood> Thanks for feedback as well.
[20:36] <terry-b> We can close it for now. If 1226 does not work, we can recreate this
[20:36] <tdonohue> Ok. yea, closing it won't *delete* anything anyhow, and you can always reopen
[20:36] <tdonohue> I'll close it then
[20:37] * tdonohue is skipping 1138, as it has a merge conflict
[20:37] <tdonohue> next up, DSPR#1129
[20:37] <kompewter> [ https://github.com/DSpace/DSpace/pull/1129 ] - Fix: Bitstream's retrieval's response without filename by BrunoNZ
[20:37] <tdonohue> This seems like a *very tiny* change
[20:38] <tdonohue> (to REST API)
[20:38] <mhwood> Looks reasonable.
[20:38] <tdonohue> It seems good to me. Anyone want to give it a quick run through? I'll add a +1 for the code itself
[20:39] <helix84> I'll probably get to it tomorrow
[20:39] <tdonohue> thanks helix84. I added my +1 for the code
[20:40] * tdonohue is skipping 1118, merge conflict
[20:40] <tdonohue> DSPR#1044
[20:40] <kompewter> [ https://github.com/DSpace/DSpace/pull/1044 ] - [DS-1837] Create a separate Maven artifact for the MultiRemoteDSpaceRepositoryHandlePlugin by mwoodiupui
[20:41] <mhwood> This one now just removes code that has been moved to another project.
[20:41] <tdonohue> Is this just a removal of the code now? (since it's now over in a separate GitHub project?)
[20:42] <tdonohue> mhwood: in that case, I'd say we just merge this. But, we need some sort of *reminder* to release that separate project *prior to 6.0*. So, the ticket may need to stay open with a comment to release it prior to 6.0?
[20:42] <mhwood> Looks like it kept some reindenting and rearrangement I did in modules/pom.xml.
[20:43] <tdonohue> that's fine. the fixing of spacing is no big deal. I noticed that
[20:43] <tdonohue> I say merge it. Add a comment to ticket to remind us to release it via Maven
[20:43] <mhwood> I need to figure out how to release it. It isn't really a dependency of anything.
[20:43] <helix84> I wanted to run one more improvement by you that I think must be in 6.0: DS-2619
[20:43] <kompewter> [ https://jira.duraspace.org/browse/DS-2619 ] - [DS-2619] REST needs a versioned API - DuraSpace JIRA
[20:44] <tdonohue> mhwood: It'd be release the same way we release the lang packs
[20:44] <mhwood> OK, I'll look at those.
[20:44] <tdonohue> (even if it isn't a dependency, it's the same process)
[20:44] <helix84> I prepared at least a poor-man's edition of versioning - just return DSpace version via REST
[20:44] <helix84> https://github.com/helix84/DSpace/commit/0da39363d14502a30626a89f2be00ecef83f71f2
[20:44] <kompewter> [ DS-2619 add DSpace version to /rest/status · helix84/DSpace@0da3936 · GitHub ] - https://github.com/helix84/DSpace/commit/0da39363d14502a30626a89f2be00ecef83f71f2
[20:44] <mhwood> Shall I just merge this with a note?
[20:44] <helix84> Is this approach fine by y'all?
[20:45] <tdonohue> mhwood: +1 to merge
[20:45] <tdonohue> helix84: good question
[20:46] <tdonohue> helix84: honestly, since the REST API should only change in major releases, that approach seems reasonable. We could just version it based on the major version of DSpace
[20:47] <tdonohue> peterdietz: you around? I know REST API versioning is a topic of interest to you
[20:47] <peterdietz> hey
[20:48] <terry-b> I could imaging adding new endpoints to a minor release but not restructuring major calls
[20:48] <tdonohue> helix84: minor feedback on your code is to try to clean up your repetition of logic...have a "getDSpaceMajorVersion()" method, instead of re-parsing it out all over ;)
[20:48] <peterdietz> Thats not quite the direction of versioning i was planning, but, I suppose it works.
[20:48] <helix84> tdonohue: sure, that actually had a reason that is now not valid anymore :)
[20:48] <tdonohue> terry-b: minor releases are supposed to just be for bug fixes though, right
[20:49] <peterdietz> ...and I haven't suggested a better alternative
[20:49] <helix84> peterdietz: what have you been planning?
[20:49] <helix84> tdonohue++
[20:50] <peterdietz> I don't know the best way to manage API's, but I was thinking along the lines of a /rest/v1, /rest/v2
[20:50] <terry-b> tdonohue, I did not realize that was the intent of minor releases
[20:51] <tdonohue> terry-b: yep, we only allow bug fixes in minor releases these days. See our "Release Numbering Scheme": https://wiki.duraspace.org/display/DSPACE/Releases#Releases-ReleaseNumberingScheme
[20:51] <kompewter> [ Releases - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Releases#Releases-ReleaseNumberingScheme
[20:51] <hpottinger> what's the "best practice" for versioning REST APIs? What do developers expect us to do?
[20:51] <terry-b> thanks for the clarification
[20:51] <helix84> peterdietz: well, I tend to agree but I don't think there's a person who would maintain the translation layers in the future
[20:52] <tdonohue> From my understanding (correct me, peterdietz if I'm wrong)...there two ways of "versioning" REST APIs. the /rest/v1 /rest/v2 way...and the way helix84 did it. There's no "clear winner"
[20:52] <mhwood> Maybe just one version back? Give folks a chance to upgrade without keeping in lockstep with DSpace releases?
[20:53] <helix84> I'd be all for peter's suggestion, if we had the code to go to 6.0.
[20:53] <tdonohue> For *our* purposes, it might be easier on *us* to go with helix84's solution. We wouldn't have to maintain *two* (or more) versions of a REST API in parallel. For example, do we really want a v1 and v2 REST API *both* in 6.0?
[20:53] <mhwood> Granted, DSpace is developed in full view, so folks can prepare in *advance* of our releases.
[20:53] <helix84> the reason why I want at least something to go to 6.0 is that the API user will have a way of telling apart the versions (which is now missing)
[20:54] <tdonohue> I think as long as we include REST API changes in our Upgrade/Release Notes, it makes sense to version the REST API in major releases. That way we can tell folks (before they upgrade) what to watch out for
[20:54] <hpottinger> I like the simple approach helix84 is taking, in that case.
[20:54] <tdonohue> So, I think I'm convincing myself that I like helix84's solution
[20:54] <mhwood> I have no strong feelings about either way; I'm just generating ideas. And simple is good.
[20:55] <tdonohue> Are there any strong objections to helix84's solution? Anyone else out there highly dependent on REST and have opinions here (jcreel? or others)?
[20:56] <hpottinger> so, devs can query the version endpoint, and if they get an error they know they're dealing with the 5x version of our REST-API
[20:56] <tdonohue> hpottinger: yes...and in the future, they'll get back what version of the API they *are* working with
[20:56] <hpottinger> sounds good to me
[20:56] <helix84> hpottinger: v5 or v4, neither has that attribute in the /status response
[20:57] <hpottinger> oh, yes... hrmm... no answer would mean <6
[20:57] <tdonohue> true. we could "backport" it potentially, if folks really wanted it. But, that'd be another 5.x and/or 4.x release.
[20:57] <hpottinger> but you could deduce it by trying to get a token
[20:58] <peterdietz> So, a client wanting to use /rest/hierarchy, could either do an annoying dance, and query if /rest/hierarchy is available, or have some internal book-keeping that knows that /rest/hierarchy isn't available until major version 6
[20:58] <helix84> hpottinger: that's the reason why I wanted to get it to 6
[20:59] <tdonohue> We've gone on a big tangent here (and nearly out of time now). Should we just vote on this?
[20:59] <hpottinger> I'd feel bad, except from where I'm sitting, it all looks like an annoying dance :-)
[20:59] <tdonohue> I'm +1 on helix84's solution. Just needs an official PR / ticket
[20:59] <peterdietz> so.. this sounds reasonable.
[20:59] <tdonohue> other votes here?
[20:59] <hpottinger> same, +1 helix84's approach
[20:59] <mhwood> Since we have nothing else coming along: +1;
[21:00] <terry-b> +1 here as well. Sounds appropriate for where we are
[21:00] <peterdietz> +84 helix1
[21:00] <helix84> I'll have the PR ready tomorrow
[21:00] <tdonohue> thanks helix84: sounds like you have the go ahead :)
[21:01] <helix84> since I already seem to have the stage, I'd like to ask is anyone opposed to DSPR#1264?
[21:01] <tdonohue> So, we are now at the top of the hour. We didn't make it through all the improvement PRs, but I think we'll have to stop there (I have to jump off to a few other tasks)
[21:01] <kompewter> [ https://github.com/DSpace/DSpace/pull/1264 ] - DS-3016 upgrade dependencies before 6.0 release (2) by helix84
[21:02] <mhwood> I'm never opposed to fresher dependencies that don't break anything.
[21:02] <hpottinger> +1
[21:02] <tdonohue> no objections, though we don't have full test coverage... so we'll have to keep an eye out during testathon
[21:02] <tdonohue> overall it looks good though
[21:02] <helix84> tdonohue: that's the intention :)
[21:02] <hpottinger> 'tis what testathon is for
[21:03] <helix84> with pbecker it's now +2, my hand has been itching to merge this
[21:04] <tdonohue> So, regarding Testathon & the release schedule... We obviously are "way off" schedule at this point. I am going to notify the community that the 6.0 release is delayed (likely this week sometime). I don't know we can narrow down dates *yet*
[21:04] <peterdietz> i don't have reservations on the dependency bump. At least regarding AWS/S3
[21:04] <helix84> If anyone wants to take a look at the few upgrades that cause build failures, I separated them out into easy subtasks of DS-3016
[21:04] <kompewter> [ https://jira.duraspace.org/browse/DS-3016 ] - [DS-3016] upgrade dependencies before 6.0 release - DuraSpace JIRA
[21:04] <mhwood> Thank you for that.
[21:04] <helix84> (those are excluded from this PR)
[21:04] <tdonohue> But, any help that *anyone* can provide to test 6.0 PRs would be VERY welcome...we need to get back on schedule soon, and not delay indefinitely
[21:05] <tdonohue> s/on schedule/on a schedule/
[21:05] <kompewter> tdonohue meant to say: But, any help that *anyone* can provide to test 6.0 PRs would be VERY welcome...we need to get back on a schedule soon, and not delay indefinitely
[21:06] <tdonohue> My current anticipation is that 6.0 isn't likely before mid-March. We just aren't near enough to an RC1....even though we *are* doing great work stabilizing things, etc.
[21:06] <tdonohue> (and even mid-March would be early, likely)
[21:06] <hpottinger> (sounds like post spring break, then)
[21:07] <helix84> Highly relevant - list of blockers: https://jira.duraspace.org/browse/DS-3024?jql=project%20%3D%20DS%20AND%20status%20in%20(Received%2C%20%22More%20Details%20Needed%22%2C%20%22Volunteer%20Needed%22%2C%20%22Code%20Review%20Needed%22%2C%20Accepted)%20AND%20priority%20%3D%20Blocker
[21:07] <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
[21:07] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3024?jql=project%20%3D%20DS%20AND%20status%20in%20(Received%2C%20%22More%20Details%20Needed%22%2C%20%22Volunteer%20Needed%22%2C%20%22Code%20Review%20Needed%22%2C%20Accepted)%20AND%20priority%20%3D%20Blocker
[21:07] <mhwood> I've been testing SQL for 3024 as we "speak".
[21:07] <tdonohue> But, honestly, thanks to everyone for your hard work! This is a massive release (in terms of API refactoring) which has shaken loose a bunch of "spaghetti-ish" code...and I think we're just finding ourselves having to trudge through that and fix things that have been "not so great" for some time
[21:07] <helix84> mhwood: much appreciated
[21:08] <tdonohue> yes, thanks helix84: we have a lot of blockers still to fix up
[21:09] <helix84> tdonohue: I'll add it to this meeting's agenda to be copied to the next one :)
[21:09] <tdonohue> thanks for that. You might also want to narrow those blockers by *6.0*...not sure they currently are
[21:09] <tdonohue> although, nevermind..they look to be 6.0 anyways :)
[21:10] <mhwood> I just want to mention an agenda item that we didn't get to, so we can be thinking about it: there is still some uncertainty about our direction on PDF rendering. Lots of good work has been contributed but we are still wavering.
[21:10] <tdonohue> Ok, with that, I'm going to close up today's meeting. If anyone has time, please help out in testing any PRs flagged for 6.0
[21:11] * kohts (~kohts@109.252.50.1) Quit (Remote host closed the connection)
[21:11] <hpottinger> PDF rendering?
[21:11] <helix84> hpottinger: for thumbs or for cover pages?
[21:11] <tdonohue> mhwood: you mean DS-2159, right. It just needs a volunteer
[21:11] <kompewter> [ https://jira.duraspace.org/browse/DS-2159 ] - [DS-2159] Deprecate XPDF in DSpace 5, remove in DSpace 6 - DuraSpace JIRA
[21:11] * kohts (~kohts@109.252.50.1) has joined #duraspace
[21:11] <helix84> yeah I wanted to talk about that
[21:11] <mhwood> There's unfinished discussion.
[21:11] <helix84> PDFbox 2.0.0 is now @ RC3
[21:12] <helix84> we might want to bump that dependency
[21:12] <tdonohue> Feel free to continue discussion here
[21:12] <helix84> non-ASCII support for cover pages depends on that
[21:12] <mhwood> Maybe the way forward is to go ahead and finish off 2159, and then see what we want to do next.
[21:12] <helix84> if there are any bugs in 2.0.0, we may bump it in 6.x
[21:13] <helix84> mhwood++
[21:13] <tdonohue> I think we have a few different issues here. 2159 should be done, as XPDF is no longer maintained. PDFBox and ImageMagick are being used for (slightly) different reasons right now, so we may still need them in parallel
[21:13] <hpottinger> needs volunteer
[21:13] <mhwood> I think it's clear that we don't need XPDF *and* ImageMagick call-outs?
[21:14] <mhwood> So, removing XPDF support is needed regardless of any other developments.
[21:15] <tdonohue> XPDF was the "alternative" to PDFBox actually (when PDFBox was a nearly dying project). Now, PDFBox has been picked up by Apache, and is rebuilding itself & thriving again, while XPDF is dying
[21:15] <hpottinger> I just moved 2159 to "needs volunteer" hope you all don't mind
[21:16] <tdonohue> Since then, we've also added ImageMagick support for enhanced thumbnails (for both images & PDF). It's NOT just for PDF
[21:16] <mhwood> Good point.
[21:17] <tdonohue> And, since then, PDFBox also has become used for the PDF "coverpage" code. So, PDFBox and ImageMagick are doing *different* things. They are both needed. It's only XPDF that is not
[21:18] <helix84> correct me if I'm wrong, pdfbox is now used for cover pages, pdf thumbanils and pdf text extraction
[21:18] <tdonohue> So, in the end, 2159 just needs a volunteer here
[21:18] <tdonohue> helix84: by default yes. But, if you want, you can use ImageMagick (if you install it separately on your OS) to have enhanced PDF thumbnails (to replace just that one part of PDFBox)
[21:19] <tdonohue> PDFBox is our "bundled" default for all that. ImageMagick is an option extension you can use if you want to install it separately
[21:19] <tdonohue> So, I don't think there's anything we can do right now other than remove XPDF
[21:20] <helix84> removing XPDF seems to have no objections
[21:21] <helix84> what do you think about upgrading PDFbox to 2.0.0, perhaps even 2.0.0rc3?
[21:21] <tdonohue> nope. I think we should remove it ASAP, once we get someone to rip it out for us (shouldn't be too hard, I'd think...mostly just delete that MediaFilter class and its configs)
[21:21] <tdonohue> PDFBox to 2.0.0 sounds fine, as long as we can get our code upgraded too (for cover pages, pdf text extraction, etc)
[21:22] <helix84> From what I've read, 2.0.0 shouldn't have any breaking changes for us
[21:22] <tdonohue> I'm hesitant though to upgrade to an RC3 though (as we could be dealing with instability there)... I'd rather it be 2.0.0
[21:22] * kohts (~kohts@109.252.50.1) Quit (Ping timeout: 250 seconds)
[21:22] <mhwood> OK, I volunteer for 2959. I can rip out code as well as any other monkey. :-)
[21:22] <helix84> well, they're 3 RSs ahead of us, so I think they'll get there before us
[21:22] <helix84> I'll prepare the change and test it
[21:23] <tdonohue> mhwood: 2159 you mean? Feel free to claim it. Hopefully it's just removing the Media Filter & its configs & docs. Thanks!
[21:23] <mhwood> Woops, yes.
[21:24] <tdonohue> thanks helix84: yea, as long as they plan to release 2.0.0 soonish (hopefully they beat us to release)
[21:24] <tdonohue> Ok, I gotta step away now. Thanks all!
[21:24] * hpottinger (~hpottinge@mu-162038.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[21:25] <helix84> tdonohue: they've had steady progress on that
[21:25] <mhwood> I linked today's log to DS-1865 where the recent discussion has been.
[21:25] <kompewter> [ https://jira.duraspace.org/browse/DS-1865 ] - [DS-1865] XPDF requires manually installing a JAR which is NOT available in Maven Central - DuraSpace JIRA
[21:25] <mhwood> That one should also link to any new issue about upgrading PDFBox.
[21:27] <helix84> mhwood: we may already have one due to cover pages. I'll look into that.
[21:28] <helix84> let's switch to #dspace
[22:01] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:50] * 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.