Timestamps are in GMT/BST.
[6:40] -sendak.freenode.net- *** Looking up your hostname...
[6:40] -sendak.freenode.net- *** Checking Ident
[6:40] -sendak.freenode.net- *** Found your hostname
[6:40] -sendak.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
[7:08] * kshepherd (~kim@118.148.70.164) Quit (Ping timeout: 248 seconds)
[7:10] * kshepherd (~kim@118.148.70.164) has joined #duraspace
[7:33] * kshepherd (~kim@118.148.70.164) Quit (Ping timeout: 260 seconds)
[7:35] * kshepherd (~kim@118.148.70.164) has joined #duraspace
[8:13] * kshepherd (~kim@118.148.70.164) Quit (Ping timeout: 276 seconds)
[8:14] * kshepherd (~kim@118.148.70.164) has joined #duraspace
[9:03] * kshepherd (~kim@118.148.70.164) Quit (Ping timeout: 276 seconds)
[9:04] * kshepherd (~kim@118.148.70.164) has joined #duraspace
[11:28] * kshepherd (~kim@118.148.70.164) Quit (Ping timeout: 244 seconds)
[12:35] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:59] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) has joined #duraspace
[13:24] * hpottinger (~hpottinge@mu-161168.dhcp.missouri.edu) has joined #duraspace
[14:32] * th5 (~Adium@unaffiliated/th5) has joined #duraspace
[14:45] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[16:40] * peterdietz (uid52203@gateway/web/irccloud.com/x-sylczfunkifsyigi) has joined #duraspace
[16:53] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) Quit (Quit: Leaving.)
[16:54] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[18:40] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) Quit (Ping timeout: 268 seconds)
[18:41] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) has joined #duraspace
[20:01] <tdonohue> Hello all, welcome! It's time for our weekly DSpace DevMtg : https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-03-30
[20:01] <kompewter> [ DevMtg 2016-03-30 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-03-30
[20:02] <tdonohue> Before we dive into the main topic of 6.0, I did want to briefly note that the next "phase" of the DSpace UI Prototyping has started. As mentioned last week, we are building a collaborative "extended prototype" on Angular 2
[20:02] <tdonohue> That work is going on at https://github.com/DSpace-Labs/angular2-ui-prototype
[20:02] <kompewter> [ GitHub - DSpace-Labs/angular2-ui-prototype: An Angular2 (https://angular.io/) extended prototype UI for DSpace ] - https://github.com/DSpace-Labs/angular2-ui-prototype
[20:03] <tdonohue> Everyone is more than welcome to watch or take part (as much or as little as you want). Much more info in the README of that project.
[20:04] <tdonohue> I don't want to spend any major time on this today (as there is lots more to do), but I wanted to be sure everyone is aware of it (including folks reading these notes later). If you have questions, please ask (either via email, or via GitHub Issues in that project)
[20:04] <tdonohue> moving along... 6.0 topics
[20:05] <tdonohue> Today, if possible, it'd be nice to start to draft up our upcoming 6.0 schedule. We are zeroing in on an RC1 (which means a Testathon). But, we need to announce a Testathon in advance (so folks actually show up and help!)
[20:06] <tdonohue> As of today, we only have 1 outstanding feature, and 2 outstanding "blocker" bugs (one of which we've elected to delay already until RC2)
[20:07] <tdonohue> So, I'd like to talk through those a bit first...and hopefully leave the last 10 mins to talk upcoming schedule (based on the status of those tickets/PRs)
[20:08] <tdonohue> First, the outstanding feature... DSPR#1162. I'm wondering if others have opinions here on how to move this forward? The team working on this has been responsive (and I thank them), but the feature itself still fails basic tests, and we've been working with them for 3 months now on getting this in.
[20: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
[20:10] <tdonohue> As you can see in the latest comments, the feature is still not working right (I tested yesterday). KevinVdV (who won't make it today) did help get a quick fix, but it fails to compile (maven enforcement issues)
[20:10] <mhwood> It just feels as though it is not ready.
[20:11] <tdonohue> Elsevier has also been responsive, but their API keys don't seem to fully work (and throw some vague errors during the upload step, but work to pull down metadata)
[20:13] <tdonohue> mhwood: yes, that's my worry here too. But, I did want to get other's opinions
[20:14] <mhwood> Is anybody else here?
[20:14] <tdonohue> I will note that Lieven from @mire did email me today saying they are trying to work this out with Elsevier. But, I responded telling him I cannot promise this will make it into 6.0 anymore, as it's now the "last minute" and the PR still fails basic verification tests
[20:14] <mhwood> That seems reasonable.
[20:15] <mhwood> I wouldn't like to miss 6.0 with this, but who knows how long it is going to take?
[20:15] <tdonohue> anyone else around? helix84, hpottinger, peterdietz, terry-b (or other non-Committers too)
[20:15] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[20:15] <peterdietz> hey
[20:15] <mhwood> DSPR#1162
[20:15] <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:16] <tdonohue> kshepherd (welcome) and peterdietz. We are talking about what to do about #1162. Do you have thoughts/opinions to share (see the discussion so far in the logs)?
[20:18] <peterdietz> It looks like at the moment, this PR doesn't do what we want it to do...
[20:19] <terry-b> I am back from a meeting
[20:19] <tdonohue> well, it definitely doesn't do what it says it will do. It *mostly* works, to be accurate. But the upload step is the (current) major point of failure (it throws errors in logs and fails to access restrict anything when you ask it to)
[20:21] <tdonohue> In any case, I really just want to gage the opinion on 1162 and whether we (a) include it in 6.0, (b) wait a little longer until all blockers are fixed...then decide if it's ready, (c) say, sorry it's too late now
[20:22] <tdonohue> I'm very hesitant on (a). I can see the arguments for (b) or (c)...but the longer we wait, the more I start to worry about sticking something in at the "last moment"
[20:22] <mhwood> It sounds like significant breakage. I'm afraid we ought to choose not to let it affect our scheduling. If it is fixed in time, then that's great! Otherwise it will have to wait. So, I guess that's (b).
[20:23] <tdonohue> I'm with you on not letting it affect our scheduling.
[20:24] <mhwood> I wonder how hard it would be to package as a drop-in. I haven't looked at it thoroughly. If it does miss integration in 6.0, it could be distributed separately and integrated in 7.0.
[20:25] <tdonohue> it could be dropped in, but it involves a lot of parts (including a new "elsevier" metadata schema, an XMLUI aspect, a few new Item submission steps, etc)
[20:25] <tdonohue> But, nothing new in the DB layer
[20:25] <mhwood> Drop-in is what I like most about the aspect chain.
[20:26] <tdonohue> Since others are mostly quiet here, I guess we'll default to (b) for now (I hate to spend the whole meeting on 1162). Which brings us to the fact that we only have one blocker left before RC1 (as our other blocker is scheduled for RC2)
[20:27] <tdonohue> Blockers: https://jira.duraspace.org/issues/?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
[20:27] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/issues/?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
[20:27] <mhwood> Anyway, there is another route forward for the feature if it misses 6.0. I can talk about drop-in-izing of features if they want to do that, at least until the next major release.
[20:27] <tdonohue> mhwood: true
[20:27] <tdonohue> here's our last "blocker" before an RC1... DS-2940 / DSPR#881
[20:27] <kompewter> [ https://jira.duraspace.org/browse/DS-2940 ] - [DS-2940] Metadata problems with the VersionedHandleIdentifierProvider - DuraSpace JIRA
[20:27] <kompewter> [ https://github.com/DSpace/DSpace/pull/881 ] - DS-3109: Introduce a VersionedHandleIdentifierProvider that creates new handles for each version by pnbecker
[20:28] <tdonohue> This is that "blocker" which is part bug fix (the blocker part) and part enhancement
[20:29] <terry-b> Would you consider https://jira.duraspace.org/browse/DS-3108 to be a blocker?
[20:29] <kompewter> [ https://jira.duraspace.org/browse/DS-3108 ] - [DS-3108] Support Shibboleth Authentication in the REST API - DuraSpace JIRA
[20:29] <kompewter> [ [DS-3108] Support Shibboleth Authentication in the REST API - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3108
[20:29] <terry-b> I did not think to tag it when I created the issue
[20:30] <tdonohue> terry-b: A blocker is usually something that flat out doesn't work or causes major failures in DSpace. I don't think 3108 would qualify. Ideally we fix it for 6.0, but if we have to document that REST + Shib doesn't work, it's something we could "live with" and fix in a 6.1 or similar
[20:31] <terry-b> OK. It will become really important as the new UI work proceeds. Hopefully the architecture to support the new UI will make authentication easier
[20:32] <tdonohue> terry-b: I agree. we want to support it. I just don't think it "blocks" a 6.0 release. We could wait a bit longer and fix it in 6.1 or 6.2 or 7.0. (Ideally though we do find a way to solve it in 6.0 if we can)
[20:33] <terry-b> I would find it helpful to know if others see the same errors that I see when I attempt to authenticate.
[20:34] <tdonohue> terry-b: yes, hopefully we can find someone to help (even during testathon as needed)
[20:35] <tdonohue> So, back to DSPR#881...looks like KevinVdV tested it, and it has a minor issue. Unfortunately pbecker is away (until next week I believe?). I wonder if anyone else here has experience with 881, or wants to dig in and see if we can clean it up?
[20:35] <kompewter> [ https://github.com/DSpace/DSpace/pull/881 ] - DS-3109: Introduce a VersionedHandleIdentifierProvider that creates new handles for each version by pnbecker
[20:36] <tdonohue> mhwood: I just realized, doesn't this 881 overlap with your DSPR#1008? It looks like 881 still hardcodes the metadata field used into various sub-classes
[20:36] <kompewter> [ https://github.com/DSpace/DSpace/pull/1008 ] - DS-2408: Fix ordering of listeners in web.xml to ensure Kernel always starts before DB migrations happen by tdonohue
[20:37] <mhwood> I think I had to do something with that, when rebasing today.
[20:37] <tdonohue> whoops, I meant DSPR#1006 is related (not 1008)
[20:37] <kompewter> [ https://github.com/DSpace/DSpace/pull/1006 ] - [DS-2199] DSpace stores DOIs in different metadata values depending on which DOI registration agency is used by mwoodiupui
[20:39] <tdonohue> mhwood: I was actually noting the new code hardcodes it...so, there may be (minor) conflicts between 1006 and 881
[20:39] <mhwood> I'm looking for them.
[20:39] <tdonohue> like here, where "identifier" and "uri" are harcoded again (instead of constants): https://github.com/DSpace/DSpace/pull/881/files#diff-68519f443be911806eecffa87bad9292R514
[20:39] <kompewter> [ DS-3109: Introduce a VersionedHandleIdentifierProvider that creates new handles for each version by pnbecker · Pull Request #881 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/881/files#diff-68519f443be911806eecffa87bad9292R514
[20:39] <tdonohue> it's not a merge conflict, but it "undoes" some of what you are trying to achieve in 1006
[20:40] <mhwood> True. I'll look it over for these and comment.
[20:41] <tdonohue> it may imply either 1006 should go in first (and updates to 881)... or visa versa
[20:42] <mhwood> I don't think they are order-dependent. Nothing breaks either way.
[20:42] <tdonohue> Anyone want to volunteer to help test / debug 881 (pbecker's PR), especially since pbecker is out of the office for a while?
[20:43] <tdonohue> mhwood: right, true. It doesn't break...but pbecker cannot refactor his PR to use your changes unless 1006 is accepted first.
[20:44] <mhwood> OK
[20:45] <mhwood> He *could* use the old duplicated values from, say, DataciteDOIProvider, which ought to collide with 1006 and then I can fix them up.
[20:46] <mhwood> That already happened with VersionedDOIIdentifierProvider or some such.
[20:46] <mhwood> Don't rely on those names' exact spelling. :-)
[20:46] <tdonohue> right, that was my point though. We may want to coordinate these PRs getting in. Or just merge yours and ask pbecker (or whomever) to refactor his to use the new constants
[20:47] <tdonohue> In any case, 881 needs more testers and someone to take over while pbecker is out of the office.
[20:47] <tdonohue> I'll see if I can find time to dig into 881 tomorrow or Fri, but I'd appreciate help from anyone else who can find time
[20:47] * tdonohue gets the feeling that only mhwood & I are in this meeting though
[20:47] <mhwood> I have a note to at least mark all of the dc.identifier.uri instances I can find in that one.
[20:49] <tdonohue> sounds good.
[20:50] <kshepherd> hi all
[20:50] <terry-b> tdonohue, I am sorry that I do not have the bandwidth or expertise to help on this one
[20:50] <kshepherd> tdonohue: sorry, missed the discussion on 1162, my laptop was just being flakey and reconnecting. i will catch up today and come back
[20:51] <tdonohue> So, regarding 6.0 schedule. I really really want to get RC1 ready to go, and Testathon announced. But, I could use help from all of you in trying to close out tickets (many just need basic testing / verification)
[20:52] <tdonohue> Again, we stand at 1 outstanding feature (Elsevier import), 1 blocker to RC1 (881 mentioned above), 8 improvement PRs outstanding, 10 code tasks.... several of the improvements / code tasks are flagged as "quick win" (in GitHub), which means they should be easy to review & test
[20:53] <mhwood> I just put a repeating item on my calendar, "DSpace 6 tickets", which doesn't expire until I delete it. :-)
[20:53] <tdonohue> (and we have a total of ~30 "quick win" PRs right now. So, if anyone has even an extra 30 mins or so, grab one, try it out and merge it if it works
[20:55] <tdonohue> I'm not sure there's enough of us here to make a decision on 6.0 schedule. But, ideally we get this last blocker done before our next mtg, and get many of the "quick wins" merged by then too
[20:56] <tdonohue> I'm thinking I may put a "call" out to the -commit and/or -devel for help with testing PRs. There's a lot of them, but most are actually quite small and just need some testers to add +1
[20:56] <kshepherd> i've made a calendar note to remind me tonight, i'll hopefully have time over today and tomorrow, but only in evenings
[20:57] <mhwood> IIRC there are a couple of bug PRs that went +2 today.
[20:57] <tdonohue> thanks mhwood and kshepherd. Any help you can provide is appreciated
[20:57] <hpottinger> I will pitch in when I can
[20:58] <tdonohue> mhwood: in that case, we should go merge them. I've been having trouble keeping up (and my eyes started to glaze after I personally reviewed all 140+ PRs today and closed many obsolete ones) ;)
[20:58] <mhwood> DS-2999 is merged.
[20:58] <kompewter> [ https://jira.duraspace.org/browse/DS-2999 ] - [DS-2999] Improve REST collection report to incrementally filter collections with many items - DuraSpace JIRA
[20:59] <tdonohue> Ok, so as we are nearing the end of this meeting, I don't think I'll bring up any more topics for today.
[20:59] <tdonohue> However, I do welcome *anyone* (even non-Committers) to help us test some PRs! We'd love to get as much into 6.0 as possible!
[21:00] <tdonohue> Also, I welcome feedback on DSPR#1162 as well (our last outstanding feature)... especially if you feel strongly about whether we include it in 6.0 or not
[21:00] <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
[21:01] <mhwood> DS-2616 is merged.
[21:01] <kompewter> [ https://jira.duraspace.org/browse/DS-2616 ] - [DS-2616] oai_dc crosswalk does not export format of bitstreams - DuraSpace JIRA
[21:01] <tdonohue> With that though, we'll go ahead and close out today's meeting
[21:01] <tdonohue> thanks mhwood for your merging! :)
[21:04] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:17] * th5 (~Adium@unaffiliated/th5) Quit (Quit: Leaving.)
[21:20] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) has left #duraspace
[21:22] <hpottinger> DSPR#976 looks *really* tiny
[21:22] <kompewter> [ https://github.com/DSpace/DSpace/pull/976 ] - DS-2520: Modify XPath expression when retrieving a workflow step by FacundoAdorno
[21:37] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 276 seconds)
[21:42] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[21:53] * hpottinger (~hpottinge@mu-161168.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[22:05] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 244 seconds)
[22:16] * kshepherd (~kim@wireless-nat-21.auckland.ac.nz) has joined #duraspace
[23:16] * kshepherd (~kim@wireless-nat-21.auckland.ac.nz) Quit (Ping timeout: 244 seconds)
[23:21] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[23:26] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 268 seconds)
[23:26] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[23:31] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 252 seconds)
[23:32] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[23:36] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 244 seconds)
[23:37] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[23:42] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 248 seconds)
[23:43] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[23:48] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 244 seconds)
[23:49] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[23:54] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 240 seconds)
[23:54] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[23:59] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 252 seconds)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.