#duraspace IRC Log


IRC Log for 2017-02-08

Timestamps are in GMT/BST.

[6:51] -orwell.freenode.net- *** Looking up your hostname...
[6:51] -orwell.freenode.net- *** Checking Ident
[6:51] -orwell.freenode.net- *** Found your hostname
[6:51] -orwell.freenode.net- *** No Ident response
[6:51] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:51] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:51] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[13:27] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:00] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[14:52] <tdonohue> Morning/Afternoon all. The DSpace DevMtg starts at the top of the hour: https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-02-08
[15:01] * terry-b (~chrome@97-113-118-39.tukw.qwest.net) has joined #duraspace
[15:02] <tdonohue> Hi All, it's time for the DSpace DevMtg. It's a small group today... I just pinged folks on Slack #dev as well to see if anyone else plans to join us
[15:02] <tdonohue> Agenda is really the same as in recent weeks...continuing DSpace 6 maintenance work: https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-02-08
[15:02] <terry-b> hello!
[15:03] <tdonohue> Hi terry-b
[15:03] <tdonohue> That reminds me...pinging other Committers (helix84, mhwood)
[15:04] <tdonohue> So, we'll kick off with usual reminders. The next DSpace 7 UI Meeting is tomorrow. It was announced to dspace-devel yesterday
[15:04] <tdonohue> https://groups.google.com/d/msg/dspace-devel/pfMG_sFkGnY/dO-7kiTSBgAJ
[15:04] <tdonohue> Also, I've kept the usual Slack reminder around, but I'm pretty sure everyone here is already in Slack ;)
[15:06] <tdonohue> So, I'm wondering if anyone else besides terry-b & I are here... is it just two of us? mhwood, are you around today?
[15:06] * hpottinger (~hpottinge@ has joined #duraspace
[15:06] <tdonohue> there's mr. hpottinger..that makes three (of us)
[15:06] <mhwood> Sorry, just got back from a meeting.
[15:07] * hpottinger points at himself, looks worried, "who, me?"
[15:07] <tdonohue> there we go, up to four! ;)
[15:07] <hpottinger> wasn't me
[15:08] <tdonohue> In any case, next up on the agenda is to go through our 6.x tickets. I've noticed (recently) we have a few PRs that seem to be nearing acceptance...so, it might be nice to get some merged in here today (if we can) or figure out next steps to merging
[15:09] <terry-b> I would love to see the stats repo PR's merged
[15:09] <tdonohue> I'm thinking mainly of the work terry-b has done on statistics/solr fixes. IIRC, several of those PRs are at +1
[15:09] <tdonohue> terry-b: do you have all the PR #'s handy? we could give them a review here and see if we can push them forward
[15:09] <mhwood> Yeah, I have a couple of those on my list to review.
[15:09] <terry-b> Will do
[15:10] <terry-b> https://github.com/DSpace/DSpace/pull/1635
[15:10] <terry-b> https://github.com/DSpace/DSpace/pull/1634
[15:10] <terry-b> Those are the pair for master. We have similar pairs for 5x and 6x
[15:11] <tdonohue> Right, I *think* kshepherd had +1'ed the 6x versions of these PRs, correct?
[15:11] <terry-b> Correct. Shall I share those?
[15:11] <tdonohue> yep, looks like the 6x versions are: DSPR#1633 and DSPR#1624
[15:12] <tdonohue> oh, we don't have kompewter here
[15:12] <tdonohue> https://github.com/DSpace/DSpace/pull/1633 and https://github.com/DSpace/DSpace/pull/1624
[15:12] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[15:13] <tdonohue> thanks terry-b for cleaning up your whitespace alignment in these PRs (much easier to read) ;)
[15:13] * ntorres (c1895861@gateway/web/freenode/ip. has joined #duraspace
[15:14] <terry-b> Thanks for pointing it out. Hopefully my tab setting update in Eclipse will help me see those issues in advance.
[15:15] <tdonohue> So, starting at 1633/1634 (Tomcat hanging issues on shards)... the changes here look good to me. I'd lean towards merging these (to all branches) unless there are objections here?
[15:16] <tdonohue> ^ mhwood / hpottinger, what do you say on 1633/1634 (these are the same issue on different branches)?
[15:16] <hpottinger> no objections, I can toss a +1 on the pile if that helps?
[15:16] <mhwood> Looking at it now.
[15:16] <terry-b> These are a pair of issues for 6x.
[15:16] <hpottinger> looks tested, code is from a trusted dev...
[15:17] <terry-b> One addresses the shard hang issue. The other addresses the import/export tools which facilitates shard management and testing
[15:17] <terry-b> Changes are nearly identical on 6x and master PR pairs. 5x does not have the tomcat hang issue so that PR is slightly different.
[15:19] <tdonohue> terry-b: small note for the future, it'd help (me) if we link these PRs together via their descriptions (I keep having to search on the ticket ID to find the PRs on each of the various branches)
[15:20] <tdonohue> it's not a big deal to fix here...just makes it easier on testers/reviewers to find all of them at once
[15:20] <terry-b> Makes sense. I had them paired in the wiki page that detailed all the issues...
[15:20] <hpottinger> I tossed a +1 on to both 1633 and 1624
[15:21] <hpottinger> and 1634, too
[15:21] <mhwood> Sorry, struggling to comprehend the synchronization....
[15:22] <hpottinger> tdonohue++ we should link matching PRs
[15:22] <terry-b> The initialization now runs on the first use of solr. That is to address multiple threads calling the initialization before it is complete
[15:24] <mhwood> So that adds in a delay, but doesn't positively wait on Solr to start? Probably good enough, but then I should stop looking for the wait.
[15:25] <terry-b> Solr has started at the point where the inits are called. The logic moved from class loading to first use of solr.
[15:25] <terry-b> (At the point where the synchronized init method is called)
[15:26] <mhwood> Theoretically Tomcat could still be starting Solr. Practically, it very likely won't be.
[15:26] <tdonohue> I've cross linked all these PRs to the 6x versions now (as those PRs are where the most voting has occurred). So, let's consider the "primary" PRs to be DSPR#1633 (6x shard fix) and DSPR#1624 (6x import/export fixes)
[15:26] <kompewter> [ https://github.com/DSpace/DSpace/pull/1633 ] - [DS-3457] Address tomcat hang when multiple solr shards exist in DSpace 6 by terrywbrady
[15:26] <kompewter> [ https://github.com/DSpace/DSpace/pull/1624 ] - [DS-3456] 6x Fix Command Line Parameters for statistics import/export tools by terrywbrady
[15:27] <mhwood> Anyway it sounds like a better design than before.
[15:28] <tdonohue> Yes, I think this shard fix looks much better than before...it now actually pings Solr to ensure it's running...whereas before we just "assumed" it likely should be running if Tomcat is up
[15:28] <terry-b> Interesting note... if the ping is called during class load, it also causes tomcat to hang.
[15:29] <tdonohue> So, 1633 (shard fix) now is at +3 votes (and no objections from mhwood). So, I'll go through and merge those three PRs....if you all want to start reviewing DSPR#1624 (the import/export CLI fixes) in meantime
[15:29] <kompewter> [ https://github.com/DSpace/DSpace/pull/1624 ] - [DS-3456] 6x Fix Command Line Parameters for statistics import/export tools by terrywbrady
[15:30] * dyelar (~dyelar@biolinux.mrb.ku.edu) has joined #duraspace
[15:30] <terry-b> Among other things, this addressed a fun issue that only manifested itself in certain time zones!
[15:31] <mhwood> Oh, THOSE are always interesting.
[15:31] * hpottinger grumbles grumpily about time-zone bugs...
[15:32] <mhwood> That would be in SolrLoggerServiceImpl.
[15:32] <terry-b> yes
[15:34] <tdonohue> I've merged two of the shard PRs...cannot merge the 5x one though until DSPR#1624 is approved (as the 5.x shard fixes also include the import/export tool commits)
[15:34] <kompewter> [ https://github.com/DSpace/DSpace/pull/1624 ] - [DS-3456] 6x Fix Command Line Parameters for statistics import/export tools by terrywbrady
[15:37] <tdonohue> So, with 1624, looks like we'll need updated docs, as there are new flags here (of course). This is kinda an improvement / bug fix...but, still seems OK to me for a minor release
[15:38] <terry-b> Once these are merged, I will update the docs. I may add some addition notes about testing that are captured here:https://wiki.duraspace.org/display/~terrywbrady/Statistics+Import+Export+Issues
[15:38] <kompewter> [ Statistics Import Export Issues - Terry Brady - DuraSpace Wiki ] - https://wiki.duraspace.org/display/~terrywbrady/Statistics+Import+Export+Issues
[15:38] <mhwood> I like the improvements to the error messages.
[15:39] <terry-b> We will likely also need a release notes section informing users how to repair corrupted shards.
[15:39] <tdonohue> terry-b++ (Yes, your wiki page notes would help inform what updates to add to the docs...and adding notes to the Upgrade instructions/release notes on repair would be excellent)
[15:40] <tdonohue> So, 1624 looks good to me, and was tested by kshepherd. So, I think this looks ready too. Any objections/comments from mhwood or hpottinger?
[15:40] <mhwood> No objections.
[15:41] <tdonohue> Ok, I'm going to approve and merge these PRs too. While I'm doing that, I just realized we have *ANOTHER* related sharding PR... DSPR#1613 (at +1)... could you all review that next?
[15:41] <kompewter> [ https://github.com/DSpace/DSpace/pull/1613 ] - DS-3436 Sharding SOLR cores corrupts multivalued fields by tomdesair
[15:42] <terry-b> This one looks good to me. The conversation on this ticket led to the discovery of all the other issues we have reviewed
[15:43] <terry-b> If this is approved, I will take a todo to port this to master and to 5.7
[15:44] <mhwood> 1613 looks sensible, but I'd have to study Solr quite a bit to say more.
[15:46] <hpottinger> I tossed a +1 on 1613
[15:47] <terry-b> Looking at the status of https://github.com/DSpace/DSpace/pull/1625, is this indicating that the branch may need some fixing?
[15:48] <terry-b> I will work on that
[15:48] <tdonohue> terry-b: yes, you need to rebase #1625...it won't merge as-is, as it included some commits from another PR (and I think that other PR had updates)
[15:48] <tdonohue> once 1625 is rebased, I'll merge it. Just ping me on it
[15:48] <tdonohue> I've also merge 1613 (as it looks good to me too
[15:49] <tdonohue> So, I *think* (besides 1625's conflicts) all the PRs relating to Solr shards/bugs have now been merged. terry-b, could you close all the JIRA tickets once you've updated documentation?
[15:49] <terry-b> Will do. Thanks for all the time today
[15:49] <tdonohue> Thanks for the reviews here today all! I was hoping to get some of these PRs merged soon ;)
[15:50] <tdonohue> So, are there other PRs/JIRA tickets we wish to discuss today? Anything else we can help move along?
[15:51] <terry-b> https://github.com/DSpace/DSpace/pull/1625/ is running through travis
[15:51] <kompewter> [ [DS-3458]5x Allow Shard Process to Append to an existing repo by terrywbrady · Pull Request #1625 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1625/
[15:53] <mhwood> Trying to recall why I'm assigned DS-3367
[15:53] <kompewter> [ https://jira.duraspace.org/browse/DS-3367 ] - [DS-3367] Configurable Workflow authorization denied error - DuraSpace JIRA
[15:54] <tdonohue> mhwood: maybe it was to test the related PR?... DSPR#1596
[15:54] <kompewter> [ https://github.com/DSpace/DSpace/pull/1596 ] - DS-3367: Fix authorization error on claim by non-admin user by tomdesair
[15:54] <mhwood> Must be.
[15:54] <tdonohue> That PR looks tiny to me, and seems like it's also likely correct.
[15:55] <terry-b> I need to run to a meeting. Thanks for the reviews today.
[15:55] <tdonohue> So, we could just merge it...or if you could give a quick test before merging, that'd be great too, mhwood
[15:56] <tdonohue> terry-b: thank you for your hard work on the Solr shard stuff! later
[15:56] <mhwood> OK I will test, and merge if it works?
[15:56] <tdonohue> +1 yes, please merge if works
[15:56] <mhwood> Will do.
[15:56] <tdonohue> Thanks!
[15:57] <mhwood> Wondering about DS-3469 status.
[15:57] <kompewter> [ https://jira.duraspace.org/browse/DS-3469 ] - [DS-3469] virus scan during submission attempts to read uploaded bitstream as anonymous user, which fails - DuraSpace JIRA
[15:58] <mhwood> DSPR#1632 is +1.
[15:58] <kompewter> [ https://github.com/DSpace/DSpace/pull/1632 ] - [DS-3469] virus scan during submission attempts to read uploaded bitstream as anonymous user, which fails by mwoodiupui
[15:58] <tdonohue> As we are nearing the end of the meeting, I thought I'd mention we have a LOT of recent "quick win" PRs coming in the door. I'm starting to wonder if we just give some of these quick code reviews (assuming Travis doesn't complain) and merge them...as we have a growing backlog of "quick wins"
[15:58] <tdonohue> (Admittedly it may be a case by case basis on how tiny the "quick win" is though)
[15:58] <tdonohue> mhwood: I'll review that PR
[15:58] <mhwood> Thanks!
[16:00] <tdonohue> 1632 looks good, will merge
[16:00] <tdonohue> Would appreciate thoughts on "quick win" analysis...we have 24 quick win PRs already (and I haven't even gotten through flagging them all yet)
[16:00] <hpottinger> tdonohue: wanna spend backlog hour on quick wins?
[16:01] <tdonohue> sure, we could do that. I'm free for backlog today
[16:01] <hpottinger> I have backlog hour on my calendar for today, my day is completely full of meetings
[16:02] <tdonohue> Ok, let's close out the formal meeting then. We'll move over to Backlog Hour (in #dspace) and we can dig through our PR backlog today and see if we can move some along / merge
[16:06] * ntorres (c1895861@gateway/web/freenode/ip. Quit (Quit: Page closed)
[18:18] * terry-b (~chrome@97-113-118-39.tukw.qwest.net) Quit (Ping timeout: 264 seconds)
[21:20] * hpottinger (~hpottinge@ Quit (Ping timeout: 240 seconds)
[21:20] * hpottinger (~hpottinge@ has joined #duraspace
[22:00] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:28] * dyelar (~dyelar@biolinux.mrb.ku.edu) Quit (Quit: Leaving.)
[22:32] * tdonohue (~tdonohue@dspace/tdonohue) has left #duraspace
[22:33] * hpottinger (~hpottinge@ Quit (Quit: Leaving, later taterz!)

These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.