Timestamps are in GMT/BST.
[2:42] * peterdietz (uid52203@gateway/web/irccloud.com/x-rqpddskcqydhaufl) Quit (Quit: Connection closed for inactivity)
[6:28] -asimov.freenode.net- *** Looking up your hostname...
[6:28] -asimov.freenode.net- *** Checking Ident
[6:28] -asimov.freenode.net- *** Found your hostname
[6:28] -asimov.freenode.net- *** No Ident response
[6:28] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:28] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:28] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[11:00] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[13:15] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:56] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[14:49] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[14:54] * KevinVdV (~kevin@85.234.195.109.static.edpnet.net) has joined #duraspace
[14:55] * hpottinger (~hpottinge@mu-162038.dhcp.missouri.edu) has joined #duraspace
[14:58] <tdonohue> Morning all, we'll be getting started with our DSpace Developer Mtg shortly. If you haven't seen it yet, here's our agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-02-10
[14:58] <kompewter> [ DevMtg 2016-02-10 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-02-10
[15:00] <tdonohue> My clock now shows the top of the hour, so we'll get started
[15:01] <tdonohue> Obviously, in recent weeks, our primary topic of concern in these meetings has been 6.0 (rightly so). But, today, I wanted to take a brief break to give you all a chance to voice opinions on the direction of the next UI for DSpace (coming in 7.0)
[15:01] <tdonohue> So, for the first 15 mins or so, I'd like to hear your opinions/thoughts/feedback on any of the UI Prototypes / proposed technologies that have come out of the UI Prototype Challenge & recent discussions: https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge
[15:01] <kompewter> [ DSpace UI Prototype Challenge - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge
[15:02] <tdonohue> Obviously, 15 mins may not be enough time to cover it all, and I'm working with Jonathan Markow to schedule some followup discussions, especially with Committers (as I feel I haven't heard opinions from many of you yet, and I want to hear from everyone)
[15:03] <tdonohue> To give a brief summary though... the UI platforms (from prototypes & under discussion) have brought up some specific questions about what we want out of the next UI... here's just a few:
[15:04] <tdonohue> 1) Do we want to stay on a Java web framework (e.g. Spring Boot or MVC), consider a client-side Javascript UI (e.g. Angular.js or Ember.js) or even move to something like Ruby on Rails?
[15:04] * rivaldi8 (~alexm@gardeny.udl.cat) has joined #duraspace
[15:04] <hpottinger> I don't know about everyone else, but my time has been stretched pretty thinly lately, I've only watched one video (partially), I need to watch them all.. the trick is to find a block of time to do so.
[15:05] <pbecker> I have doubts against any ruby solutions. In every modern webapp you have JavaScript code. DSpace is build in Java. So both technologies will stay in DSpace. I would prefer to not add another technology/language to DSpace. This basically is the same point as seeing that the DSpace community is quite java centric.
[15:05] <tdonohue> 2) Do we want to continue to rely heavily on the Java API (as the primary API), or consider moving more towards actually *using* our REST API (either as the primary API behind the UI, or at least as a supporting API for any javascript-based tools)
[15:05] <mhwood> The more I work with RoR the more I want to get away from it. It's clearly very good, for things I never do.
[15:05] <pbecker> hpottinger: I have the same problem. I attended most of the demonstartions live, nevertheless I have to review all of them to be able to give qualified feedback.
[15:06] <tdonohue> I'll stop after those two questions...as I want to listen to your thoughts here :)
[15:06] <hpottinger> I have a preference for keeping complexity away from the stack, so I will freely admit to a bias against non-JVM-based solutions, as well as ones that rely a lot on JS frameworks
[15:07] <tdonohue> Sidenote: with regards to the hour long videos, the first 30 minutes is demonstration (and likely the most important part)...the last 30 minutes of each is Q&A (which is useful to watch too, if you can fit it in, but may be less meaty)
[15:08] <pbecker> regarding the second question I tend to the REST solution with a transition phase till the REST API supports all of the Java API. The only concern left regarding this question for me is if this can be done with acceptable performance.
[15:09] <mhwood> I think that perhaps the underlying technology of the UI should drive the answer to (2). Some will be a more natural fit than others.
[15:09] <helix84> I'm also very sorry that I haven't had time to review the videos yet. For me, the primary concern is to be able to test changes to templates, including any logic just by reloading the page, no recompiling.
[15:11] <pbecker> tdonohue: do you already had the chance to reach out to google scholar regarding indexing of javascript solutions?
[15:11] <helix84> On the other hand, I'm very biased against single-page apps in JavaScript framework of the day - some repositories don't get updated for many years, so it's important we're on stable client-side technologies. And indexing (which may be hindered by SPAs) is also a major concern.
[15:11] <tdonohue> helix84: could you expand on that? It is just about making sure *any of these* solutions lets you reload the page? Or are you specifically expressing concerns about a particular technology (Java or Ruby or JS)?
[15:12] <pbecker> helix84: good point!
[15:12] <helix84> My concerns are only about what we serve to the client (client-side JS). I don't onject to any particular proposal as I haven't reviewed them yet.
[15:12] <hpottinger> My experience with JS frameworks is a bit limited, but, I'm wary of their dependence on network availability... that really puts a wrench in my ability to work wherever I happen to be
[15:13] <tdonohue> pbecker: Anurag from Google Scholar has mentioned that client-side javascript is not a problem as long as you can create "cached" HTML pages to index (and there are standard tools for doing that). I am also aware that the primary Google spiders now actually *support* indexing client-side JS...so it could be that Google Scholar will do so at some point too
[15:13] <hpottinger> so... I suppose it's not the JS framework per se, it's the stack required to work on that framework
[15:14] <helix84> tdonohue: what do you mean by "cached"? (examples of such solutions would help)
[15:15] <pbecker> helix84: someone mentioned some nodejs solution that runs the javascript once by night to create static html page that can then be indexed.
[15:16] <tdonohue> helix84: one example is using PhantomJS: http://phantomjs.org/ ... it allows spiders or similar to see the same HTML as a normal User would (i.e. execute the JS). By default, spiders would just see the JS code, obviously
[15:16] <kompewter> [ PhantomJS | PhantomJS ] - http://phantomjs.org/
[15:16] <helix84> With preservation, the motto is to KISS, so I only care about what we serve to the client to be simple. If we use node.js on the server side - that doesn't matter to me.
[15:17] <tdonohue> helix84: I will admit here though, I'm less knowledgeable about PhantomJS (and other solutions) than others may be. I've not done much with client-side JS myself, but there are others in the community who have (e.g. Art Lowel from @mire, and folks at Texas A&M)
[15:17] <helix84> tdonohue: I see. That's an example of what I'd hate DSpace to become :)
[15:18] <tdonohue> helix84: that's good feedback. This is the sort of thing I want to be hearing from Committers (right now, I don't have a good idea of where everyone stands on these sorts of questions)
[15:18] <pbecker> That brings me to another point: We should try not lo enlarge the server side stack too much. What I mean: we depend on Postgres, a servlet container (for solr, rest, rdf), maybe a triple store. If possible I would like to avoid to also depend on nodejs.
[15:20] <tdonohue> So, what I'm hearing from folks here (at least pbecker, helix84, hpottinger, mhwood) is that all of you seem to be favoring a solution using a Java web framework. There's major concerns with client side JS and Ruby solutions voiced above. Correct?
[15:20] <mhwood> Yes.
[15:20] <hpottinger> correct
[15:21] <pbecker> +1
[15:21] <helix84> basically (ruby is not client-side)
[15:21] <hpottinger> client-side JS is OK for applying "a nice coat of paint" but I don't want it involved in semantic work
[15:21] <tdonohue> Is there anyone else in this discussion who'd like to add your opinion? There's a few other folks in this room that haven't said anything yet
[15:21] <helix84> (sorry, I parsed that sentence wrong)
[15:21] <mhwood> hpottinger++
[15:22] <tdonohue> helix84: so, your concern is primarily against client-side solutions...you prefer anything server side (Java or Ruby). Thanks for clarifying
[15:22] <hpottinger> client-side JS should also be well-behaved as far at a "nice coat of paint" is concerned: working with it should not get in the way of, say, hacking on DSpace while offline.
[15:23] <mhwood> My impression is that a good deal of the bulk of client-side JS frameworks represents impatience with the pace of HTML5 development and rollout, which could now be a little dated.
[15:23] <helix84> To clarify my concern for ease of theme-development: a) make change - reload page - see result b) templates should roughly correspond to pages
[15:24] <hpottinger> Ideally, I'd like to see a template system that could be handed off to a graphic designer, so... pretty close to plain HTML would be ideal
[15:25] <pbecker> tdonohue: Shall each one of us add this to the google docs or will you add some summary of this meeting over there?
[15:25] <tdonohue> So, this is all excellent discussion, but I think I'll ask that we wrap this up for today. I *would* encourage everyone to add even *general* opinions to the public Evaluation Form (general opinions go on the "Technology Feedback" tab). It really will help us better gage the opinions of everyone
[15:25] <tdonohue> https://docs.google.com/spreadsheets/d/1XWxEERh0UXCOo7LhocMMaqbY2u4b6oI11oWOjSp_aSQ/edit
[15:25] <kompewter> [ DSpace UI Prototype Evaluation Form - Google Sheets ] - https://docs.google.com/spreadsheets/d/1XWxEERh0UXCOo7LhocMMaqbY2u4b6oI11oWOjSp_aSQ/edit
[15:25] <mhwood> Indeed, I would like to spend far less time figuring out what the presentation pipeline is going to do to what I want displayed.
[15:25] <hpottinger> deadline?
[15:25] <tdonohue> I will note that currently, on the "Technology Feedback" tab, the few opinions that have been entered seem supportive to client side JS, etc. So, hearing other voices is important here.
[15:26] <mhwood> Add me to the list of people who need to carve out more time for this review.
[15:26] <tdonohue> deadline: preferably by the end of this week (even just general feedback). But, you are welcome to enhance, clarify your thoughts in the coming weeks (as you see fit)
[15:27] <hpottinger> my main bias is: whatever we get better be easy to set up and maintain, and it ought to (in the best of worlds) be fun to work with.
[15:28] <KevinVdV> Not be a buzzkill here, but would it not be advisable to go on to the next topic (DSpace 6.0)
[15:28] <tdonohue> I will also note that I'm working with Jonathan Markow to setup some Committer discussions (likely a phone call or two) around these proposed UI platforms. I want to be sure we hear from as many of you as possible (in case folks haven't been able to attend todays mtg, etc). I'll email about that to dspace-commit
[15:29] <tdonohue> KevinVdV: yes, we are ready for that. It's just very important to have these UI feedback discussions in parallel, as the *decision* is planned to be made within the next month.
[15:29] <KevinVdV> I agree, but I would prefer not to have these discussion in here right now ;)
[15:29] <tdonohue> But for now, lets move along to DSpace 6.0
[15:30] <tdonohue> So, with 6.0, we still have one outstanding feature PR. Do we have a "latest status" on if this is ready? DSPR#1162
[15:30] <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:30] <helix84> unfortunately, no improvement since last week :/
[15:31] <tdonohue> ugh. Ok. So, we cannot wait forever here, obviously. We may have to let this one "slip" unless we can get resolution to the remaining issues quickly.
[15:31] <mhwood> Is this something we can decide today?
[15:31] <KevinVdV> Bugs have been fixed already
[15:31] <KevinVdV> & some have been reported as not being bugs at all
[15:32] <helix84> sorry, I missed the last comment
[15:32] <KevinVdV> & the two open ones include 1 configuration & an issue with the API key which isn’t related to the actual implementation
[15:32] <tdonohue> Ok, so it sounds like we have one last "retest" to perform here? I agree with mhwood that I'd really like to have an "in" or "out" decision this week (perhaps by end of week)
[15:34] <KevinVdV> I agree, but the PR has been regullarly updated, so if it remains on a single issue give them to resolve it ?
[15:34] <hpottinger> I'm worried about what supporting this feature might look like...
[15:34] <helix84> assuming the bugs are really fixed, the year is a configuration issue and the API key is a mystery, I think I'll be able to re-test soon
[15:35] <tdonohue> I can also set aside some time to give this a test this week ( I was finally provided with an API key to test with )
[15:35] * PhilipV (~philip@85.234.195.109.static.edpnet.net) has joined #duraspace
[15:36] <tdonohue> hpottinger: I agree that there are concerns here with long term support for this feature. I like the integration though, and I hope someone (@mire?) will be able to help us keep it up to date / have a valid API key to test with. I had to lean on Elsevier to finally get an API key on my end (and they only could give me one that expires in 3 months)
[15:37] <tdonohue> Nonetheless, I think we should try to move this forward, as Elsevier & @mire have both been responsive, and hopefully they will continue as such in the future (if this should have future issues)
[15:37] <hpottinger> a committment of support from some group would go a long way...
[15:38] <tdonohue> So, I think we give this a last test..we try to get this merged by the end of the week (if possible). If more issues exist, we will have to make a decision on whether to continue to wait (as this one has been hanging here for way too long)
[15:39] <tdonohue> For now, we have a few testers (myself & helix84). We'll move on to other topics
[15:40] <tdonohue> Next up, improvements: https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A6.0+label%3Aimprovement
[15:40] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A6.0+label%3Aimprovement
[15:40] <tdonohue> I'm going to skip any that are "work in progress" or "merge conflict". Others, I'd like to get assigned quickly or someone to volunteer to followup
[15:40] <tdonohue> DSPR#1253
[15:41] <kompewter> [ https://github.com/DSpace/DSpace/pull/1253 ] - DS-3009 Allow classpath definition of command line tools by rradillen
[15:41] <tdonohue> Thoughts on this?
[15:41] <helix84> one concern - that there won't be a single place to look for command definitions (launcher.xml)
[15:42] <mhwood> So, essentially, this adds the ability to drop in new commands, if I understand it.
[15:42] <tdonohue> One note is that this desperately needs documentation. Not sure I fully understand how to even use it
[15:42] <tdonohue> (and the descriptions sound interesting, but give little information on how to test or use it)
[15:43] * th5 (~th5@unaffiliated/th5) has joined #duraspace
[15:43] <KevinVdV> I checked with my collegue & he is willing to create docs for this.
[15:43] <tdonohue> Ok, I added a note to the PR as well on docs needed
[15:44] <tdonohue> For now, lets move on, as I feel we'd just be "spinning our wheels" on this one without some documentation
[15:44] <tdonohue> DSPR#1248
[15:44] <kompewter> [ https://github.com/DSpace/DSpace/pull/1248 ] - [DS-1518] Support of StartTLS in LDAPAuthentication. by christian-scheible
[15:44] <tdonohue> This one is assigned already to helix84. Any updates?
[15:44] <mhwood> helix84: please note your concern in the ticket or PR.
[15:45] <helix84> As far as I'm concerned, this one's ready to go in. It will conflict with the other JNDI PR, but I have to re-test that one anyway.
[15:45] <tdonohue> Oh, I see it requires a minor config change?
[15:45] <tdonohue> As long as we have someone willing to make the minor config change (noted in the PR) and fix up any conflicts with the other JNDI PR, this one looks fine to me
[15:46] <helix84> I haven't merged it only because I was the only tester. But if there are no objections, I'll merge it.
[15:46] <helix84> just throw your +1 and it's done :)
[15:46] <tdonohue> Any objections here?
[15:47] <tdonohue> I think this *does* need updates to the LDAP Auth docs (obviously)...but other than that, the code looks reasonable to me
[15:48] <tdonohue> ok, I added my +1
[15:48] <helix84> thanks, I'll take it from here :)
[15:48] <tdonohue> moving on.. DSPR#1226 (pinging terry-b and KevinVdV..any updates?)
[15:49] <kompewter> [ https://github.com/DSpace/DSpace/pull/1226 ] - [DS-2898] Add support for all authentication methods in the rest api by KevinVdV
[15:49] <KevinVdV> @Terry-b does the shibboleth authenticate ? (In the logs only regardless of the other pages)
[15:49] <terry-b> I have hit a wall with the issue. I need someone else to recreate my issue or some new code to test.
[15:50] <KevinVdV> If so then I assume that the “session” isn’t carried over, it doesn’t work with the “token” key anymore
[15:50] <terry-b> I put the latest status into the Jira ticket.
[15:50] <mhwood> Aaaaand it has another merge conflict.
[15:51] <KevinVdV> That can be resolved….
[15:51] <mhwood> Yes.
[15:52] <tdonohue> Anyone else able to do some Shib testing here to help out. There is a demo Shib site (http://www.testshib.org/) which might be of use to test the basics of a Shib AuthN
[15:52] <KevinVdV> But from what I can detect from the JIRA comments is that the shibboleth itself works. But that the results aren’t visable on other pages
[15:52] <KevinVdV> Which is normal, but that all depends on HOW you are testing the rest API.
[15:53] <KevinVdV> Because I don’t use the “rest-dspace-token”
[15:53] <KevinVdV> If that makes sense...
[15:53] <tdonohue> Could we clarify *how* this is expected to be used with REST? Maybe it's a matter of better documenting how Shib or LDAP authN works with REST?
[15:54] <helix84> without the token, dspace-rest doesn't know who you are
[15:54] <terry-b> So we can authenticate but we cannot do anything with the session. How does this get fixed?
[15:54] <terry-b> Note also that https://jira.duraspace.org/browse/DS-3034 is a new issue with XMLUI and Shibb.
[15:54] <kompewter> [ [DS-3034] When Password and Shib Authentication are enabled, Shib redirect does not take place - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3034
[15:54] <kompewter> [ https://jira.duraspace.org/browse/DS-3034 ] - [DS-3034] When Password and Shib Authentication are enabled, Shib redirect does not take place - DuraSpace JIRA
[15:54] <KevinVdV> By using the JESSIONID
[15:54] <helix84> I see how the session could theoretically work across REST endpoints with shib, but not with LDAP
[15:55] <KevinVdV> Why not with LDAP ?
[15:55] <KevinVdV> I have seen it working locally
[15:55] <KevinVdV> Spring stores the special groups for you
[15:55] <helix84> without using the token?
[15:56] <KevinVdV> You just have to pass the JSESSIONID around instead of the token, that is the only change
[15:56] <helix84> ok, I haven't tried that
[15:57] <helix84> anyway, if that's required, we need to document that
[15:57] <hpottinger> OK, from my work with DS-570, I know that Shib AuthN causes a new JSESSIONID to be created, even if you attempt to disable session fixation attack prevention
[15:57] <kompewter> [ https://jira.duraspace.org/browse/DS-570 ] - [DS-570] Redirect users to current page on login - DuraSpace JIRA
[15:57] <tdonohue> So, I guess I'm curious...how is the "best way" to test this is all working correctly now with JSESSIONID? Is there some basic "how to test this" documentation we could create, to ensure everyone is testing it *correctly* (and understands the change to JSESSIONID)?
[15:57] <helix84> and I'm not sure how I feel about having 2 ways of keeping client-side state
[15:58] <KevinVdV> Checkout my comment from December 24th
[15:58] <KevinVdV> It has curl requests in out to demenstrate how it can work
[15:59] <KevinVdV> OR you can use postman (free chrome extension, this one will automatically remember the JSESSIONID: https://www.getpostman.com/
[15:59] <kompewter> [ Postman | Supercharge your API workflow ] - https://www.getpostman.com/
[15:59] <tdonohue> KevinVdV: can you pull out those curl request and put them into the description? I'm not sure if you are referring to comments on the PR or JIRA ticket...and there's a ton of comments on both
[16:00] <helix84> tdonohue: the initial comment on the PR
[16:00] <KevinVdV> Updated the description in the initial comment on how it would work with curl
[16:00] <tdonohue> thanks KevinVdV. I see them now
[16:00] <hpottinger> so... my comment above is that the JSESSIONID *changes* after you log in via Shib
[16:01] <tdonohue> hpottinger: right, but once you are logged in, it shouldn't change...and KevinVdV's curl examples show that you use the JSESSIONID obtained *after* login
[16:01] <KevinVdV> But doesn’t it do that for DSpace as well ? Since you are redirected to another page ?
[16:01] <KevinVdV> So indeed, the one you get back AFTER authentication should work
[16:02] <hpottinger> yes, as long as you use *that* JSESSIONID, you should be fine
[16:02] <KevinVdV> Then it is just a matter of docs, right ?
[16:03] <helix84> hpottinger: so you get the correct JSESSIONID back together with the login response?
[16:03] <tdonohue> So, do we have a few people who can help try and move this work forward (re-test)? This seems like a very important feature for REST
[16:03] <KevinVdV> & I have been able to verify with all but shibboleth & X.509
[16:03] <tdonohue> KevinVdV: yes, it sounds like we need to better document this new behavior. The curl examples are a good start to that though
[16:03] <pbecker> helix84: the JSESSIONID is changed during login for security reasons.
[16:03] <hpottinger> according to the Tomcat folks, it's the same session data object, they just change the ID... in my experience, I cannot confirm that... but it might be due to DSpace's handling of the session ID... so... anyway, I'd urge caution in depending on it
[16:03] <pbecker> helix84: so you need to use the JSESSIONID you get back right after a successful login.
[16:04] <KevinVdV> Which is what DSpace does right now I assume
[16:04] <helix84> pbecker: my question is what right after means. The successful login response?
[16:05] <pbecker> helix84: yes, as fare as I know.
[16:05] <tdonohue> helix84: yes, the correct JSESSIONID is returned on the successful login response (as shown by the 'curl' examples that KevinVdV documented)
[16:05] <helix84> pbecker: in that case I don't see the problem
[16:06] <tdonohue> Ok. So, it sounds like we all have a better understanding now of *how* this is supposed to work. We just need to have folks re-test it to ensure it's working correctly for Shibb & X.509
[16:06] <tdonohue> As I noted, there is a public Shib test server at: http://www.testshib.org/
[16:06] <kompewter> [ TestShib/Home ] - http://www.testshib.org/
[16:06] <KevinVdV> Testers for password authentication are also welcome, one +1 on that would be great
[16:07] <tdonohue> We are now over our one hour meeting time. Any objections to continuing review of PRs though (as we were scheduled to have a PR/JIRA Review for the next hour anyhow)?
[16:08] <KevinVdV> I’m out for the next hour I’m afraid, so if you need my input on something please email me.
[16:08] <tdonohue> KevinVdV. That's ok, thanks for letting us know
[16:08] * KevinVdV (~kevin@85.234.195.109.static.edpnet.net) Quit (Quit: KevinVdV)
[16:09] <mhwood> I can continue.
[16:09] <tdonohue> So, "officially", we'll close out the DevMtg. However, I would like to continue here in #duraspace with more 6.0 PR reviews
[16:10] <tdonohue> next up, DSPR#1214 (this looks to be the "other" JNDI PR that needs cleanup?)
[16:10] <kompewter> [ https://github.com/DSpace/DSpace/pull/1214 ] - [DS-1494] Facilitate use of jndi.properties instead of DSpace configuration for LDAP credentials by mwoodiupui
[16:10] <mhwood> Yes, I'm looking at the conflict now.
[16:10] <tdonohue> Ok, sounds good. The concept here sounds good in general, so we'll just need an updated PR
[16:11] <tdonohue> DSPR#1138 (I'm adding this in here cause I wonder if we should just reschedule this...seems to need a bit more work, based on last comment)
[16:11] <helix84> I'm also a bit clearer now about what it's supposed to do, so I'll re-test
[16:11] <kompewter> [ https://github.com/DSpace/DSpace/pull/1138 ] - input-forms localization in xmlui by kosarko
[16:11] <mhwood> Thank you helix84.
[16:12] <tdonohue> based on the last comment to 1138, I think I'd recommend closing this PR for a better solution
[16:12] <helix84> The correct approach to input-forms i18n would be to include the message keys
[16:13] <helix84> I think we still haven't replied to the submitter about that
[16:14] <tdonohue> I replied and closed the PR
[16:14] <mhwood> It sounds as though the preferred approach is already running and we just need for them to contribute it.
[16:14] <tdonohue> moving along, DSPR#1129
[16:14] <kompewter> [ https://github.com/DSpace/DSpace/pull/1129 ] - Fix: Bitstream's retrieval's response without filename by BrunoNZ
[16:15] <tdonohue> this looks like an obvious win to me. Anyone willing to give it a quick test & then merge it?
[16:15] <helix84> I'll take it
[16:16] <tdonohue> thanks helix84!
[16:16] <tdonohue> moving along, DSPR#1118
[16:16] <kompewter> [ https://github.com/DSpace/DSpace/pull/1118 ] - DS-2635 discovery facets with configurable ordering by jonas-atmire
[16:18] <tdonohue> This was one that almost made it into 5.4, but it changed facet names, so we delayed it. It seems pretty much ready though, and fixes an annoyance described in DS-2635
[16:18] <kompewter> [ https://jira.duraspace.org/browse/DS-2635 ] - [DS-2635] "View More" links for discovery facets should sort by occurrence, not alphabetical - DuraSpace JIRA
[16:18] <helix84> is that configurable?
[16:18] <mhwood> So it appears that this one is liked, and in good shape, but needs testers and votes?
[16:18] <tdonohue> correct, needs testers/votes
[16:19] <helix84> also needs docs if it's configurable (I think it should be)
[16:19] <tdonohue> good point on needing docs
[16:20] <tdonohue> I added a comment on needing docs
[16:20] <tdonohue> Any volunteer to give this an initial test?
[16:21] <tdonohue> no volunteers. Ok, we'll leave this one for now. It seems like it should be quick to test for anyone with extra time
[16:22] <tdonohue> next up, DSPR#1010
[16:22] <kompewter> [ https://github.com/DSpace/DSpace/pull/1010 ] - DS-2696-showJSP-catch-all-exceptions by akinom
[16:22] <tdonohue> This is a tiny change related to DS-2696
[16:22] <kompewter> [ https://jira.duraspace.org/browse/DS-2696 ] - [DS-2696] JSPUI sometimes fails to report error stack on exception - DuraSpace JIRA
[16:23] <tdonohue> Any JSPUI users here want to take a quick look at this. It looks fine to me, assuming I'm not misunderstanding the bug report
[16:23] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[16:23] <mhwood> It looks sensible, but not a JSPUI user.
[16:24] <mhwood> And returning a blank page is Not Nice.
[16:24] <tdonohue> I cannot imagine it'd caused issues, but I'd prefer someone more knowledgeable with JSPUI to actually merge it. I'll add my +1 via code review though
[16:25] <helix84> tdonohue: I'm looking at the auth docs now and all the properties in the docs are unprefixed. Should I change all of those to prefixed?
[16:26] <tdonohue> helix84: sure, if you have the time. I'm still getting back to updating all the Configuration docs for 6.0. It's a massive number of changes, and I've not been able to get them all done at once
[16:26] <mhwood> Oops, yes.
[16:26] <tdonohue> (Slowly but surely, I am updating 6.0 Config docs though..it's just a ton of work)
[16:27] * terry-b (~chrome@71-35-109-90.tukw.qwest.net) Quit (Ping timeout: 260 seconds)
[16:28] <tdonohue> ok, moving along.. I'm going to reschedule DSPR#974 (no activity since Dec and a merge conflict)
[16:28] <kompewter> [ https://github.com/DSpace/DSpace/pull/974 ] - DS-2630: New autocomplete options and enhancements by amarisi
[16:28] <tdonohue> next up, DSPR#962
[16:28] <kompewter> [ https://github.com/DSpace/DSpace/pull/962 ] - DS-2608: Improve collections and communities metadata in discovery results by nicolasschwab
[16:29] <tdonohue> relates to DS-2608
[16:29] <kompewter> [ https://jira.duraspace.org/browse/DS-2608 ] - [DS-2608] Improve collections and communities metadata in discovery results - DuraSpace JIRA
[16:29] * terry-b (~chrome@71-35-109-90.tukw.qwest.net) has joined #duraspace
[16:30] <tdonohue> It is essentially a code refactor, so that all objects are treated equally with Discovery. Previously, Communities/Collections only returned limited metadata from Discovery
[16:31] <tdonohue> The code itself looks reasonable to me. But, this definitely needs a test, as it is a refactor
[16:32] <tdonohue> This is also XMLUI specific.. I just changed the title to note that
[16:32] <mhwood> Sounds like unfinished business from Metadata for All. These objects used to have a fixed set of metadata; now they don't.
[16:32] <tdonohue> yep
[16:32] * hpottinger is jotting down notes furiously, so far 1118, 1010 and 962 have been added to the list
[16:33] <tdonohue> I added my support to this in a comment. It really just needs a tester
[16:33] <tdonohue> moving along for now (hoping to get through all these improvement PRs today, if we can): DSPR#931
[16:33] <kompewter> [ https://github.com/DSpace/DSpace/pull/931 ] - DS-2552: Makes configurable whether handles or DOIs should be displayed by pnbecker
[16:34] <tdonohue> whoops typo on my part
[16:34] <hpottinger> we have plans to use collection/community metadata some day, so, I'll take 962
[16:34] <tdonohue> I meant DSPR#934
[16:34] <kompewter> [ https://github.com/DSpace/DSpace/pull/934 ] - DS 2557 xmlui curation ux by aschweer
[16:34] <tdonohue> thanks hpottinger. Please assign it to yourself
[16:35] <tdonohue> 934 is mainly about user experience enhancements... see DS-2557 for screenshots. It mainly just needs a tester
[16:35] <kompewter> [ https://jira.duraspace.org/browse/DS-2557 ] - [DS-2557] Curation task admin UI should complain when no handle is given - DuraSpace JIRA
[16:35] <helix84> +1 to the ideas. not sure if i'll get to testing it.
[16:36] <hpottinger> re 934, I *think* that we ended up getting pieces of this earlier, I remember having to add missing key/value pairs to messages.xml
[16:36] <hpottinger> but, I'll add 934 to my list
[16:36] <tdonohue> thanks hpottinger
[16:37] <tdonohue> next up, DSPR#931
[16:37] <kompewter> [ https://github.com/DSpace/DSpace/pull/931 ] - DS-2552: Makes configurable whether handles or DOIs should be displayed by pnbecker
[16:38] <tdonohue> this is JSPUI specific. Seems like a reasonable change here though
[16:39] <tdonohue> looks like pbecker had to drop out of the meeting here though. My guess here is that we're just looking for JSPUI testers
[16:39] <mhwood> Yes, it's had a good deal of review already.
[16:40] <mhwood> This is probably one of those things that XMLUI would handle by hacking the templates.
[16:40] <hpottinger> we're always looking for JSPUI testers :-)
[16:41] <tdonohue> I added a +1 via code review
[16:41] <tdonohue> next up, DSPR#919
[16:42] <kompewter> [ https://github.com/DSpace/DSpace/pull/919 ] - DS-2547: Adds a label to access restricted bitstreams in JSPUI. by pnbecker
[16:42] <tdonohue> this looks to have been tested & given a +1 by helix84
[16:42] <helix84> yep
[16:43] <helix84> tdonohue: I just noticed in authentication-ip.cfg you changed ip.GROUPNAME -> authentication-ip.GROUPNAME. I assume the correct key is authentication-ip.ip.GROUPNAME, right? (same for ip.MY_UNIVERSITY)
[16:43] <tdonohue> This seems OK to me as well (scanning code)
[16:44] <tdonohue> helix84: it depends on how it's being read from the IPAuthentication class...it's possible I updated the calls there (I don't recall offhand)
[16:44] <helix84> tdonohue: ok, I'll check
[16:44] <hpottinger> so... 931- I think if pnbecker likes it and KevinVdV likes it... and tdonoue gives it a +1.... it's ready?
[16:45] <mhwood> dspace.cfg comment needs some language touch-up.
[16:45] <tdonohue> helix84: looks like I updated IPAuthentication was updated to use "authentication-ip" for everything: https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/authenticate/IPAuthentication.java#L88
[16:45] <kompewter> [ DSpace/IPAuthentication.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/authenticate/IPAuthentication.java#L88
[16:46] <tdonohue> 919 looks like it's "ready to go" to me, if you are also satisfied helix84
[16:46] <helix84> yes to 919
[16:47] <tdonohue> in essence of time, I'm moving along... Skipping 896, as it still has a merge conflict (and I know pbecker knows this)
[16:47] <tdonohue> DSPR#885
[16:47] <kompewter> [ https://github.com/DSpace/DSpace/pull/885 ] - DS-1349: Add configuration to hide submitter in item history (JSPUI). by pnbecker
[16:49] <tdonohue> This seems reasonable. It's a general issue though, and this only fixes the JSPUI side
[16:50] <tdonohue> again, probably just needs a tester
[16:50] <helix84> yes, with regard to 'common business layer' it should be addressed lower in the stack
[16:53] <tdonohue> that is true, this is something that could (potentially) be addressed lower in the stack, and not even *made available* to UIs when disabled. But, that may be more significant work
[16:54] <mhwood> +1 to all that.
[16:55] <tdonohue> It has the "feel" of something like "hiding metadata" across all interfaces. This is similar, hiding it just from the JSPUI (and not XMLUI or REST, etc) is not the best solution here
[16:55] <mhwood> I've now looked it over, and the only thing I could find was picky stuff about using Boolean.TRUE instead of new Boolean(true).
[16:57] <tdonohue> I summarized this in a comment on the PR
[16:57] <tdonohue> next up, DSPR#879
[16:58] <kompewter> [ https://github.com/DSpace/DSpace/pull/879 ] - DS-2490: adds org.dspace.identifier.VersionedDOIIdentifierProvider by pnbecker
[16:58] * PhilipV (~philip@85.234.195.109.static.edpnet.net) Quit (Quit: PhilipV)
[16:59] <tdonohue> This seems to be an important one: "also contains important bugfixes to make DOIs working again after the introduction of the Service Level API."
[17:00] <tdonohue> KevinVdV looks to have reviewed and his comments were addressed
[17:01] <tdonohue> Anyone here willing to give this a test run? The code is looking reasonable (still reading it though). But, it needs a tester
[17:02] <helix84> mhwood or pbecker might be interested
[17:02] <tdonohue> pbecker wrote it ;)
[17:03] <tdonohue> but, in general, this looks good to me, and it sounds like we need to get this into master soonish (to fix problems with DOIs in general, and make them compatible with Item Versioning)
[17:03] <helix84> ignore me, I'm half asleep already :/
[17:03] <mhwood> mwood is trying to figure out if he can test it, since we're using EZID.
[17:04] <tdonohue> well, in any case, this looks to pass code review. Hopefully we can find someone to give it a quick run through
[17:04] <tdonohue> The final PR in our list has a merge conflict & no recent activity: DSPR#879 ... I'd lean towards rescheduling this
[17:05] <kompewter> [ https://github.com/DSpace/DSpace/pull/879 ] - DS-2490: adds org.dspace.identifier.VersionedDOIIdentifierProvider by pnbecker
[17:05] <tdonohue> I mean DSPR#810 (man, I cannot type today)
[17:05] <kompewter> [ https://github.com/DSpace/DSpace/pull/810 ] - DS-2381 sitemap generator skip unreadable items by akinom
[17:05] <tdonohue> (obviously 879 was the one we already discussed above)
[17:05] <tdonohue> Any objections to rescheduling/descheduling 810?
[17:06] <mhwood> None here.
[17:06] <tdonohue> descheduled. It's inactive and broken right now
[17:07] <mhwood> Another place where access decisions should be pushed down. The sitemap generator should not even see objects that should not be exposed.
[17:07] <mhwood> Essentially it is a not-logged-in user, a member of Anonymous.
[17:08] <tdonohue> Ok, that's the full list of improvement PRs. Obviously there's a few in there that still need testers. So, if anyone of you have extra time later this week or early next, please grab a PR or two to test! We seem to be getting closer to an RC1...it's just these improvement PRs, and cutting down on major bugs (Blockers) which we didn't get to reviewing today
[17:10] <hpottinger> I have no extra time, but I do have an aspirational list of stuff to test :-)
[17:10] <tdonohue> I'm also going to spend more time this week cleaning up DSPR#1251, as it will resolve at least 1-2 of those blockers... Will let you know when it is ready again for testing
[17:10] <kompewter> [ https://github.com/DSpace/DSpace/pull/1251 ] - DS-2188 : Remove remaining artifacts/configs of DBMS Browse system by tdonohue
[17:10] <tdonohue> Thanks all!
[17:10] <hpottinger> top on my list of things to do, however, is to watch the prototype videos
[17:12] <tdonohue> yes, PLEASE do try to also find time to review the prototypes / watch the videos (or first 30mins). We need your input on the UI decision as well. I'll touch base with Committers on setting up some discussion calls (phone calls) with you all to talk through your feedback/comments on various proposals.
[17:13] <tdonohue> Non-Committers are also *more than welcome* to add notes/thoughts/feedback to the Evaluation Form (and Committers should add your written thoughts there as well): https://docs.google.com/spreadsheets/d/1XWxEERh0UXCOo7LhocMMaqbY2u4b6oI11oWOjSp_aSQ/edit
[17:13] <kompewter> [ DSpace UI Prototype Evaluation Form - Google Sheets ] - https://docs.google.com/spreadsheets/d/1XWxEERh0UXCOo7LhocMMaqbY2u4b6oI11oWOjSp_aSQ/edit
[17:15] <tdonohue> With that, we'll close things up for today. I'll be around though, if anyone has things to discuss on #dspace
[18:01] * th5 (~th5@unaffiliated/th5) Quit (Ping timeout: 256 seconds)
[18:16] * rivaldi8 (~alexm@gardeny.udl.cat) Quit (Quit: rivaldi8)
[18:28] * th5 (~th5@unaffiliated/th5) has joined #duraspace
[21:42] * helix84_ (~ctenar@unaffiliated/helix84) has joined #duraspace
[21:48] * helix84 (~ctenar@unaffiliated/helix84) Quit (*.net *.split)
[22:15] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[22:15] * terry-b3 (~chrome@71-35-109-90.tukw.qwest.net) has joined #duraspace
[22:21] * th5 (~th5@unaffiliated/th5) Quit (Quit: Textual IRC Client: www.textualapp.com)
[22:22] * terry-b (~chrome@71-35-109-90.tukw.qwest.net) Quit (Ping timeout: 240 seconds)
[22:39] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:41] * hpottinger (~hpottinge@mu-162038.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[23:49] * 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.