Timestamps are in GMT/BST.
[6:47] -weber.freenode.net- *** Looking up your hostname...
[6:47] -weber.freenode.net- *** Checking Ident
[6:47] -weber.freenode.net- *** Found your hostname
[6:47] -weber.freenode.net- *** No Ident response
[6:47] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:47] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:47] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[7:02] * xbsb (~bkroll@gateway.bsb-muenchen.de) has joined #duraspace
[7:03] * xbsb (~bkroll@gateway.bsb-muenchen.de) has left #duraspace
[8:47] * AlexS[zedat] (~Alexander@home.zedat.fu-berlin.de) Quit (*.net *.split)
[9:31] * AlexS[zedat] (~Alexander@home.zedat.fu-berlin.de) has joined #duraspace
[12:20] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:22] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[14:54] <DSpaceSlackBot> <tdonohue> @here: Reminder, our DSpace Developers Meeting is at the top of the hour (~5mins). Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-08-09
[14:54] <kompewter> [ DevMtg 2017-08-09 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-08-09
[15:01] <DSpaceSlackBot> <tdonohue> @here: it's DSpace DevMtg time (agenda linked above). As usual, I'd like to do a very quick rollcall (a simple "here" is fine) to see who's with us today either in Slack or IRC.
[15:01] <DSpaceSlackBot> <mwood> Here!
[15:02] <DSpaceSlackBot> <tdonohue> Either we have a lot of lurkers, or others are off getting coffee/snacks ;) Well, either way, we'll move along and hope a few others pop into the discussion
[15:03] <DSpaceSlackBot> <sulfrian> I am here, too
[15:04] <DSpaceSlackBot> <tdonohue> Ok, so the main topic today is getting a 6.2 out the door (ASAP really). We've got a number of important Hibernate bugs to squash, but I'd like to get them all squashed together if we can do so
[15:05] <DSpaceSlackBot> <tdonohue> The list of tickets is still at the top of the agenda. DS-3659 was closed out this week, but three remain.
[15:05] <kompewter> [ https://jira.duraspace.org/browse/DS-3659 ] - [DS-3659] Database migrate fails to create the initial groups - DuraSpace JIRA
[15:06] <DSpaceSlackBot> <tdonohue> DS-3648 / DSPR#1813
[15:06] <kompewter> [ https://jira.duraspace.org/browse/DS-3648 ] - [DS-3648] XMLUI Batch Import Failure - DuraSpace JIRA
[15:06] <kompewter> [ https://github.com/DSpace/DSpace/pull/1813 ] - DS-3648: Fix LazyInitializationExceptions in Batch Import Failure by tomdesair
[15:06] <DSpaceSlackBot> <tdonohue> (Sidenote: This one is tightly intertwined with PR-1812, which is next in the list)
[15:07] <DSpaceSlackBot> <tdonohue> The main idea behind this PR seems sound, but we've hit a bit of a "controversy" here with the `flush()` changes in the `uncacheEntity()` method (which are actually added as part of DSPR#1812)
[15:07] <kompewter> [ https://github.com/DSpace/DSpace/pull/1812 ] - [DS-3656] DOIOrganiser CLI does not change the database anymore by ssolim
[15:08] <DSpaceSlackBot> <tdonohue> So, between 1812 / 1813, I'm starting to wonder if we need a possible new approach here...
[15:09] <DSpaceSlackBot> <tdonohue> Conceptually, the new `flush()` makes sense (we don't want to lose session changes before uncaching)
[15:10] <DSpaceSlackBot> <tdonohue> But, should that be the job of `uncacheEntity()`? Or should the code calling `uncacheEntity()` *first* ensure changes are saved (via a `commit()` or similar) before it uncaches?
[15:10] <DSpaceSlackBot> <tdonohue> @sven in dev today suggested the latter as a solution to PR-1812
[15:11] <DSpaceSlackBot> <mwood> I concur: the caller knows what it is doing, and Context does not.
[15:12] <DSpaceSlackBot> <tdonohue> So, that said, it sounds like we should close 1812 and 1813 and create new PRs which fix they problems by adding in new `commit()` calls where needed. (That said, 1813 has other changes that should be pulled into the new PR)
[15:13] <DSpaceSlackBot> <mwood> I think I agree, but would feel better to hear a few more voices.
[15:14] <DSpaceSlackBot> <tdonohue> Unfortunately, we seem a small team today. Another option is to keep these PRs open (for now) but create alternative versions (based on this new idea) to see if we can fix it another way. We can point folks at the new PRs and decide which approach is "bettter"
[15:15] <DSpaceSlackBot> <tdonohue> That all said, I'd need some help/volunteers here. Looking at this week's schedule, I'm not sure I'll have time myself to create these alternative PRs. Though the alternative to 1812 is seemingly already proposed by @sven as this: https://github.com/ssolim/DSpace/commit/ac3ecbf4c58f974bb092652eff8ad746bff04850
[15:15] <kompewter> [ added context.commit for objects when processed · ssolim/DSpace@ac3ecbf · GitHub ] - https://github.com/ssolim/DSpace/commit/ac3ecbf4c58f974bb092652eff8ad746bff04850
[15:16] <DSpaceSlackBot> <cwilper> Not having the in-depth knowledge of the issue you folks have, I would think making Context "dumb" (not overly presumptuous about the use-case) makes sense.
[15:18] <DSpaceSlackBot> <tdonohue> Hi @cwilper, welcome ;) The issue is essentially a Hibernate caching issue...the twin goal of keeping the cache "small" (to ensure better performance) but not accidentally "uncaching" stuff that hasn't been saved (which is the issue we are having). The fix was proposed as https://github.com/DSpace/DSpace/pull/1812 (but we are rethinking that approach now)
[15:18] <kompewter> [ [DS-3656] DOIOrganiser CLI does not change the database anymore by ssolim · Pull Request #1812 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1812
[15:19] <DSpaceSlackBot> <sulfrian> 1813 is about not uncaching some objects? I do not think we need to add `commit()` calls, or am I missing something?
[15:19] <DSpaceSlackBot> <tdonohue> 1813 added in the commits of 1812 (i.e. the `flush()` before uncache) cause of similar issues noted in this comment: https://jira.duraspace.org/browse/DS-3648?focusedCommentId=56562&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-56562
[15:20] <kompewter> [ https://jira.duraspace.org/browse/DS-3648 ] - [DS-3648] XMLUI Batch Import Failure - DuraSpace JIRA
[15:20] <kompewter> [ [DS-3648] XMLUI Batch Import Failure - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3648?focusedCommentId=56562&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-56562
[15:21] <DSpaceSlackBot> <tdonohue> So, 1813 to me "sounds" like it was experiencing similar uncaching issues (to 1812) after part of it was fixed. I've not yet fully tested it myself though...just noting why these two PRs got "connected" together
[15:22] <DSpaceSlackBot> <tdonohue> As @tom_desair is off on vacation, I think these both need more eyes / testers though. Both tickets have "stalled" somewhat, which is why I'd like to see if we could find new volunteers for fixing either (in a new PR)
[15:22] <DSpaceSlackBot> <sulfrian> I maybe have time to look into that tomorrow .
[15:23] <DSpaceSlackBot> <tdonohue> Thanks @sulfrian, that'd be great if you can! My suspicion is there's (one or more) `commit()` missing before an `uncacheEntity()` in this XMLUI batch import code
[15:24] <DSpaceSlackBot> <sulfrian> Yes, I suspect something, too.
[15:24] <DSpaceSlackBot> <tdonohue> And it sounds like @hpottinger previously tested this ticket (we're talking DS-3648, Hardy), so maybe we can get him to help re-test any new solution
[15:24] <kompewter> [ https://jira.duraspace.org/browse/DS-3648 ] - [DS-3648] XMLUI Batch Import Failure - DuraSpace JIRA
[15:25] <DSpaceSlackBot> <tdonohue> Ok, so that's a plan for an alternative PR to 1813. Anyone want to create/test a quick alternative to 1812 (likely just a cherry-pick of https://github.com/ssolim/DSpace/commit/ac3ecbf4c58f974bb092652eff8ad746bff04850)?
[15:26] <DSpaceSlackBot> <tdonohue> I'll admit, I've not used DOIOrganiser before myself. I could create this quickly, but not sure how best to "test" (yet) ;)
[15:26] <DSpaceSlackBot> <sulfrian> I can create a pull request for this. But I currently do not have a working DOI setup, so I cannot test it.
[15:26] <DSpaceSlackBot> <terrywbrady> Joining late. Hello everyone
[15:27] <DSpaceSlackBot> <tdonohue> @sulfrian : if you want to create this quickly, I'll let you do so, and see if I can search out a tester for you (and/or even just ping @sven to approve it)
[15:27] <DSpaceSlackBot> <tdonohue> thanks again!
[15:28] <DSpaceSlackBot> <tdonohue> So, it sounds like we have a plan to fix/replace the 1812 and 1813 PRs, which is good. I'd encourage us all to test/review them quickly once available
[15:29] <DSpaceSlackBot> <terrywbrady> I can test something. Let me know which PR to start with
[15:29] <DSpaceSlackBot> <tdonohue> The last ticket in our list is DS-3660 / DSPR#1816
[15:29] <kompewter> [ https://github.com/DSpace/DSpace/pull/1816 ] - DS-3660: Fix discovery reindex on metadata change by AlexanderS ¡ Pull Request #1816 ¡ DSpace/DSpace ¡ GitHub
[15:29] <kompewter> [ https://jira.duraspace.org/browse/DS-3660 ] - [DS-3660] Items fail to be reindexed on metadata change when 'authority' consumer is enabled - DuraSpace JIRA
[15:30] <DSpaceSlackBot> <tdonohue> This one looks good to me (and has a few approvals of code review). But, it would be nice to give it a quick test. @terrywbrady -- this is one you could test right away, and shouldn't be hard to test
[15:30] <DSpaceSlackBot> <terrywbrady> Will do.
[15:30] <DSpaceSlackBot> <tdonohue> As noted in the ticket 3660, just enable the "authority" consumer, and make sure that reindexing triggers automatically after updating any metadata field.
[15:31] <DSpaceSlackBot> <tdonohue> Thanks, @terrywbrady !
[15:32] <DSpaceSlackBot> <tdonohue> So, that's it for the tickets I had listed as "must have" for the 6.2 release. Are there any other major issues (especially Hibernate related) we need/want to review for 6.2?
[15:33] <DSpaceSlackBot> <sulfrian> I haven't heard anything other.
[15:33] <DSpaceSlackBot> <tdonohue> Neither have I. Just wanted to be sure I hadn't missed anything myself ;)
[15:34] <DSpaceSlackBot> <terrywbrady> They are not hibernate related, but I have 2 PR's looking for some attention: https://github.com/DSpace/DSpace/pull/1817 and https://github.com/DSpace/DSpace/pull/1782
[15:34] <kompewter> [ [DS-3661] ImageMagick PDF Processing Degraded with Changes in 5.7 release by terrywbrady · Pull Request #1817 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1817
[15:34] <kompewter> [ [DS-3602] Ensure Consistent Use of Legacy Id in Usage Queries by terrywbrady · Pull Request #1782 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1782
[15:34] <DSpaceSlackBot> <tdonohue> 1817 looks like it'd require a 5.8 release to fix :( So, that'd need to be in a different release of course
[15:35] <DSpaceSlackBot> <terrywbrady> You are right. It would be nice to get it merged
[15:35] <DSpaceSlackBot> <terrywbrady> The performance hit is SIGNIFICANT
[15:37] <DSpaceSlackBot> <mwood> Oh, I guess I should mention https://github.com/DSpace/DSpace/pull/1820
[15:37] <DSpaceSlackBot> <tdonohue> Unclear to me how to reproduce 3661. Does it affect everyone using ImageMagick? Or only if you have a custom color profile?
[15:37] <DSpaceSlackBot> <terrywbrady> If we have time today, could we continue the conversation from DCAT about creating a cloud instance running the latest release?
[15:37] <kompewter> [ [DS-3667] Document fundamental persistence support classes. by mwoodiupui · Pull Request #1820 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1820
[15:38] <DSpaceSlackBot> <terrywbrady> For 3661, run the imagemagick thumbnail creator on a multi page PDF. It takes 30 sec per page to process.
[15:38] <DSpaceSlackBot> <terrywbrady> Event though you only need the first page for the thumbnail.
[15:38] <DSpaceSlackBot> <terrywbrady> If you enable the color profile setting, the performance hit will still be present.
[15:38] <DSpaceSlackBot> <tdonohue> So, the answer to my question is it affects *everyone* using ImageMagick? (correct?)
[15:39] <DSpaceSlackBot> <terrywbrady> Yes
[15:39] <DSpaceSlackBot> <tdonohue> Just making sure I understand, as that affects the priority here obviously
[15:40] <DSpaceSlackBot> <terrywbrady> We had to perform an emergency release in order to work around the issue. New collections could not be processed.
[15:41] <DSpaceSlackBot> <tdonohue> Ok, well the changes in PR 1817 look fine to me. I can give them a code review :+1: That doesn't resolve the fact that this would need a 5.8 release though (if even just to fix this one major issue introduced in 5.7)
[15:42] <DSpaceSlackBot> <terrywbrady> Great. @alanorth confirmed his test so I think it could then be merged
[15:43] <DSpaceSlackBot> <tdonohue> Would you be willing to cut a quick 5.8 (not necessarily now, but in nearish future)? It seems like if this affects everyone using ImageMagick, it'd be good to get it in a formal release
[15:43] <DSpaceSlackBot> <terrywbrady> Sure. It would be a good way for me to learn the process.
[15:43] <DSpaceSlackBot> <terrywbrady> I still hope to shadow Mark on the 6.2 creation.
[15:44] <DSpaceSlackBot> <hpottinger> https://wiki.duraspace.org/display/DSPACE/Release+Procedure#ReleaseProcedure-MakinganOfficialRelease%28e.g.%27dspace-x.y%27or%27dspace-x.y-rc1%27%29
[15:44] <kompewter> [ Release Procedure - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Release+Procedure#ReleaseProcedure-MakinganOfficialRelease%28e.g.%27dspace-x.y%27or%27dspace-x.y-rc1%27%29
[15:44] <DSpaceSlackBot> <tdonohue> Thanks @terrywbrady . Yes, the 6.2 release would be good to learn from. Also reviewing the docs @hpottinger just linked to (and the "prerequisites" on that page for doing a release)
[15:45] <DSpaceSlackBot> <terrywbrady> You all have worn me down and have gotten me to volunteer to do a release.
[15:45] <DSpaceSlackBot> <tdonohue> Scrolling back up... DSPR#1782 was also mentioned
[15:45] <kompewter> [ https://github.com/DSpace/DSpace/pull/1782 ] - [DS-3602] Ensure Consistent Use of Legacy Id in Usage Queries by terrywbrady
[15:45] <DSpaceSlackBot> <mwood> Yeah, there's some stuff you have to do, to be able to work with Sonatype, and it will take a bit of time.
[15:46] <DSpaceSlackBot> <tdonohue> 1782: I have no objections to including this in 6.2. But, it sounds like it's waiting for a tester?
[15:46] <DSpaceSlackBot> <terrywbrady> Yes. No luck so far. It would be unfortunate to not address this issue.
[15:46] <DSpaceSlackBot> <terrywbrady> Our rep admins really care about usage stats.
[15:47] <DSpaceSlackBot> <tdonohue> Is there an "easy" way to test this (that could be laid out in the PR)? Or, do you have to have a 5.x (with stats) sitting around to upgrade to 6.x and test?
[15:48] <DSpaceSlackBot> <terrywbrady> You either need to upgrade a 5x instance or you need to have a set of exported 5x stats lying around that you can import
[15:48] <DSpaceSlackBot> <tdonohue> TBH, the code to me "looks right", but I'm at a loss to testing it easily
[15:49] <DSpaceSlackBot> <hpottinger> OK, so: Vagrant-DSpace up a 5x-based instance, poke poke poke, verify there are a few stats in there, upgrade it to 6x
[15:50] <DSpaceSlackBot> <tdonohue> @hpottinger care to give this a bit of a test? (just a quick verification that basics "work"?)
[15:50] <DSpaceSlackBot> <tdonohue> (I'll gladly give it a code review)
[15:50] <DSpaceSlackBot> <hpottinger> I'm swamped
[15:51] <DSpaceSlackBot> <hpottinger> I've got one eye on this meeting, and another on a bunch of Mirage2 stylesheets
[15:52] <DSpaceSlackBot> <tdonohue> Ok. I'll code review this...see if I can find time to give it a verification test. Otherwise, I might just "trust it" assuming @terrywbrady has done some major testing for his repo mgr folks
[15:52] <DSpaceSlackBot> <terrywbrady> Thanks. I appreciate this getting some attention.
[15:53] <DSpaceSlackBot> <tdonohue> Running short on time, but I want to also mention DSPR#1820
[15:53] <kompewter> [ https://github.com/DSpace/DSpace/pull/1820 ] - [DS-3667] Document fundamental persistence support classes. by mwoodiupui
[15:53] <DSpaceSlackBot> <tdonohue> More eyes on this PR (which is all enhanced comments) would be useful. I'd really like to get this into 6.2, as it helps document all this Hibernate Session/Connection stuff better
[15:54] <DSpaceSlackBot> <tdonohue> But it'd be good to verify no obvious "misstatements" in these comments... I looked myself and didn't see anything
[15:54] <DSpaceSlackBot> <mwood> I'm always nervous when I find myself writing documentation because I needed to *read* that documentation.
[15:55] <DSpaceSlackBot> <terrywbrady> I added myself as a reviewer
[15:55] <DSpaceSlackBot> <mwood> Thanks!
[15:55] <DSpaceSlackBot> <tdonohue> Based on my understanding of the purpose of these classes, I think your docs here are correct @mwood . That said, I didn't write this code either... it mostly came from @kevinvdv (and updates from @tom_desair and others)
[15:58] <DSpaceSlackBot> <terrywbrady> Will the in-code documentation be sufficient? Is there a need for a supplemental wiki page to go along with the code?
[15:58] <DSpaceSlackBot> <tdonohue> A wiki page on how we use Hibernate or Hibernate resources we've found to "explain things" would also be nice. But, this is a good start to document what the code is "supposed to do"
[15:58] <DSpaceSlackBot> <mwood> We probably do need a higher-level document on disciplined use of the persistence layer to avoid things like the PRs we've discussed today.
[15:58] <DSpaceSlackBot> <tdonohue> I'd welcome anyone to start such a doc on the Wiki. I'd gladly contribute to it... I just haven't had the chance to do that myself
[15:58] <DSpaceSlackBot> <terrywbrady> If I feel inspired as I review, I will create one
[15:58] * DuraLogBot (~PircBot@webster.duraspace.org) Quit (Ping timeout: 260 seconds)
[15:58] * Disconnected.
[15:58] -verne.freenode.net- *** Looking up your hostname...
[15:58] -verne.freenode.net- *** Checking Ident
[15:58] -verne.freenode.net- *** Found your hostname
[15:58] -verne.freenode.net- *** No Ident response
[16:31] -adams.freenode.net- *** Looking up your hostname...
[16:31] -adams.freenode.net- *** Checking Ident
[16:31] -adams.freenode.net- *** Found your hostname
[16:31] -adams.freenode.net- *** No Ident response
[16:31] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[16:31] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[16:31] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[17:42] <DSpaceSlackBot> <terrywbrady> As a follow up to today's meeting, I created a first draft proposal related to Active Branch Cloud Instances: https://wiki.duraspace.org/display/~terrywbrady/Proposal%3A+Create+Cloud+Instances+for+DSpace+Active+Branches
[17:42] <kompewter> [ Proposal: Create Cloud Instances for DSpace Active Branches - Terry Brady - DuraSpace Wiki ] - https://wiki.duraspace.org/display/~terrywbrady/Proposal%3A+Create+Cloud+Instances+for+DSpace+Active+Branches
[20:09] * dyelar (~dyelar@129.237.146.129) Quit (Quit: Leaving.)
[20:54] * tdonohue (~tdonohue@dspace/tdonohue) Quit (Ping timeout: 258 seconds)
[20:59] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[21:49] * tdonohue (~tdonohue@dspace/tdonohue) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.