Timestamps are in GMT/BST.
[0:22] * peterdietz (uid52203@gateway/web/irccloud.com/x-cbogsubsinpcwbpc) Quit (Quit: Connection closed for inactivity)
[1:04] * dyelar (~dyelar@24.225.102.225) has joined #duraspace
[1:04] * dyelar (~dyelar@24.225.102.225) Quit (Client Quit)
[6:52] -weber.freenode.net- *** Looking up your hostname...
[6:52] -weber.freenode.net- *** Checking Ident
[6:52] -weber.freenode.net- *** Found your hostname
[6:52] -weber.freenode.net- *** No Ident response
[6:53] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:53] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:53] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[13:28] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:35] * awoods (~awoods@c-98-245-50-182.hsd1.co.comcast.net) Quit (Quit: Leaving)
[13:51] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[14:21] * th5 (~th5@unaffiliated/th5) has joined #duraspace
[14:51] * robint (81d7fa56@gateway/web/freenode/ip.129.215.250.86) has joined #duraspace
[14:51] * hpottinger (~hpottinge@128.206.253.157) has joined #duraspace
[14:55] <tdonohue> Reminder: Our DevMtg starts here in about 5 minutes. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-02-24
[14:55] <kompewter> [ DevMtg 2016-02-24 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-02-24
[15:00] <tdonohue> Hello all, it's time for our weekly DSpace DevMtg. Agenda is linked above.
[15:01] <mhwood> Here!
[15:01] <tdonohue> Obviously the primary topic for today is 6.0 (and getting us to a feature freeze / RC1). But, I did want to take a few brief minutes to call out the updates/links for the new UI discussions in the agenda
[15:01] * KevinVdV (~kevin@85.234.195.109.static.edpnet.net) has joined #duraspace
[15:02] <tdonohue> If you haven't had a chance to join the UI discussions yet, we have started a summary of pros/cons at: https://docs.google.com/document/d/1bvJrRWEO2ZLTCLqNiaJ_KXGZKHNfXDjnqHWt_ZYGek4/edit
[15:02] <kompewter> [ DSpace UI Working Group - Summary - Google Docs ] - https://docs.google.com/document/d/1bvJrRWEO2ZLTCLqNiaJ_KXGZKHNfXDjnqHWt_ZYGek4/edit
[15:02] <tdonohue> Also, specifically regarding a possible client-side Javascript UI, we had a discussion yesterday with Anurag at Google Scholar. The notes of that discussion are at: https://docs.google.com/document/d/1aH9Be4d_sqwGIDqtd2cpK1KLX8xmBfMl1dIlr7htg20/edit#heading=h.2j4h4w6w3ju0
[15:02] <kompewter> [ DSpace UI Working Group - SEO in JS webapps - Google Docs ] - https://docs.google.com/document/d/1aH9Be4d_sqwGIDqtd2cpK1KLX8xmBfMl1dIlr7htg20/edit#heading=h.2j4h4w6w3ju0
[15:03] <tdonohue> Because these are both large documents, I don't plan to discuss them today. Just wanted to make everyone aware of them as resources. You are welcome to enhance or add comments/questions to them as you see fit (both are publicly editable)
[15:04] <tdonohue> That's really all I wanted to update on the UI discussions. Our next meeting is *tomorrow* (Thurs, Feb 25) at 15:00 UTC (10am EST). A WebEx meeting link will be sent out later today.
[15:04] <hpottinger> Can I just suggest, if you haven't yet invited your non-technical people to read anything about this process, this might be a good time to do so?
[15:05] <tdonohue> Any questions/comments before we move on to 6.0 topics?
[15:06] <tdonohue> hpottinger: yes, the Summary document might give a good overview of what we've talked about... some of it is still a bit technical, and eventually (in preparation for the DuraSpace Summit on March 16-17), I plan to write up a one-page high level summary for folks who really just want a high level overview
[15:07] <tdonohue> So, I think we'll move along to 6.0 topics now. If anyone does have "new UI" questions/comments, feel free to pass them along or add them to the docs. Thanks!
[15:08] <tdonohue> For 6.0, the next steps are continuing to stabilize and get in any last features/improvements, so that we can get to an RC1. We're getting closer...
[15:09] <tdonohue> On the "features" side, we are waiting still for improvements to DSPR#1162. It currently has several noted outstanding issues, and there has been no activity on it in the last week. (KevinVdV is @mire working on this? do you know?)
[15:09] <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
[15:09] <KevinVdV> @tdonohue: We are working on fixing the last issues
[15:10] <tdonohue> Thanks, KevinVdV. Just wanted to be sure that something is happening on this PR.
[15:11] <tdonohue> Moving along then...let's get some updates on our outstanding "improvements": https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A6.0+label%3Aimprovement
[15:11] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A6.0+label%3Aimprovement
[15:11] <mhwood> And bugs. Don't forget the bugs.
[15:11] <tdonohue> mhwood: yep, of course
[15:12] <tdonohue> We have a lot of improvements still open here. I'd like to see if we can do a quick review of status here.
[15:13] <tdonohue> DSPR#1292 (flagged as "work in progress")... is this coming or do we reschedule KevinVdV?
[15:13] <kompewter> [ https://github.com/DSpace/DSpace/pull/1292 ] - [DS-3057] Enable enforce versions to prevent dependency issues by KevinVdV
[15:14] <KevinVdV> Well I don’t know yet…. if I can find the time I will advance on it, but unclear right now. Perhaps I should remove the 6.0 milestone & readd it IF I can finish it ?
[15:14] <tdonohue> Oh, I see in the Travis CI reports..this actually "works" but is reporting that we have dependency conflicts
[15:14] <KevinVdV> Yeah but we need to resolve those dependencies issue prior to mergin
[15:14] <tdonohue> (i.e. two different versions of the same JAR referenced in different modules for example)
[15:14] <helix84> tdonohue: yeah, it adds a test which is failing for now
[15:15] <KevinVdV> & it will help prevent library collision issues in the future
[15:15] <KevinVdV> So really usefull build tool in my opinion
[15:15] <tdonohue> So, it looks like 1292 is something *anyone* could pick up and help us resolve those conflicts. Anyone willing to help advance this?
[15:15] <tdonohue> I agree, it does seem useful (if we can get it moved forward)
[15:15] <mhwood> I agree that this is quite useful. We just need to fix the broken things it is finding for us.
[15:16] <KevinVdV> We can just “ignore” this PR, but it won’t make the potential issues go away ;)
[15:16] <helix84> well I'm not sure if it's possible to completely clean it up, I think I've seen a case where B and C both depend on different versions of A
[15:16] <KevinVdV> Then one version for A needs to be excluded
[15:16] <KevinVdV> But you need to be aware of the conflicts it has
[15:16] <tdonohue> Ok, not hearing any volunteers yet. Let's just keep this PR open and hope someone finds time to revisit this
[15:17] <mhwood> I think it is "nice to have, I want it, but there are other things I should work on first."
[15:18] <tdonohue> moving along for now: DSPR#1287 (this is just waiting on the final PDFBox v2, right helix84?)
[15:18] <kompewter> [ https://github.com/DSpace/DSpace/pull/1287 ] - DS-3052 improvements to PDFBox-based code by helix84
[15:18] <helix84> right
[15:18] <tdonohue> ok, skipping that then
[15:18] <tdonohue> next up, DSPR#1253
[15:18] <helix84> it's a waiting game at this point - no new unfixed bugs and this is almost surely the last RC
[15:18] <kompewter> [ https://github.com/DSpace/DSpace/pull/1253 ] - DS-3009 Allow classpath definition of command line tools by rradillen
[15:20] <tdonohue> 1253 needs some documentation. It's unclear to me how to test it. But, the concept seems OK to me
[15:21] <tdonohue> I added a comment to the PR about the need for docs.
[15:22] <tdonohue> moving along (trying to get through these all quickly)... DSPR#1226 (any updates to share here terry-b or KevinVdV?)
[15:22] <kompewter> [ https://github.com/DSpace/DSpace/pull/1226 ] - [DS-2898] Add support for all authentication methods in the rest api by KevinVdV
[15:23] <KevinVdV> Would be nice to get some additional testers on this one. As previously mentioned I believe the shibboleth itself works but that the JSESSSION parameter might not get passed along.
[15:23] <KevinVdV> But this is not shibboleth specific, this is part of the framework
[15:23] <KevinVdV> So anybody with password login or LDAP can perform some tests
[15:24] <tdonohue> Could we get some volunteers to help test this and move it forward? It seems like this has been "very close" for a long time now, and just needs some final approvals
[15:25] <mhwood> I will try to clear some time to test at least password.
[15:25] <hpottinger> I can help
[15:25] <tdonohue> Ok, it'd be nice to see this get in sometime this week (or early next), if possible. This is one that seems to be "stuck"
[15:26] <tdonohue> moving along for now. DSPR#1129
[15:26] <kompewter> [ https://github.com/DSpace/DSpace/pull/1129 ] - Fix: Bitstream's retrieval's response without filename by BrunoNZ
[15:27] <mhwood> Conflicted; assigned to helix84.
[15:27] <tdonohue> helix84, looks like you assigned this to yourself, and it has a merge conflict. Are you working on it?
[15:27] <helix84> oops, forgot about that one. I'll take a look again.
[15:27] <tdonohue> I've already given a +1. I think this looks good, just needs rebase, etc.
[15:27] <tdonohue> thanks, helix84
[15:28] <tdonohue> moving along, DSPR#1118
[15:28] <kompewter> [ https://github.com/DSpace/DSpace/pull/1118 ] - DS-2635 discovery facets with configurable ordering by jonas-atmire
[15:29] <tdonohue> This one needs testers. But, it also needs a minor rebase, as we fixed the bug with "workflow.workflow.framework" on master...and this changes the config back to that double-prefix. (I'll add a comment)
[15:30] <hpottinger> I tested it, the change to sort by value is welcome, but ascending order isn't an improvement over alpha
[15:31] <tdonohue> hpottinger: not sure I follow. What's wrong with "ascending order"? Is there an example of why that's not an improvement?
[15:32] <tdonohue> Oh, I see..cause the facets are always sorted in descending order?
[15:32] <hpottinger> yep, thanks, saved me a lot of typing
[15:33] <hpottinger> if you see a bunch of single result facets up front... you're likely to shake your head and wander off
[15:33] <tdonohue> Ok, so this needs some minor updates. Sounds like it's close though. I added some comments on last steps
[15:33] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[15:34] <tdonohue> For now, seems like we should move along... DSPR#1010
[15:34] <kompewter> [ https://github.com/DSpace/DSpace/pull/1010 ] - DS-2696-showJSP-catch-all-exceptions by akinom
[15:35] <hpottinger> whenever the sort order for 1118 is, erm, sorted, I can retest quickly
[15:35] <tdonohue> We need a JSP user to test 1010 out...It looks right to me, but I don't know if this would have any other implications (doubtful though)
[15:35] <mhwood> 1010 looks sensible to me, but we don't use JSPUI here....
[15:36] * hpottinger looks at the list of attendees, sees a few JSPPUI users there... considers naming them...
[15:37] <tdonohue> If anyone wants to test this, it looks like a "just merge" once tested
[15:37] <tdonohue> moving along, DSPR#962
[15:37] <hpottinger> it looks easy enough to test
[15:37] <kompewter> [ https://github.com/DSpace/DSpace/pull/962 ] - DS-2608: Improve collections and communities metadata in XMLUI discovery results by nicolasschwab
[15:37] <tdonohue> assigned to hpottinger. Any updates here?
[15:38] <tdonohue> To me, this looks like a simple, nice code refactor...but needs a tester
[15:38] <hpottinger> none, have been putting out fires and dodging spitballs the past week
[15:38] <tdonohue> so, this is still on your radar though?
[15:38] <hpottinger> it is
[15:39] <tdonohue> Ok,...moving along then... DSPR#934
[15:39] <kompewter> [ https://github.com/DSpace/DSpace/pull/934 ] - DS 2557 xmlui curation ux by aschweer
[15:39] <hpottinger> I'm home with a cold today, testing might prove an amusing distraction
[15:39] <tdonohue> ugh, 934 needs another rebase
[15:40] <mhwood> hpottinger was seeing this symptom the other day. Similar cause?
[15:40] <tdonohue> Anyone interested in helping get 934 moved forward? I just commented to aschweer that it needs another rebase
[15:41] <hpottinger> erm, what symptom?
[15:41] * hpottinger *is* a symptom today :-\ achoo!
[15:41] <mhwood> The task was completed successfully.
[15:41] <mhwood> STATUS: Fail, RESULT: Nothing to do for this DSpace object.
[15:41] <hpottinger> oh, yeah, that
[15:41] * hpottinger grumbles...
[15:41] <tdonohue> yes, 934 helps clean up that UI & its messaging.
[15:42] <hpottinger> OK, sign me up
[15:42] <tdonohue> assigned to hpottinger then
[15:42] <tdonohue> moving along, DSPR#931
[15:42] <kompewter> [ https://github.com/DSpace/DSpace/pull/931 ] - DS-2552: Makes configurable whether handles or DOIs should be displayed in JSPUI by pnbecker
[15:43] <tdonohue> from pbecker...is this just looking for more reviewers / testers?
[15:43] <mhwood> I'm assuming that johlton's comment represents a test.
[15:44] <pbecker> just comming back.
[15:45] <tdonohue> true. I reviewed the code here and it looks fine to me.
[15:45] <hpottinger> we need to teach kompewter how to needle JSPUI users
[15:46] * pbecker will test pr#1010
[15:46] <tdonohue> pbecker, it seems like 931 is a useful fix for JSPUI users. I'm not against getting this merged if you & others are satisfied
[15:46] <pbecker> sounds great.
[15:46] <pbecker> johlton is my colleague
[15:46] <pbecker> so maybe someone else should test it
[15:46] <pbecker> nevertheless, I think it's ready for merge.
[15:47] <tdonohue> any hints to testing (especially if you don't actually have DOIs configured locally)? Or do we need someone with DOIs?
[15:48] <pbecker> we need someone with doi.
[15:48] <pbecker> the only purpose of this pr is to make it configurable which persistent identifier is shown in messages like "use this identifier to cite this item: ..."
[15:48] <tdonohue> I was assuming someone could just add "dummy" DOIs in the appropriate metadata fields and see if this works? Is that not possible?
[15:48] <pbecker> current forms I were aware of are handle (default) and doi
[15:49] <pbecker> it's a while since I created this PR. I'm currently not sure if it uses the IdentifierService or the metadata to recognize the available identifiers.
[15:50] <tdonohue> Ok. If it *is* possible to just add "dummy" DOIs, then it might be worth noting that in the PR...it might be easier to find testers through that route, instead of having to track down someone with DOIs enabled
[15:50] <pbecker> looking into the code, it needs any of our DOIIdentifierProviders that gives back a doi.
[15:50] <tdonohue> moving along for now though... DSPR#896
[15:50] <kompewter> [ https://github.com/DSpace/DSpace/pull/896 ] - DS-1814: Allow submitter to create new version of their items. by pnbecker
[15:51] <tdonohue> looks like 896 is still waiting on a rebase
[15:52] <hpottinger> 896 has a dependency, too?
[15:52] <pbecker> I won't get this ready for 6.0
[15:52] <pbecker> I removed the milestone.
[15:53] <tdonohue> ok, thanks for the update, pbecker
[15:53] <pbecker> It's my only PR I didn't had the time to rebase after service api.
[15:53] <pbecker> would have bin a great improvement...
[15:53] <tdonohue> next up, DSPR#885
[15:53] <kompewter> [ https://github.com/DSpace/DSpace/pull/885 ] - DS-1349: Add configuration to hide submitter in item history (JSPUI). by pnbecker
[15:54] <pbecker> This was discussed two weeks ago. But I have concerns with the changes requested.
[15:56] <tdonohue> Which changes specifically?
[15:56] <pbecker> pushing this down in the api layer
[15:57] <pbecker> It's all mentioned in the PR comments.
[15:57] <pbecker> "Ideally, if this config was disabled, the submitter info would not even be provided to the UI layer."
[15:57] <pbecker> That is a great idea, but not the way our UIs work currently.
[15:57] <tdonohue> Ok. Yes, I think it's OK to let this slide as-is (as noted in comment by mhwood in PR). Ideally, longer term, we move this down a level, as hiding this info from "one UI" doesn't do anything for all the other ways to access this info
[15:57] <mhwood> That's a big job with far-reaching consequences.
[15:58] <pbecker> This is something for the new UI.
[15:58] <hpottinger> if it *is* there should be a use case for this desired functionality
[15:59] <tdonohue> I added a comment to the PR that I agree with mhwood's comments on 885
[15:59] <pbecker> so can we merge this?
[15:59] <mhwood> So, do we think it is okay to accept this as-is, for now, and re-architect access control later?
[16:00] <tdonohue> pbecker: I saw one other (minor) oddity in the code...which I added a comment on...your usage of "getPropertyAsType()" on ConfigurationService instead of simply "getBooleanProperty". But, the code looks OK. There's just some minor messy-ness that could be cleaned up
[16:01] <tdonohue> mhwood++ (Yes, I think this is more about access control issues, which we are well aware of and exist in use cases / roadmap)
[16:01] <tdonohue> Last one here... DSPR#879
[16:02] <kompewter> [ https://github.com/DSpace/DSpace/pull/879 ] - DS-2490: adds org.dspace.identifier.VersionedDOIIdentifierProvider by pnbecker
[16:02] <mhwood> Um, is 885 okay to merge after perhaps some minor cleanup?
[16:02] <tdonohue> is this just waiting on testers?
[16:02] <pbecker> this has a dependency.
[16:02] <pbecker> one moment, looking for it.
[16:02] <tdonohue> mhwood: yes...885 is ok to merge after minor cleanup (sorry, I guess I wasn't clear)
[16:03] <mhwood> I agree. I could only find some picky problems with 'new Boolean()'.
[16:03] <pbecker> I will take care of the Booleans right after the meeting.
[16:03] <pbecker> 885 depends on DSPR#900
[16:03] <KevinVdV> Need to run, if any of my PR’s need attention please add it in the comments.
[16:03] * KevinVdV (~kevin@85.234.195.109.static.edpnet.net) Quit (Quit: KevinVdV)
[16:04] <kompewter> [ https://github.com/DSpace/DSpace/pull/900 ] - DS-2497: Keep version numbers stable. by pnbecker
[16:04] <pbecker> sorry, 879 depends on 900 of course.
[16:05] <tdonohue> I updated the description of 879 to note that dependency
[16:05] <tdonohue> so is 900 waiting on more testing?
[16:05] <pbecker> KevinVdV marked is as to be discussed.
[16:05] <mhwood> No note on the PR as to *what* needs discussion.
[16:06] <tdonohue> 900? no, it's not marked as to be discussed
[16:06] <pbecker> I was in contact with Ben from atmire last summer. I think I respected his concerns. I asked for feedback by mail, but unfortunatly they didn't had the time yet.
[16:06] * robint (81d7fa56@gateway/web/freenode/ip.129.215.250.86) Quit (Quit: Page closed)
[16:06] <pbecker> sorry, I forget about that, was another PR.
[16:07] <pbecker> 881 is marked as needs discussion. All three PRs handle Persistent Identifiers combined with versioning.
[16:07] <tdonohue> Ok. So, with 900, are we just looking for testers? If so, perhaps we could ping KevinVdV on it to see if someone from @mire could help?
[16:07] <pbecker> so, yes 900 only misses testers/reviews/+1 ;-)
[16:09] <tdonohue> I pinged KevinVdV on 900, since it's assigned to him
[16:09] <pbecker> thanks
[16:10] <tdonohue> Ok, that's our full list of improvement PRs.
[16:11] <tdonohue> As we are over time here, I wonder if there's any final comments for today's "official meeting"? I think we need to find time to do more of this review "offline". We still have too much to dig through in meetings, so I encourage individuals to quickly review (+1s) PRs and/or ping others when things need review
[16:12] <hpottinger> re bugs, it looks like DS-3004 has had some comments recently
[16:12] <kompewter> [ https://jira.duraspace.org/browse/DS-3004 ] - [DS-3004] extremely slow searching when logged in as admin - DuraSpace JIRA
[16:12] <mhwood> Indeed it has. :-)
[16:13] <tdonohue> yep. Not sure there's much more to accomplish with that here, now though. But, good to see it moving
[16:13] <hpottinger> mhwood: if you have ideas of "things to try" I'm willing to try them
[16:13] <mhwood> Quickie: slap an index on that field and see if things speed up. Also see how much the database storage increased.
[16:13] <hpottinger> aye aye
[16:14] * tdonohue unfortunately needs to step away for a moment. We've got a blizzard here & kids are around today..need to help "wrangle" for a moment
[16:14] <mhwood> More work: try lazy-initializing a cached UUID for Administrator and doing find() rather than findById().
[16:14] <tdonohue> While I like the discussion & I hope you continue it...I'm not going to call any more topics for today's meeting. So, it's "closed"...but post-meeting discussion is more than welcome
[16:14] <hpottinger> mhwood: can I trouble you to add those notes to the ticket?
[16:14] <mhwood> OK, will add them.
[16:15] <hpottinger> thanks!
[16:15] <mhwood> Note: creating that index over a large repo. will take a while. Dunno how long.
[16:15] <mhwood> Actually my suggestions are already in there, but I will summarize.
[16:16] <hpottinger> we'll just see how "high performance" this Oracle DB really is :-)
[16:16] <hpottinger> thanks, mhwood, sorry, I have a head cold
[16:18] <mhwood> Commented.
[16:32] * cknowles (uid98028@gateway/web/irccloud.com/x-auldlwogqxzhuffh) has joined #duraspace
[17:13] * hpottinger (~hpottinge@128.206.253.157) Quit (Quit: Leaving, later taterz!)
[17:51] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[18:04] * peterdietz (uid52203@gateway/web/irccloud.com/x-bxxexlabhrnlioku) has joined #duraspace
[19:41] * th5 (~th5@unaffiliated/th5) Quit (Ping timeout: 244 seconds)
[20:21] * cknowles (uid98028@gateway/web/irccloud.com/x-auldlwogqxzhuffh) Quit (Quit: Connection closed for inactivity)
[21:28] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) Quit (Quit: Leaving.)
[21:56] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.