Timestamps are in GMT/BST.
[0:02] * terry-b (~terry-b@71-212-24-25.tukw.qwest.net) Quit (Remote host closed the connection)
[0:53] * cknowles (uid98028@gateway/web/irccloud.com/x-eomisrqsktuvpvyf) Quit (Quit: Connection closed for inactivity)
[6:38] -hobana.freenode.net- *** Looking up your hostname...
[6:38] -hobana.freenode.net- *** Checking Ident
[6:38] -hobana.freenode.net- *** Found your hostname
[6:38] -hobana.freenode.net- *** No Ident response
[6:38] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:38] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:38] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:56] * peterdietz (uid52203@gateway/web/irccloud.com/x-jnscmqxhrmlumoku) Quit (Quit: Connection closed for inactivity)
[11:52] * cknowles (uid98028@gateway/web/irccloud.com/x-dfcfnwwyvkudciyb) has joined #duraspace
[13:06] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[13:14] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:17] * peterdietz (uid52203@gateway/web/irccloud.com/x-jambiqlopwwlqwou) has joined #duraspace
[15:01] <tdonohue> Hi all, it's time for our weekly DSpace Developers meeting. Agenda for today: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-09-23
[15:01] <kompewter> [ DevMtg 2015-09-23 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-09-23
[15:02] <tdonohue> As usual, our main topic for today is the Service API refactor...which seems to be progressing nicely over the last week (thanks in part to a ton of JSP work by KevinVdv & mhwood!)
[15:02] <tdonohue> https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api
[15:02] <kompewter> [ DSpace Service based api - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api
[15:02] <tdonohue> Based on the wiki page, it looks like everything *except* the Admin JSPs are marked as completed.
[15:03] <tdonohue> And the Admin JSPs have a PR: DSPR#1068
[15:03] <kompewter> [ https://github.com/DSpace/DSpace/pull/1068 ] - DS-2701 : Migrating the admin folder by KevinVdV
[15:04] <tdonohue> So... I'd say we are "nearly there". It seems like our refactor can be considered "feature complete". The last step may be to do some basic stability testing (looking for obvious bugs).
[15:04] <tdonohue> We also do have several outstanding PRs against the Services API branch needing review: https://github.com/DSpace/DSpace/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+base%3ADS-2701-service-api
[15:04] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+base%3ADS-2701-service-api
[15:04] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[15:06] <tdonohue> Thanks a TON to everyone who has helped out here! It's been a great collaborative effort...and thanks for helping out in the "home stretch" (JSPs), mhwood & KevinVdV
[15:07] <tdonohue> Oh, and I guess before we can consider this 100% complete...we'd also need to fix our Unit Test failures which Travis is still complaining about. :)
[15:08] * tdonohue feels like I'm talking to myself here.. (it's eerily quiet)
[15:08] <peterdietz> yes, +1 all the effort that everyone has thrown in
[15:09] <mhwood> abollini observed that there may be obsolete Lucene-based code in jspui/search that can be removed. I'm not familiar enough with search *or* jspui to feel confident that I can correctly identify it.
[15:09] <peterdietz> fix tests, and do some integration testing, to verify functionality of things in before and after sense
[15:10] <tdonohue> mhwood: yea, I saw that from abollini. I think (if needed) we could clean that up after things get to "master". Technically that Lucene refactor isn't fully completed yet / ticket isn't closed. But, we should add a note to that ticket about checking for obsolete search JSPs as well
[15:11] <tdonohue> +1 peterdietz
[15:12] <tdonohue> It seems like the best thing we could do now is to ensure the still open PRs (for services api branch) get an immediate review... That way we can get most/all merged ASAP and move towards fixing tests, integration testing, stabilization, etc
[15:12] <helix84> good job, everyone
[15:13] <helix84> I noticed that the service branch still doesn't build, what's missing on that front?
[15:13] <tdonohue> Do we want to jump in and review a few of these open PRs together? (Assuming no other pressing questions?)
[15:13] <tdonohue> helix84: it builds fine actually. It just doesn't pass all Unit Tests yet...I think there also may be a slight "breakage" in how unit tests are running on Travis.
[15:14] <tdonohue> helix84: but, yes, we need to fix Travis / Unit Tests before this is fully complete
[15:14] <tdonohue> 99% (or thereabouts) of unit tests succeed. I think we have a few small stragglers
[15:14] <helix84> so I assume as soon as it builds with tests passing, we can merge to master (even though it may not be fully functional)?
[15:15] <tdonohue> helix84: it might be nice to run a few (quick) stability tests (bring up each UI and bang on it briefly) prior to merger. But, beyond that, correct...we just need to fix up tests.
[15:16] <helix84> cool
[15:16] <tdonohue> The only reason I suggest a quick stability test is that it'd help PR makers if the UIs were "semi-stable" :) They *should* be...as we've technically been bringing up UIs during this refactor. But, a final run-through would be nice
[15:16] <tdonohue> We could even throw it up on demo.dspace.org for quick / common testing
[15:18] <tdonohue> Any other pressing questions on this refactor or other things we're forgetting? (Otherwise, shall we do a quick PR run through of what remains?)
[15:18] <helix84> (apropos, demo still probably has the issue of solr refusing to run in tomcat)
[15:19] <helix84> Just a quick question whether there's anything new in the UI working group?
[15:20] <tdonohue> helix84: The UI Prototype Challenge was announced last week: https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge
[15:20] <kompewter> [ DSpace UI Prototype Challenge - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge
[15:21] <tdonohue> While the "Challenge" is going on, the UI Working Group will be finalizing the judging criteria for prototypes. Other than that, it's a bit of a "waiting game" now for prototypes to be submitted
[15:22] * KevinVdV (~KevinVdV@d54c5104d.access.telenet.be) has joined #duraspace
[15:22] <tdonohue> Back on the Services API stuff... it sounds like there's no other questions. In that case, I'd recommend we spend some time here doing a *quick* review of the outstanding PRs for Services API
[15:23] <tdonohue> Oh, hi KevinVdV. We were just noting how the Services API refactor seems to be nearing completion. We have some outstanding PRs, but beyond those...it seems like we just need to fix Unit Tests & perform some quick stability testing (to ensure no other major immediate bugs pop up)
[15:24] <tdonohue> Here's our outstanding PRs for the Services API branch: https://github.com/DSpace/DSpace/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+base%3ADS-2701-service-api
[15:24] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+base%3ADS-2701-service-api
[15:24] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[15:24] <KevinVdV> Yeah I noticed, I merged some today which I had time to check out
[15:24] <tdonohue> KevinVdV did you have any other updates/notes to share? Otherwise, I figured we could use some time today to review those outstanding PRs together
[15:25] <KevinVdV> One thing on the unit tests, any help there is appriciated
[15:26] <KevinVdV> Especially: https://github.com/DSpace/DSpace/blob/master/dspace-api/src/test/java/org/dspace/content/CommunityCollectionIntegrationTest.java
[15:26] <kompewter> [ DSpace/CommunityCollectionIntegrationTest.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/test/java/org/dspace/content/CommunityCollectionIntegrationTest.java
[15:26] <tdonohue> I can help dig into unit tests some. I've been working more on the backend testing anyhow (mostly with Flyway / DB related stuff)
[15:27] <KevinVdV> & the group one that is failing is also a mystery because in debug mode in my intellij it works
[15:28] <tdonohue> One note I've discovered with Flyway/DB stuff. With the addition of the "pgcrypto" extension requirement for Postgres... I'm 99% certain that only Postgres "superusers" will be able to run "./dspace database clean" (as only superusers can remove extensions).
[15:28] <tdonohue> I don't think that's a big deal though...we should just document it..and we can always throw an error if you are NOT a "superuser"
[15:29] <KevinVdV> Well there is another way….
[15:29] <KevinVdV> Transfer all functions created by “pgcrypto” to the dspace user
[15:29] <KevinVdV> But I will need to look into gathering up all the functions
[15:29] <KevinVdV> Then it just becomes part of how to install the “pgcrypto” extension
[15:30] <mhwood> Please make that optional. Some sites will be using Pg for other things too.
[15:31] <tdonohue> KevinVdV. We could look into it. But, in reality, this may not be a big deal. The "database clean" command is mostly for developers (and shouldn't be run in production anyhow, obviously). So, if we just say "you need to have superuser privileges", that may not be a big deal
[15:31] <KevinVdV> Ok that also works for me ofc
[15:32] <tdonohue> I think it's a bit painful to make everyone transfer functions to "dspace" ownership... especially for a command that is just for development/testing
[15:32] <helix84> tdonohue: why does database clean have to remove pgcrypto? It's akin to creating/dropping the DB, ie. I don't think it's its responsibility.
[15:33] <KevinVdV> Well it is just how flyway does the cleaning I guess… it attempts to drop all tables & functions
[15:33] <tdonohue> helix84: it's actually trying to remove pgcrypto functions...which can only be created by a "superuser" account. Why pgcrypto can only be installed by a superuser is another question
[15:34] <tdonohue> From my understanding, some extensions (including pgcrypto) can only be installed/removed by superusers. Others can be installed/removed by db owners. It depends on what the extension does and what it creates
[15:35] <helix84> So what happens currently when you run database clean and don't have the priviliges? Will the whole clean fail or just removal of pgcrypto?
[15:35] <tdonohue> So, for pgcrypto. You need to install it as a superuser. But, that does NOT mean that the "dspace" db owner needs superuser privileges. You could install it as "postgres" and then use it as the "dspace" user
[15:36] <tdonohue> helix84: flyway throws an error saying you don't have permissions to remove pgcrypto. The database clean fails entirely. I was looking into "fixing it" but realized it cannot really be fixed (easily). So, we might just throw a more immediate error saying "You need superuser privileges to run a 'clean'"
[15:37] <peterdietz> hmm. then perhaps ant-update can pause/stop and give the user instructions, sorry, Dave, I can't do that. As postgres super user run: psql dspace123 -c "UPDATE ..."
[15:37] <helix84> tdonohue: I assume you also need admin privileges to add pgcrypto. Does flyway do that, too (and fail)?
[15:37] <tdonohue> (and we should be able to check if a user acct has superuser privileges pretty easily...so we could "catch" that error before even calling Flyway)
[15:38] <KevinVdV> & it is only for postgres, oracle should work fine.
[15:39] <tdonohue> helix84: We currently don't add pgcrypto via Flyway. Doing so would REQUIRE that the "dspace" db owner has 'superuser' privileges in Postgres. I don't think we should require that, as "superuser" privileges can be a security concern (gives that user acct full rights on all databases on that server)
[15:39] <peterdietz> ditto
[15:40] <helix84> tdonohue: I completely agree. But then I don't understrand why database clean tries to remove pgcrypto.
[15:40] <KevinVdV> Because the pgcrypto is just a bundle of functions & flyway tries to remove those
[15:40] <peterdietz> so.. my thought process a month ago, was just have flyway add pgcrypto. But since this is a postgres superuser only thing, then flyway has to back away from doing this
[15:40] <tdonohue> helix84: it doesn't actually try to remove pgcrypto ENTIRELY. It just tries to remove the functions that pgcrypto creates in your "dspace" database. But, it cannot remove those functions as they are owned by the superuser who created them
[15:41] <peterdietz> (thinking out loud
[15:41] <mhwood> So we need to have them owned by the DSpace database user.
[15:41] <tdonohue> peterdietz: correct
[15:41] <helix84> IMHO, dspace shouldn't try to remove something it didn't add.
[15:42] <helix84> If it's a manual step to install pgcrypto as DB admin, it should be the same wrt its removal.
[15:42] <peterdietz> oops. hit enter too soon. Could dspace user define a bunch of functions which equate to same thing as pgcrypto, and do it as dspace user, without needing to be super user. Sounds like a terrible idea, hacking pgcrypto in
[15:43] <helix84> Sorry, gotta run now. I'll be happy to follow up on this later in #dspace.
[15:43] <KevinVdV> Well feel free to try, the only function we need is to create a UUID for existing DSPace Objects
[15:43] <KevinVdV> But perhaps we should have this discussion in a JIRA & see if somebody can come up with a solution & proceed with the PR review ?
[15:44] <tdonohue> To be honest all, after thinking about this a bit on Monday (after I realized the issue)... I think I've come to the conclusion that our ONLY issue is with the "dspace database clean" command. Since that command is ONLY for developers, I don't see why we need to do a ton of "magic" to handle pgcrypto. Instead we can just return an error that says "You must be a superuser to run clean" if you attempt to run it as a non-superuser
[15:44] <tdonohue> I don't see any problem with requiring superuser privileges to run a "clean". Most folks should NEVER run a clean anyways (as it's only for development/testing)
[15:45] <tdonohue> I can create a JIRA ticket on this after the meeting (to capture any other brainstorms). I agree that we may want to proceed today with the PR review
[15:46] <tdonohue> Here's our PRs again: https://github.com/DSpace/DSpace/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+base%3ADS-2701-service-api
[15:46] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+base%3ADS-2701-service-api
[15:46] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[15:46] <tdonohue> first up, DSPR#1073
[15:46] <kompewter> [ https://github.com/DSpace/DSpace/pull/1073 ] - [DS-2764] CollectionDAOImpl - Parameters Switched by KevinVdV
[15:46] <KevinVdV> Yeah a silly mistake I made
[15:46] <tdonohue> tiny change. Looks obvious. merge immediately :)
[15:47] <tdonohue> I'll merge it
[15:47] <tdonohue> done
[15:47] <mhwood> Agreed, obvious fix.
[15:47] <tdonohue> next, DSPR#1072
[15:47] <peterdietz> cool
[15:47] <kompewter> [ https://github.com/DSpace/DSpace/pull/1072 ] - [DS-2701-service-api-jspui-subscriptions] Migrating the subscriptions jsp by KevinVdV
[15:48] <tdonohue> changes look reasonable to me, +1
[15:48] <KevinVdV> A small jsp, the last one in the “mydspace” folder
[15:48] <peterdietz> looks like standard, 1072 +1
[15:48] <tdonohue> Ok, that's enough votes. I'll merge it.
[15:49] <tdonohue> done
[15:49] <mhwood> Looks right.
[15:49] <tdonohue> I'm doing the next two out of order...as I know there's a dependency here
[15:49] <tdonohue> DSPR#1070 next
[15:49] <kompewter> [ https://github.com/DSpace/DSpace/pull/1070 ] - DS-2701 : Flyway Upgrade by tdonohue
[15:50] <tdonohue> This is an upgrade to the latest version of Flyway. As part of this, I updated our code to use non-deprecated Flyway API methods
[15:50] <KevinVdV> Looks good but haven’t found time to test it (although I think there will be enough testing going on soon)
[15:50] <tdonohue> (So it touches a few files, especially our Flyway callbacks, but all changes are minor)
[15:51] <tdonohue> Any objections here? Does this look OK to others?
[15:51] <peterdietz> 1070 looks reasonable. i'll defer to you Tim
[15:51] <mhwood> Looks sensible.
[15:51] <tdonohue> Ok. Merging then
[15:52] <tdonohue> Next, DSPR#1071
[15:52] <kompewter> [ https://github.com/DSpace/DSpace/pull/1071 ] - DS-2452: Upgrade to Commons Pool v2 by tdonohue
[15:52] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) has joined #duraspace
[15:53] <tdonohue> This is a followup to changes from KevinVdV. He upgraded us to Apache Commons DBCPv2, which uses Pool v2. So, I upgraded us fully to Pool v2
[15:54] <tdonohue> It *does* require refactoring the EventServiceImpl. But, I've done some basic testing of this, and I'm not seeing any issues
[15:55] <KevinVdV> Seems sensible to me
[15:55] <mhwood> So this has nothing to do with DB connections; EventServiceImpl is pooling something else.
[15:55] <tdonohue> (This PR has the Flyway changes from 1070 in it right now as well... I mistaken built this off a branch that included those too. But, since we just merged 1070, that should be a problem)
[15:55] <tdonohue> mhwood: correct. But, it cleans up our dependencies. Currently we'd be using Pool v1.4 and Pool v2 (used by DBCPv2) in parallel
[15:56] <tdonohue> (and I'm not sure if running two versions of Pool could cause us issues down the line)
[15:57] <KevinVdV> Yeah it is defenitly a good thing to upgrade older dependencies if we can
[15:57] <tdonohue> Does that make sense? Should we merge?
[15:57] <mhwood> Looks sensible to me.
[15:58] <KevinVdV> +1
[15:58] <mhwood> +1
[15:58] <tdonohue> Ok, I'll merge.
[15:58] <peterdietz> yeah, probably a good idea
[15:59] <tdonohue> Ok, next up, DSPR#1068
[15:59] <kompewter> [ https://github.com/DSpace/DSpace/pull/1068 ] - DS-2701 : Migrating the admin folder by KevinVdV
[15:59] <tdonohue> Lots of changes here...scanning (look minor/obvious so far)
[16:00] <KevinVdV> These are the last of the unrefactored jsp's
[16:01] <peterdietz> all jsp's. fine by me
[16:01] <tdonohue> Finished scanning. This all looks reasonable. Nothing jumps out at me
[16:01] <tdonohue> So, I'll give my +1. Others?
[16:02] <mhwood> I read more slowly. Nothing bad yet.
[16:04] <peterdietz> (I gave a carte blanche approval, based on it being only jsps)
[16:07] <tdonohue> Ok. I say we go ahead and merge this. We can clean up minor bugs later in testing. The major refactor looks good though
[16:07] <tdonohue> merged
[16:07] <mhwood> Looks good to me.
[16:08] <tdonohue> next up, DSPR#1048 (another big one)
[16:08] <kompewter> [ https://github.com/DSpace/DSpace/pull/1048 ] - [DS-2713] Ensure that there can still be an xml workflow migration by KevinVdV
[16:08] <mhwood> One comment: a lot of those for loops could be "enhanced" for since we don't use the index for anything but fetching members of aggregates.
[16:09] <KevinVdV> Yeah I know … but doing these refactoring tasks during my lunchbreaks…..
[16:09] <KevinVdV> Not much time to do stuff beyong making sure it compiles
[16:09] <tdonohue> 1048: I wish we didn't have to allow for "out-of-order" migrations with Flyway... but, I understand why we'd need to do this to support an "optional" migration for the optional XML Workflow feature.
[16:10] <tdonohue> 1048 makes me wish we could move to *one* Workflow already, rather than having two (which requires us to stretch Flyway a bit here)
[16:10] <KevinVdV> Well it would be required in DSpace 6 anyway regardless of service api
[16:10] <tdonohue> true
[16:11] <KevinVdV> I’m not a fan myself but there was no other way
[16:11] <tdonohue> yep. I agree. It's cause this is an "optional" db migration. There's no way around that
[16:12] <tdonohue> (other than moving to ONE workflow system, so there is no "optional" migration for XML Workflow)
[16:12] <mhwood> I don't understand much of what's going on in this one, because I haven't spent much time looking at what it changes.
[16:12] <tdonohue> (but that's a completely separate, larger task)
[16:13] <tdonohue> One question KevinVdV: Is there no way to use build the *new* XML Workflow migration scripts based on the 5.x ones? It seems slightly odd to me to have repetition in those migration scripts. Normally the 6.x ones would just include *new* changes on top of the 5.x ones
[16:14] <KevinVdV> Well because the old 5 migration scripts use integer based refences as foreign keys
[16:14] <tdonohue> Instead, it seems like you are essentially building in a way to *skip* the 5.x XMLWorkflow scripts and just run the 6.x ones? Or am I misunderstanding?
[16:14] <KevinVdV> For example cwf_workflowitem links to the item id which USED to be int
[16:15] <peterdietz> I've not used XML workflow. Either needs better marketing, or make it behave like the old workflow (ui configuration, and accept/reject/ edit to be default state of it). So everyone can just migrate to it without noticing
[16:15] <KevinVdV> Yep that is what I’m doing, but the 5.x ones are still in there for fresh install with xml workflow enabled
[16:16] <mhwood> I can't say I understand the changes, but nothing leapt out at me as a concern.
[16:16] <tdonohue> KevinVdV: I guess I'm confused why you'd ever *skip* the 5.x XMLWorkflow migrations.... shouldn't it be like... (1) enable XMLWorkflow, (2) run 5.x scripts, (3) run 6.x scripts (to refactor DB for 6.x and migrate data)? Instead it seems to go #1 then #3?
[16:17] <tdonohue> I feel like I'm probably missing something here though...just seems odd to skip any old migration scripts
[16:17] <mhwood> tdonohue++
[16:18] <KevinVdV> Because with a 6 database the followoling sql statement wouldn’t work: https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/resources/org/dspace/storage/rdbms/xmlworkflow/postgres/xml_workflow_migration.sql#L33
[16:18] <kompewter> [ DSpace/xml_workflow_migration.sql at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/resources/org/dspace/storage/rdbms/xmlworkflow/postgres/xml_workflow_migration.sql#L33
[16:19] <KevinVdV> because the item_id doesn’t exist anymore
[16:20] <tdonohue> Oooohhh. I see. So, if your DB is *already* running DSpace 6.x, it won't be able to run the old 5.x XML Migration scripts
[16:20] <KevinVdV> Indeed !
[16:20] <KevinVdV> But a fresh install WILL still need that old sql
[16:20] <tdonohue> (so, XML Migration would fail to work right if you upgraded to 6.x BEFORE enabling XML Migration)
[16:20] <KevinVdV> Took me a while to get all scenarios working
[16:21] <peterdietz> aha.. yeah. didn't imagine that case
[16:21] <tdonohue> Yea..I completely missed that scenario. Ok. It's a bit of an "ugly beast" (but a very smart way to do this, KevinVdV). But, it now makes sense. +1
[16:22] <KevinVdV> All the scenario’s that I was able to come up with are in the JIRA
[16:22] * tdonohue might add in an additional comment into the code to better explain this non-obvious scenario..and why the 5.x scripts have to be skipped for that scenario. Otherwise, I worry we'll look at this in a few years and wonder "WHY?"
[16:23] <KevinVdV> Ok I can do that
[16:23] <tdonohue> I guess it's kinda implied by this comment though: https://github.com/DSpace/DSpace/pull/1048/files#diff-f3642aa768b603347f97be2263784de4R59
[16:23] <kompewter> [ [DS-2713] Ensure that there can still be an xml workflow migration by KevinVdV · Pull Request #1048 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1048/files#diff-f3642aa768b603347f97be2263784de4R59
[16:24] <tdonohue> I'd just add: "(e.g. if your database is already running DSpace 6 prior to enabling XML Workflow, we need to skip these old 5.x scripts, as they are incompatible with a 6.x database)"
[16:24] <tdonohue> It's what you seem to be implying there KevinVdV... just a bit more bluntly stated
[16:24] <KevinVdV> That is what it does yes
[16:25] <KevinVdV> But currently at home so will make the change tomorrow
[16:25] <KevinVdV> Or merge now & create a pull request to fix the comment
[16:25] <tdonohue> I'll just merge & fix it in a new tiny PR. No problem
[16:26] <tdonohue> OK, we are way "overtime" here...but one last one: DSPR#1039
[16:26] <kompewter> [ https://github.com/DSpace/DSpace/pull/1039 ] - DS-2730 link getName() to DSpaceServices by pnbecker
[16:26] <KevinVdV> Great thx
[16:26] <tdonohue> Based on KevinVdV's comments on 1039, we likely need to wait on this one
[16:28] <KevinVdV> Yeha DSpace won’t compile anymore if we merge this one
[16:28] <tdonohue> I think that wraps things up? We'll wait on 1039.
[16:29] <tdonohue> Next steps here: We need to get Unit Tests all working (and I'll chip in on that this week). We also need to get some basic stability tests done on UIs (just to ensure no major problems we've overlooked on any)
[16:29] <tdonohue> Then, *hopefully* we can merge all this to master as early as next week.
[16:30] <tdonohue> We probably should also send a status update on where we stand to dspace-devel, to warn developers / Committers that this is coming soon
[16:30] <mhwood> Prepare to open the floodgates!
[16:31] <tdonohue> Any last topics or questions for today?
[16:32] <mhwood> Not here.
[16:32] <hpottinger> to be clear, for the integration testing, you're talking about doing that manually, not writing tests?
[16:32] <KevinVdV> *thumbleweed*
[16:32] <peterdietz> hmm. i guess we're all busy, but tim are you thinking of refactoring configuration to work with services?
[16:32] <tdonohue> hpottinger: correct. manual testing
[16:33] <mhwood> Anybody who wants to write an automated integration test is welcome to do so, I think.
[16:33] <hpottinger> do we want to stand this up on demo and ask the community to testathon it?
[16:33] * cknowles (uid98028@gateway/web/irccloud.com/x-dfcfnwwyvkudciyb) Quit (Quit: Connection closed for inactivity)
[16:33] <tdonohue> peterdietz: yes. I still have an (old) PR opened which refactors configuration to use Services (and Apache Commons Config). I plan to refactor/rebase that work (in time for 6.0) once the Service API stuff is over in "master"
[16:33] <hpottinger> mhwood: I was mostly asking to clarify, in case an observer reads the logs and is tempted to believe we have automated tests
[16:33] <peterdietz> this is as close as I've got for integration testing. Rebuild each time with a fresh DB, and the fire away with: https://github.com/DSpace-Labs/dspace-rest-requests
[16:33] <kompewter> [ DSpace-Labs/dspace-rest-requests · GitHub ] - https://github.com/DSpace-Labs/dspace-rest-requests
[16:34] <tdonohue> Ok, I'm going to close up the meeting for today. No new topics, but feel free to continue discussions either here or in #dspace. Thanks all!
[16:36] * KevinVdV (~KevinVdV@d54c5104d.access.telenet.be) Quit (Quit: KevinVdV)
[16:55] * cknowles (uid98028@gateway/web/irccloud.com/x-aejkjkiibrqtpyym) has joined #duraspace
[19:46] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[20:49] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[21:01] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:33] * cknowles (uid98028@gateway/web/irccloud.com/x-aejkjkiibrqtpyym) Quit (Quit: Connection closed for inactivity)
[21:36] * peterdietz (uid52203@gateway/web/irccloud.com/x-jambiqlopwwlqwou) Quit (Quit: Connection closed for inactivity)
[21:48] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.