Timestamps are in GMT/BST.
[1:56] * kdweeks (~Adium@75-139-93-137.dhcp.spbg.sc.charter.com) Quit (Quit: Leaving.)
[1:58] * kdweeks (~Adium@75-139-93-137.dhcp.spbg.sc.charter.com) has joined #duraspace
[2:02] * kdweeks (~Adium@75-139-93-137.dhcp.spbg.sc.charter.com) Quit (Client Quit)
[2:24] * kdweeks (~Adium@75-139-93-137.dhcp.spbg.sc.charter.com) has joined #duraspace
[4:11] * kdweeks (~Adium@75-139-93-137.dhcp.spbg.sc.charter.com) has left #duraspace
[6:41] -adams.freenode.net- *** Looking up your hostname...
[6:41] -adams.freenode.net- *** Checking Ident
[6:41] -adams.freenode.net- *** Found your hostname
[6:41] -adams.freenode.net- *** No Ident response
[6:41] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:41] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:41] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[13:09] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:05] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[14:59] * hpottinger (~hpottinge@162.104.218.179) has joined #duraspace
[15:00] <tdonohue> All, reminder that our DevMtg starts now-ish. Rough agenda at https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-11-30
[15:00] <kompewter> [ DevMtg 2016-11-30 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-11-30
[15:01] <tdonohue> Good morning (or afternoon) all. The agenda for today is above. Pinging our Committers here (helix84, hpottinger, mhwood)
[15:01] <tdonohue> We are a small group it seems...so a few quick announcements/reminders before we get started today
[15:02] <tdonohue> First, if you don't have your OR2017 proposals in yet, get them in ASAP. The deadline is end of day today!
[15:03] <tdonohue> (As a sidenote, I've submitted a proposal on DSpace 7 work along with Art & Andrea B... and I've decided not to do the DCAT/DevMtg as a Workshop. We'll find another way to try and meet up informally there)
[15:03] <hpottinger> Oh, cool, I was worried about that
[15:04] <tdonohue> A further clarification... I feel the DCAT/DevMtg is just getting in the way of us doing other workshops, and it sounds like others wanted to submit other types of workshops...so, we need to find a better way to do this meetup informally
[15:05] <tdonohue> (Plus the content in that meeting was often repetitive of other talks)
[15:06] <tdonohue> One other reminder/note... the next DSpace 7 UI Working Group meeting is tomorrow (Dec 1) at 15UTC (for Angular2) and 16UTC (for REST API) respectively. It will be in the usual Google Hangout (contact art.lowel at atmire.com if you need an invite)
[15:06] <hpottinger> just curious: ping helix84, mhwood
[15:06] <mhwood> pong
[15:07] <hpottinger> after we cover the agenda, I vote we go straight to backlog
[15:08] <tdonohue> Just curious... any other last minute OR17 proposals you all are working on (I realize we are just 3 here though). I should also mention, there's going to be another "Repo Rodeo" (updates from all projects), and I'll represent DSpace again on that panel
[15:09] <tdonohue> sounds like not. no problems
[15:09] <hpottinger> Kim Shepherd is working on a How to contribute presentation, Art and I are pitching in
[15:10] <tdonohue> awesome! glad to hear that idea is moving forward
[15:11] <tdonohue> ok, moving along to agenda topics... we have our running list of DSpace 6 issues to review...then I agree, we should jump into "backlog". I won't be available for backlog hour, but I can take part for the full hour that is this meeting
[15:12] <tdonohue> Regarding 6.0 tickets.. this one just came in this morning (not yet on our list on the agenda): DS-3406
[15:12] <kompewter> [ https://jira.duraspace.org/browse/DS-3406 ] - [DS-3406] Sub-communities and collections not sorted alphabetically - DuraSpace JIRA
[15:12] <tdonohue> This sounds like a major, unexpected change in behavior
[15:13] <mhwood> Reported by multiple sites, too.
[15:14] <tdonohue> my guess is the updated API refactor may have a bug in the query (e.g. no sort by)
[15:14] <hpottinger> sounds like a discovery snafu?
[15:14] <tdonohue> Anyone have time to investigate this?
[15:15] <hpottinger> I can
[15:15] <tdonohue> hpottinger: I don't think this list of sub-communities/collections comes from Discovery. IIRC, it's a database query
[15:15] <tdonohue> thanks, hpottinger!
[15:16] * dyelar (~dyelar@129.237.45.105) has joined #duraspace
[15:16] <tdonohue> moving along to the next one on our agenda list... DS-3367
[15:16] <kompewter> [ https://jira.duraspace.org/browse/DS-3367 ] - [DS-3367] Configurable Workflow authorization denied error - DuraSpace JIRA
[15:17] <tdonohue> needs a volunteer still...verified by several folks, but the bug needs tracking down
[15:18] <mhwood> I'll put it on my list. I need to learn more about configurable workflow anyway.
[15:18] <tdonohue> huh, I just remembered I saw another ticket like this one recently... here it is DS-2920 (updated today)
[15:18] <kompewter> [ https://jira.duraspace.org/browse/DS-2920 ] - [DS-2920] AuthorizeException on "take task" during workflow process - DuraSpace JIRA
[15:19] <tdonohue> 2920 was reported in 5.x with *traditional* workflow. 3367 was reported on 5.x and 6.0 with *configurable* workflow
[15:19] <tdonohue> but, the errors sound very similar
[15:20] <mhwood> Link them?
[15:20] <tdonohue> yep, doing that as we type already
[15:22] <tdonohue> done. Added a comment to 3367 to note that 2920 has more info on a possible workaround too
[15:23] <tdonohue> and I see mhwood claimed 3367. Thanks!
[15:23] <tdonohue> moving along to next in our list... DS-3381
[15:23] <kompewter> [ https://jira.duraspace.org/browse/DS-3381 ] - [DS-3381] Blocking error trying the versioning system - DuraSpace JIRA
[15:24] <tdonohue> needs volunteer. We asked for more info on the errors in JSPUI, but this sounds like something anyone should be able to replicate (after turning on versioning)
[15:25] <tdonohue> if anyone wants this, please claim it. Otherwise, I'll flag as "needs volunteer" but leave it on our agenda shortlist
[15:25] <mhwood> Assigned to hpottinger.
[15:26] <hpottinger> wait, wut?
[15:26] <tdonohue> 3381 is not assigned to anyone :)
[15:26] <mhwood> Sorry, wrong tab.
[15:26] <tdonohue> i'll flag as "needs volunteer" for now, and leave it on our list
[15:27] <tdonohue> done
[15:28] <tdonohue> last up is mostly just a reminder ticket... DS-3389
[15:28] <kompewter> [ https://jira.duraspace.org/browse/DS-3389 ] - [DS-3389] Replication Task Suite add-on doesn't work with DSpace 6 API - DuraSpace JIRA
[15:29] <tdonohue> If anyone has time to devote to updating this, please claim it. Otherwise, I'll likely get to it next year once we update DSpaceDirect to DSpace 6 (as that service uses ReplicationTaskSuite)
[15:29] <hpottinger> On my list, I think?
[15:29] <mhwood> This one *is* assigned. I'm not sure what Received/Assigned means...
[15:29] <hpottinger> yes, assigned to me
[15:29] <tdonohue> oh..yes, thanks hpottinger
[15:30] <tdonohue> in that case, we need to update status to "Accepted"
[15:30] <tdonohue> done
[15:30] <tdonohue> I missed the assignment and was just looking at the status
[15:30] <tdonohue> ok, that's it for our "shortlist" of DSpace 6 tickets. Anything else come in recently that needs attention (or to be added to this list)?
[15:31] <hpottinger> it would be nice if when we clicked "assign to me" the ticket would advance in the workflow
[15:31] <mhwood> I suppose that Received/Assigned means "someone gave this to me but I'm not working on it yet."
[15:31] <tdonohue> hpottinger: yes, it would be nice. Haven't figured out a way to make that happen automatically in JIRA yet though (I had looked into it a while back with no success, not sure if newer JIRA now supports it though)
[15:31] <hpottinger> I am not sure, but I think I've found an oddity with DS-2818
[15:32] <kompewter> [ https://jira.duraspace.org/browse/DS-2818 ] - [DS-2818] authentication fails after upgrade from 3.x to master (6.0) schema - DuraSpace JIRA
[15:32] <mhwood> IIRC that "ignored" migration is supposed to be ignored in some cases.
[15:32] <hpottinger> the flyway migration which "fixed" 2818 is showing up as status "ignored"
[15:33] <tdonohue> which migration is this? and what version are you upgrading from?
[15:33] <hpottinger> if "ignored" is an acceptible state, we probably need to tell that to the database validate script
[15:33] <mhwood> If you look at the migrated database, is it in the state that it would occupy were the ignored migration to have run?
[15:34] <hpottinger> mhwood: I haven't dug in today yet, I noticed it last night
[15:34] <hpottinger> | 4.9.2015.10.26 | DS-2818 registry update | | Ignored |
[15:34] <kompewter> [ https://jira.duraspace.org/browse/DS-2818 ] - [DS-2818] authentication fails after upgrade from 3.x to master (6.0) schema - DuraSpace JIRA
[15:34] <hpottinger> If I run dspace database validate it throws errors on that ignored migration
[15:34] <tdonohue> hpottinger: if you are upgrading from 5.x to 6.0 then that migration *will* always be ignored (as it is flagged as a "4.9" migration, which only runs for 4.x or below)
[15:35] <hpottinger> OK, so, the bug is in the validation script
[15:36] <tdonohue> The validation script literally just runs Flyway's "validate" command. It might throw errors on ignored migrations...not sure. If so, maybe we should see if there's a way to tell Flyway's "validate" that ignored migrations are "warnings" instead
[15:37] <tdonohue> Also, if it really bugs you locally, you could run "./dspace database migrate ignored" (which runs any old migrations flagged as ignored). In this scenario it won't hurt, as that old migration will be a noop. But, it's best to not generally run migrations "out of order" (which is what that does)
[15:39] <mhwood> IIRC what's going on here is that we needed a new migration for certain cases of 4.x->5.x, but this was dicovered *after* 5.something was released. 5.x fresh installs don't need it. So it was added to the 4-> path retroactively. Which means it won't run for any 5.n->5.n+m upgrades.
[15:40] <tdonohue> mhwood: that is 100% correct. That essentially boils down to.. when upgrading from 4.x or below, this migration will NOT be "ignored"... but when upgrading from 5.x or above, it *will* be ignored (as it is not necessary / is a noop)
[15:41] <tdonohue> so, the only real "issue" here is that the "validate" command seems to complain about this migration being ignored (and that complaint is misleading, as it is expected behavior to us)
[15:42] <tdonohue> So, this might either be a Documentation issue... or maybe there's some way to tell Flyway's "validate" command to not complain about "ignored" migrations (but I'm not seeing any after searching around a bit)
[15:42] <mhwood> Hmm. There may be cases where it really is a problem to have an ignored migration? If so, then what we need is "dspace database migrate --expert --ignored2finished NAME"
[15:43] <hpottinger> DS-3407
[15:43] <kompewter> [ https://jira.duraspace.org/browse/DS-3407 ] - [DS-3407] database validate script fails when it encounters an ignored FlyWay migration - DuraSpace JIRA
[15:45] <tdonohue> According to Flyway, if a migration is ignored, it *might* be a problem. But, base on how *DSpace* has built our migrations, we have some (rare) scenarios (like this one) where ignored migrations are unfortunately necessary to ensure a smooth upgrade from all past versions.
[15:45] <hpottinger> is there a better state than "ignored"?
[15:45] <tdonohue> I hope in the future these migrations are EXTREMELY rare (as this isn't good practice). But, DS-2818 was a scenario we didn't anticipate and forced us to backport a migration (which is subsequently ignored by 5.x or above)
[15:45] <kompewter> [ https://jira.duraspace.org/browse/DS-2818 ] - [DS-2818] authentication fails after upgrade from 3.x to master (6.0) schema - DuraSpace JIRA
[15:46] <tdonohue> hpottinger: there's no other states to my knowledge... there's only "ignored", "success" and "failed". Flyway controls the states. It only flags something success/failed if it runs, otherwise the default is "ignored"
[15:46] <mhwood> If you're satisfied that the migration can be permanently ignored, you *could* just poke the state in that record of the migrations table.
[15:47] <tdonohue> hpottinger: your new ticket has an empty code box at the beginning of the description. I think you meant to paste in the migration: DS-3407
[15:47] <kompewter> [ https://jira.duraspace.org/browse/DS-3407 ] - [DS-3407] database validate script fails when it encounters an ignored FlyWay migration - DuraSpace JIRA
[15:48] <tdonohue> In all honesty here... 2818 is the only scenario where an "ignored" migration is NOT some sort of issue in DSpace. Hopefully it's the only one EVER (in which case we document this as a known issue and tell folks to run "./dspace database migrate ignored" to correct it
[15:49] <hpottinger> mhwood: I think I'd prefer to tweak the dspace database migrate ignored script to do what you suggest: move from "ignored" to "succeed"
[15:49] <tdonohue> So, this was a very specific scenario...there was no way around this in fixing 2818...believe me, I dug into this at the time.
[15:49] <hpottinger> tdonohue: I fixed the empty code block, thanks for noticing it
[15:50] <tdonohue> not sure what that suggestion is... the "./dspace database migrate ignored" script *will* run this old migration (resulting in a noop) and *will* already move the status from "ignored" to "succeed"
[15:50] <tdonohue> So, we already have a script that does this.
[15:50] * luizsan (~luizsan@199.79.165.2) has joined #duraspace
[15:50] <hpottinger> orly?
[15:50] <hpottinger> sweet
[15:50] <hpottinger> yeah, "fix" this with docs
[15:51] <mhwood> Yeah, I forgot "migrate ignored". Better than lying to Flyway.
[15:52] <hpottinger> oh, that's lovely
[15:52] <tdonohue> The only reason we don't advertise "database migrate ignored" heavily is that it has the *potential* to be dangerous in other scenarios... as it runs *all* "ignored" migrations immediately. In the scenario of fixing 2818, this is exactly what we need to do. But, in other scenarios it is safer to simply run "database migrate"
[15:52] <hpottinger> [dspace@apg dspace]$ bin/dspace database validate
[15:52] <hpottinger> Database URL: jdbc:postgresql://localhost:5432/ds5
[15:52] <hpottinger> Attempting to validate database status (and migration checksums) via FlywayDB...
[15:52] <hpottinger> No errors thrown. Validation succeeded. (Check dspace logs for more details)
[15:53] <tdonohue> So, yes, I agree, we should fix this with Documentation
[15:53] <tdonohue> I just want to be sure the Documentation also warns folks to run "dspace database migrate" in all other scenarios (people shouldn't get in the habit of always running "dspace database migrate ignored")
[15:54] <mhwood> Document this option as "use this only when recommended by the maintainers."
[15:55] <tdonohue> yes, exactly
[15:55] <tdonohue> it's a very useful command to have.. but can have unforeseen side-effects if used too frequently
[15:56] <hpottinger> I've assigned DS-3407 to myself
[15:56] <kompewter> [ https://jira.duraspace.org/browse/DS-3407 ] - [DS-3407] database validate script fails when it encounters an ignored FlyWay migration - DuraSpace JIRA
[15:57] <mhwood> Before we break: any thoughts on DS-2707? There was concern about duplicative logging. The problem is that the code is peppered with System.out.X calls that don't work in webapp.s.
[15:57] <kompewter> [ https://jira.duraspace.org/browse/DS-2707 ] - [DS-2707] Poor messaging when batch upload directory cannot be created - DuraSpace JIRA
[15:58] <tdonohue> hpottinger: I added a clarifying comment to 3407...though I now see you did the same ;)
[15:59] <mhwood> The code has been repurposed, and now needs to support the servlet environment in addition to the command line (for which it was originally written). It's kind of a mess right now.
[16:01] <tdonohue> mhwood: yea, I understand that now with 2707. I do wonder if we rip out all the System.out calls, and just report to check the logs (when run from commandline)... that's what we do with other commands
[16:02] <mhwood> I can look at how to do that. Does that belong in 2707 or should it be a new ticket?
[16:02] <tdonohue> But, if that results in further complications, the duplication of logging is OK for now. We just should note why it's there
[16:03] <tdonohue> probably a new ticket, I guess. I don't mind the debug logs...it'd just be nice to clean up the logging here at some point
[16:04] <mhwood> OK, I can add a note to the code. Then 2707 just needs approval.
[16:05] <mhwood> Thanks for taking another look.
[16:05] <tdonohue> The code looked ok to me. I'm assuming it's been tested and seems to work fine? There's a lot of code changes/realignment here...while it looks good to me, I haven't run any tests
[16:06] <luizsan> Hi, I am sorry about this out of topic question, a couple of weeks I ago I volunteered myself to the XOAI update, so I have a question about the XOAI update, basically what I have to do is change it dependency in pom.xml and fix the errors, right?
[16:06] <mhwood> Yeah, there was a big chunk that was hard to read. I've put a couple of line comments in to show where the actual fix happens.
[16:08] <tdonohue> mhwood: approved it
[16:08] <mhwood> Thanks!
[16:09] <tdonohue> I unfortunately have to run here (wish I could stick around, but have a busy day ahead). So, I need to close up the meeting until next week. If others have time, please feel free to do some JIRA backlog review
[16:10] <mhwood> luizsan, that sounds correct. It's hard to say what "fix the errors" will require.
[16:11] <tdonohue> luizsan: Yes, in updating DSpace to use the latest XOAI, you'd need to update DSpace's POMs to use that new version, and then likely refactor/update the DSpace "oai" project to fix errors. The "fix errors" though is uncertain, as no one has dug deeply into how many errors there will/may be
[16:11] <tdonohue> jumping off now...will be lurking, but need to get a few other things done. bye
[16:11] <hpottinger> I added a section to "troubleshooting upgrade issues" here: https://wiki.duraspace.org/display/DSDOC6x/Upgrading+DSpace
[16:11] <kompewter> [ Upgrading DSpace - DSpace 6.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC6x/Upgrading+DSpace
[16:12] <mhwood> Thanks tdonohue.
[16:12] <hpottinger> DS-3407 closed as fixed
[16:12] <kompewter> [ https://jira.duraspace.org/browse/DS-3407 ] - [DS-3407] database validate script fails when it encounters an ignored FlyWay migration - DuraSpace JIRA
[16:12] <luizsan> Thank you guys, I will work on it.
[16:14] <mhwood> Thanks to you as well, luizsan.
[16:14] <mhwood> hpottinger: any way to say "don't do this unless we tell you to"?
[16:15] <mhwood> Otherwise this looks well. Thanks for adding it.
[16:18] <hpottinger> mhwood: it's a wiki ;-)
[16:23] <mhwood> Warning amplified.
[16:23] <mhwood> Moving over to #dspace.
[16:51] * isido (~sidoroff@dm2-hulib-1.hulib.helsinki.fi) has joined #duraspace
[16:54] * dyelar (~dyelar@129.237.45.105) Quit (Quit: Leaving.)
[17:01] * dyelar (~dyelar@129.237.108.10) has joined #duraspace
[17:29] * dyelar (~dyelar@129.237.108.10) Quit (Remote host closed the connection)
[17:38] * dyelar (~dyelar@129.237.45.105) has joined #duraspace
[18:07] * isido (~sidoroff@dm2-hulib-1.hulib.helsinki.fi) Quit (Quit: leaving)
[21:32] * dyelar (~dyelar@129.237.45.105) Quit (Quit: Leaving.)
[21:37] * dyelar (~dyelar@129.237.45.105) has joined #duraspace
[22:12] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[22:26] * luizsan_ (~luizsan@199.79.165.2) has joined #duraspace
[22:26] * luizsan (~luizsan@199.79.165.2) Quit (Remote host closed the connection)
[22:36] * luizsan_ (~luizsan@199.79.165.2) Quit (Quit: Leaving...)
[22:49] * tdonohue (~tdonohue@dspace/tdonohue) has left #duraspace
[22:58] * dyelar (~dyelar@129.237.45.105) Quit (Quit: Leaving.)
[23:56] * hpottinger (~hpottinge@162.104.218.179) Quit (Quit: Leaving, later taterz!)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.