Timestamps are in GMT/BST.
[6:40] -asimov.freenode.net- *** Looking up your hostname...
[6:40] -asimov.freenode.net- *** Checking Ident
[6:40] -asimov.freenode.net- *** Found your hostname
[6:40] -asimov.freenode.net- *** No Ident response
[6:41] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:41] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:41] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[13:34] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:55] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[19:59] * KevinVdV (~KevinVdV@d54C5104D.access.telenet.be) has joined #duraspace
[20:00] <mhwood> It's 2000UTC. Is anybody there?
[20:01] * Letitia_Mukherje (9124eb03@gateway/web/freenode/ip.145.36.235.3) has joined #duraspace
[20:01] <peterdietz> hi all
[20:01] <KevinVdV> Present
[20:01] <tdonohue> hello all, it is time for our weekly DSpace Developers Mtg. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-11-25
[20:01] <kompewter> [ DevMtg 2015-11-25 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-11-25
[20:02] <KevinVdV> Although I might fall out now & then if a certain member of the family needs my attention
[20:02] <peterdietz> Congratulations again!
[20:02] <KevinVdV> Thx again
[20:02] <tdonohue> Looks like we have a small quorum today, which is good. Yes, congrats again, KevinVdV, and thanks for all the master bug fixes in your "free" time :)
[20:03] <tdonohue> So, the agenda today is rather light. It's still primarily reviewing PRs for 6.0 possible inclusion
[20:04] <tdonohue> I will mention that I've not heard much feedback regarding the Commons Configuration PR vote, DSPR#1104 (just a few +1s over on dspace-devel). So, I'm assuming the vote has generally "passed". But, it still could use more testers / folks to try it out before we jump in and merge it
[20:05] <kompewter> [ https://github.com/DSpace/DSpace/pull/1104 ] - DS-2654: Enhanced Configurations via Apache Commons Configuration by tdonohue
[20:05] <tdonohue> The outstanding question with that PR is *when* to merge it (assuming no last minute objections pop up)
[20:06] <KevinVdV> I’ll try and take a look as well before next week (can’t promise anything though)
[20:06] <tdonohue> And I just noticed that PR has conflicts from recent mergers (likely the many small bug fixes). So, I'll need to rebase it...but if you just check it out directly, it does *work*
[20:06] <peterdietz> tdonohue: I've been toying with config commons, and being pleasantly surprised when noticing that xmlui themepath was default off, and changing url in ?themepath=redtheme/ didn't change the site, but was able to update local.cfg to themepath.enabled=true, and then reload browser, and the change was immediate
[20:08] <peterdietz> I then started to muck with REST API to add an endpoint to get/set configs, and was trying to figure out with framework to start a fresh rest client from, for some administrative app. But, the point is that commons so far is good.
[20:08] <tdonohue> peterdietz: nice :) Admittedly, I'm not entirely sure which configs *are* reloadable (most actually are not as they end up cached somewhere)...which is why I've been playing down that aspect of this PR
[20:09] <tdonohue> So, are there any other 6.0 PRs/features we'd like to specifically highlight or discuss today? Or should we jump into the list of PRs and review some?
[20:09] <peterdietz> But yes. One might NEVER end up touching dspace.cfg again
[20:10] <tdonohue> peterdietz: that is my hope with that PR. You never need to directly change any of the default *.cfg files again ;)
[20:11] <tdonohue> OK, any other topics folks want to specifically bring up? (Last chance before we dive into some PR reviews)
[20:12] <KevinVdV> Don’t know if anybody already noticed my work on: https://jira.duraspace.org/browse/DS-2222
[20:12] <kompewter> [ [DS-2222] Fix DSpace code via FindBugs - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-2222
[20:12] <kompewter> [ https://jira.duraspace.org/browse/DS-2222 ] - [DS-2222] Fix DSpace code via FindBugs - DuraSpace JIRA
[20:13] <KevinVdV> I think if we can get the scary and/or scariest bugs out of there we can enable findbugs by default on a certain level in travis
[20:13] <KevinVdV> Does anybody have anything against this, or have some comments ?
[20:13] <tdonohue> KevinVdV: yes, I've been seeing your many many PRs come across. I've yet to be able to put much time into testing/reviewing them myself yet (as I'm trying to quickly put in a UI Prototype for the upcoming UI Prototype Challenge deadline)
[20:13] <mhwood> Well, four of them were merged and closed....
[20:14] <tdonohue> KevinVdV: I'd personally like to enable findbugs in Travis (once things are cleaned up enough)
[20:14] <mhwood> I'm +1 on any for which I have a clear opinion.
[20:14] <KevinVdV> Not the highest prior ofc, but would be nice to have it in for DSpace 6.1
[20:15] <tdonohue> I would encourage folks to *merge* the obvious bug fixes immediately. There's really no need to wait around for more votes, if the fix is very obvious, etc
[20:16] <KevinVdV> Don’t want to hold up the meeting just wanted people to know & hopefully get some eyes on it ;)
[20:16] <tdonohue> e.g. DSPR#1186 is one that falls under the "just merge it"
[20:16] <kompewter> [ https://github.com/DSpace/DSpace/pull/1186 ] - [DS-2912] Sub daily script is broken by KevinVdV
[20:17] <tdonohue> No problem. We'll jump back into some PR reviews now.
[20:18] <tdonohue> Last week, we reviewed a lot of the more recent feature PRs....we got all the way down to 1159
[20:18] <tdonohue> Here's the list of those flagged as "feature" https://github.com/DSpace/DSpace/pulls?utf8=%E2%9C%93&q=is%3Aopen+milestone%3A6.0+label%3Afeature
[20:18] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?utf8=%E2%9C%93&q=is%3Aopen+milestone%3A6.0+label%3Afeature
[20:19] <tdonohue> So, today, I'd propose starting us off at some of the older PRs (earlier than 1159)
[20:19] <mhwood> Which is +1 now.
[20:19] <peterdietz> assetstore looks +1, needs some services flavored refactoring
[20:20] <tdonohue> peterdietz: yes, 1159 just needs some light refactoring I think. It's looking good overall
[20:20] <mhwood> I think the 79 PR has accumulated a lot of interesting ideas which probably should be separate tickets.
[20:21] <tdonohue> mhwood: are you saying that DSPR#1159 needs multiple tickets to describe *each* of the features in there?
[20:21] <kompewter> [ https://github.com/DSpace/DSpace/pull/1159 ] - DS-79 Assetstore to support different implementations, including S3 by peterdietz
[20:21] <mhwood> The original intent is fine.
[20:21] <peterdietz> Yeah, Mark Diggory was suggesting to rethink how to shuffle the bits. Resumable, look for tricks in Guava
[20:22] <mhwood> Toward the bottom we've all been adding ideas that sort of wander off the topic.
[20:22] <tdonohue> Ok. I'm not sure if there's anything else specific to discuss here with 1159? If not, we can move along
[20:23] <mhwood> I think 1159 is probably good to merge with or without renaming things but shouldn't get bogged down with reworking the configuration, adding Guava all over, etc. (Good ideas for later.)
[20:23] <peterdietz> I need to spend some time refactoring. Yes, can move on
[20:23] <mhwood> Yes, move on.
[20:24] <tdonohue> next on the list is actually #1104 (Commons Configuration), which has been under discussion already. Just needs testers
[20:24] <tdonohue> I don't think there's anything else to immediately touch upon with 1104..so, I'll move along to the next one
[20:24] <Letitia_Mukherje> Hello, I have sent in a contribution on behalf of Elsevier; DS-2877 Import of ScienceDirect metadata including embargo and linking to or embedding of the final version #1162 . Are there any questions on it?
[20:24] <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:25] <tdonohue> Letitia_Mukherje: Oh, thanks for letting us know you were here. We can jump to that one now. Looks like it's DSPR#1162
[20:25] <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:25] <Letitia_Mukherje> Yes, apologies, I was on the #dspace chat, first time i join..
[20:27] <peterdietz> It looks like helix84 did some testing of this
[20:27] <tdonohue> Letitia_Mukherje: is there any more documentation on how to test this feature? It looks like helix84 already tried (based on comments in 2877) and hit errors immediately
[20:28] <tdonohue> Usually when that sort of issue occurs, we wait for resolution of the bugs (or documented workarounds) before we can perform additional testing
[20:28] <Letitia_Mukherje> Yes, Atmire is working on the documentation, they first wanted to make sure the contribution was in before the deadline
[20:29] <peterdietz> FileAccess looks new to me
[20:30] <peterdietz> https://github.com/LetitiaMukherjee/DSpace/blob/DS-2877/dspace-api/src/main/java/org/dspace/importer/external/README.md
[20:30] <kompewter> [ DSpace/README.md at DS-2877 · LetitiaMukherjee/DSpace · GitHub ] - https://github.com/LetitiaMukherjee/DSpace/blob/DS-2877/dspace-api/src/main/java/org/dspace/importer/external/README.md
[20:30] <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:30] <Letitia_Mukherje> The goal of the plugins is to help IRs gather metadata, abstracts and DOI links from ScienceDirect and link entitled users to the final version on SD
[20:31] <Letitia_Mukherje> Both live import and batch import use cases are possible
[20:33] <tdonohue> So, the concept sounds fine to me. But, it sounds like it has bugs in the testing that need resolution before we'd be able to give it a more thorough test & review?
[20:33] <Letitia_Mukherje> Ok, I will pass that message onto Atmire, who is doing the development, many thanks
[20:34] <tdonohue> No problem. At this time, I think we're mostly just waiting on a testable version. Once the bugs are worked out, we can do more thorough tests, etc.
[20:35] <mhwood> I do think that this sounds like something which many sites will find desirable.
[20:35] <tdonohue> So, before moving back to our list, I realize we haven't yet discussed DS-2876 (the framework the previous PR is based on) in a meeting. It's had several comments in the ticket, and is a separate DSPR#1160
[20:36] <kompewter> [ https://github.com/DSpace/DSpace/pull/1160 ] - DS-2876 Framework for importing external metadata by jonas-atmire
[20:36] <kompewter> [ https://jira.duraspace.org/browse/DS-2876 ] - [DS-2876] Framework to better support metadata import from external sources - DuraSpace JIRA
[20:36] <KevinVdV> For the actual framework I think it would be best to address my colleague Roeland Dillen (Who should be present for the meeting next week)
[20:36] <KevinVdV> This meeting was a bit late for him today
[20:37] <Letitia_Mukherje> <mhwood> I am liaising with 120 institutions worldwide who are interested
[20:37] <peterdietz> Overall, I'm guessing this sounds like a good feature to add. I seeing on SD export to Mendeley, RefWorks, RIS, BibTex, Text. I'm wondering if there is a best format for data transfer between every repository?
[20:37] <tdonohue> KevinVdV: OK, that's good to know. I mostly wanted to make others aware of the discussions already on the ticket...namely around having two competing frameworks for the two competing UIs :) But, as noted in the ticket, it may not be a big deal for now, as long as we standardize on *one* in Dspace 7
[20:39] <tdonohue> (I'm referring to the discussions within the 2876 ticket itself...in case others haven't seen it, it'd be worth reviewing prior to next week's meeting)
[20:39] <mhwood> It appears to me that the framework, with the exception of a couple of dependencies added to a POM, is 100% new code.
[20:39] <tdonohue> mhwood: it is
[20:39] <peterdietz> I've never actually used BTE. So I don't have much insight into competing between the new metadata import service, and BTE. But I would be in favor of things to be feature complete, easy to use, documented, ...
[20:39] <mhwood> So it probably can't hurt. :-)
[20:41] <tdonohue> The end goal is just to get to a *single UI* (in DSpace 7). If we have two competing import frameworks (BTE & this new one) we'll have to choose *one*. So, while we *can* have duplicative frameworks in DSpace 6, one is going to be removed in DSpace 7.
[20:42] <tdonohue> I just wanted to make that 100% clear. It's not that I'm against the duplicity in DSpace 6. It's just that we need to choose one for the long term
[20:42] <tdonohue> In any case, we can talk through this more next week, when Roeland is around. Just wanted to get those thoughts out there
[20:42] <peterdietz> 2 frameworks, many many formats. For DSpace7+, it means 1 framework, many many supported formats
[20:43] <tdonohue> Back to our list of feature PRs
[20:44] <tdonohue> next up for review is DSPR#1086
[20:44] <kompewter> [ https://github.com/DSpace/DSpace/pull/1086 ] - DS-2583: Quality Control Reporting via REST API (v4) by terrywbrady
[20:45] <tdonohue> There's been a ton of discussion in the PR itself on this one. I know terrybrady is excited to get this one into the codebase & could use extra testers/reviewers here. Any immediate thoughts or volunteers on this?
[20:46] <peterdietz> I've given the REST QC a run. I suggested to move the reports from DSpace-Labs, to /rest/static/reports
[20:47] <tdonohue> peterdietz: yes, it looks like terry merged your suggestion of putting the reports into the codebase itself
[20:47] * Letitia_Mukherje (9124eb03@gateway/web/freenode/ip.145.36.235.3) Quit (Ping timeout: 246 seconds)
[20:48] <tdonohue> Does anyone have thoughts on this as a feature? Good/bad? It seems like something that could be of broad use, assuming you are OK with building your reports via REST.
[20:49] <tdonohue> (And that'd be much much better than manually building some local reports via SQL or similar)
[20:50] <peterdietz> Also, I think we're running into needing to figure out multi-webapp SSO. https://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Single_Sign_On
[20:50] <kompewter> [ Apache Tomcat 7 Configuration Reference (7.0.65) - The Host Container ] - https://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Single_Sign_On
[20:50] <peterdietz> Configs for a few of Terry's PR's include a disabled-by-default auth bypass
[20:51] <mhwood> Woops, still?
[20:51] <peterdietz> https://github.com/DSpace/DSpace/pull/1173/files#diff-a9f8bb21850852f7ed98e33220c0876cR10
[20:51] <kompewter> [ DS-2894:REST Call to return Optimized Hierarchy by terrywbrady · Pull Request #1173 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1173/files#diff-a9f8bb21850852f7ed98e33220c0876cR10
[20:52] <mhwood> I don't see how the Tomcat doc. applies to DSpace, since we're not using container-managed authNZ
[20:52] <tdonohue> that's a different PR though, right? Or is this same thing also in 1086?
[20:53] <peterdietz> Tim, your right, I think I hopped over to the hierarchy one.
[20:54] <tdonohue> Oh, wait, it *is* also in 1086: https://github.com/DSpace/DSpace/pull/1086/files#diff-a9f8bb21850852f7ed98e33220c0876cR34
[20:54] <kompewter> [ DS-2583: Quality Control Reporting via REST API (v4) by terrywbrady · Pull Request #1086 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1086/files#diff-a9f8bb21850852f7ed98e33220c0876cR34
[20:54] <peterdietz> But, back to the point. Are pre-built report tools helpful. I would say yes. The ones specifically included with the QC tools, I don't know if I've been asked to produce ones like that
[20:55] <peterdietz> But I regularly produce reports on amount of disk storage for contents for each comm/coll in the hierarchy
[20:55] <peterdietz> For that, we make SQL query to each instance DB
[20:57] <tdonohue> peterdietz: so would this help you with those reports?
[20:57] * tdonohue added a comment to 1086 regarding the disabled authN option
[20:58] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[20:59] <peterdietz> close. Maybe I can add a storage size_bytes tally
[21:01] <peterdietz> I don't have much to add to this topic. Overall +1.
[21:01] <mhwood> I've been wanting to rework my old content-statistics servlet into REST.
[21:01] <peterdietz> This is the perfect time to inject that
[21:02] <tdonohue> I guess I'm mostly wanting to hear feedback from others who want to see a framework like this in REST, to do more reports on. It *sounds* like mhwood & peterdietz both want that, even if these are all the exact reports you need. So, the question is, does this framework make that easier to achieve..
[21:03] <tdonohue> my view here is this *looks* useful. But, I admit, i don't tend to run such reports myself...I'd like to hear from someone who *does* want to see reports via REST :)
[21:03] <mhwood> Well, I don't need *reports*; I need *numbers* that can go into a dashboard for all of our various and sundry services.
[21:03] <mhwood> I'm still trying to figure out these reports. But I may know someone here who would be more interested than I.
[21:04] <mhwood> (I also sample our numbers periodically into a database so that we can chart content growth over time. No charts yet, alas.)
[21:05] <tdonohue> Ok, so it sounds like there's no objections here (which is good). It seems like to me, the initial "strength" of these default reports is in finding metadata issues...namely these settings: https://github.com/DSpace/DSpace/pull/1086/files#diff-a9f8bb21850852f7ed98e33220c0876cR113
[21:05] <kompewter> [ DS-2583: Quality Control Reporting via REST API (v4) by terrywbrady · Pull Request #1086 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1086/files#diff-a9f8bb21850852f7ed98e33220c0876cR113
[21:06] <tdonohue> But, it also seems like it *should* be possible to extend this for other useful reports/outputs that folks want to see
[21:06] <mhwood> I agree.
[21:07] <tdonohue> So, generally then...we should work to help get this into 6.0, and it'd be good to find a tester or two to help Terry make that happen
[21:08] <tdonohue> If anyone has interest at your institution, please do try to test this out, and help us get this into 6.0. I'll leave it at that for now/today
[21:09] <mhwood> May I just mention that folk who are bugged by all that EHCache serialization noise in the logs may want to take a peek at DSPR#1170.
[21:09] <kompewter> [ https://github.com/DSpace/DSpace/pull/1170 ] - [DS-2763] EHCache throwing a NotSerializableException: org.dspace.content.CollectionServiceImpl by mwoodiupui
[21:09] <tdonohue> mhwood++ (I haven't had a chance to try it yet..I hope to next week, perhaps, but if others get to it first, I'd love to see these issues fixed)
[21:10] <tdonohue> I'm realizing we're already over time today. Unfortunately, I'm going to have to close up the meeting, as I have a few things still left to get done before the holiday (USA Thanksgiving tomorrow).
[21:10] <tdonohue> One final reminder though... the DSpace UI Prototype Challenge deadline is NEXT WEEK (Friday, Dec 4). So, get your prototypes in, if you are interested in taking part! https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge
[21:10] <kompewter> [ DSpace UI Prototype Challenge - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge
[21:10] <peterdietz> I'm thankful for holidays
[21:11] <tdonohue> With that, we'll close out today's meeting. Thanks all!
[21:11] <peterdietz> I'm not thankful for deadlines ;)
[21:11] <mhwood> :-)
[21:11] <tdonohue> me neither ;)
[21:11] <mhwood> I *should* be; otherwise I'd never finish anything. :-(
[21:14] <KevinVdV> Until next week guys !
[21:14] * KevinVdV (~KevinVdV@d54C5104D.access.telenet.be) Quit (Quit: KevinVdV)
[22:01] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:32] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[23:33] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) Quit (Quit: Leaving.)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.