Timestamps are in GMT/BST.
[6:31] -bear.freenode.net- *** Looking up your hostname...
[6:31] -bear.freenode.net- *** Checking Ident
[6:31] -bear.freenode.net- *** Found your hostname
[6:31] -bear.freenode.net- *** No Ident response
[6:31] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:31] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:31] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[9:22] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[13:25] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:02] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[15:35] * NTorres (c1895861@gateway/web/freenode/ip.193.137.88.97) has joined #duraspace
[16:08] * peterdietz (uid52203@gateway/web/irccloud.com/x-iesabrwwoihpysng) has joined #duraspace
[16:50] * NTorres (c1895861@gateway/web/freenode/ip.193.137.88.97) Quit (Quit: Page closed)
[19:00] * hpottinger (~hpottinge@vpn-128-97-245-147.host.ucla.edu) has joined #duraspace
[19:25] * cwilper (~user@cpe-74-74-245-64.rochester.res.rr.com) has joined #duraspace
[19:55] * tdonohue notes DevMtg will start in ~5mins (top of hour). Agenda at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-01-04
[19:59] * bram_ (~bram@94-225-37-203.access.telenet.be) has joined #duraspace
[20:00] <tdonohue> Hi all, happy new year! It's our first DSpace DevMtg of the new year, and we've got a big agenda here (though much of it is reviewing status of 6.0 tickets): https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-01-04
[20:00] <kompewter> [ DevMtg 2017-01-04 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-01-04
[20:01] <hpottinger> Happy New Year!
[20:01] <tdonohue> Rather than starting with DSpace 6... I first want to *briefly* draw your attention to DSpace 7 notes (topic #3 on agenda).
[20:02] <tdonohue> I'm not going to retype the notes here, but I do want to mention the next DSpace 7 Mtg is on Jan 12 @ 15UTC. Also, we'll be doing a call for participation soon to try to find other interested developers
[20:02] <tdonohue> (so keep an eye on the lists for that)
[20:04] <tdonohue> We've also been discussing (behind the scenes) creating a Slack org for DSpace. I'll be emailing Committers about that, and hopefully have something to announce publicly soon
[20:04] <tdonohue> Finally, Committers should add comments to DS-3422 (I'll also be emailing about this), as it's necessary to move forward with DSpace 7 REST API (if we want to use latest Spring, etc)
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-3422 ] - [DS-3422] Remove XMLUI and JSPUI from the official distribution - DuraSpace JIRA
[20:05] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[20:05] <hpottinger> tdonohue: do we need to vote on that?
[20:05] <tdonohue> that's it for the DSpace 7 updates...there's quite a few of them though, and I'm glad to take questions (if any). Otherwise, you can also ask questions on -devel or join the next meeting on Jan 12
[20:06] <tdonohue> hpottinger: 3422 will need approval, yes. But, it'll be run like any other code approval...needs two +2s and no vetoes
[20:06] <tdonohue> two +1s that is ;)
[20:07] <tdonohue> but, yes, I'll email -commit to ensure everyone is aware that it is coming, and offer the opportunity for questions/concerns to be expressed, etc
[20:07] * hpottinger wanders off to find the PR
[20:07] <tdonohue> And once approved by committers, I'll also email -devel to let folks there know it is coming too ;)
[20:07] <hpottinger> DSPR#1597
[20:07] <kompewter> [ https://github.com/DSpace/DSpace/pull/1597 ] - DS-3422 Remove XMLUI and JSPUI from the official distribution by abollini
[20:08] <bram_> one question about this:
[20:08] <bram_> (and happy new year everyone ;) )
[20:08] <tdonohue> wow, -253,156 lines of code! :)
[20:08] <hpottinger> "files changed: 1,469"
[20:08] <tdonohue> go ahead, bram_
[20:08] <bram_> once this happens, do we still intend to keep master up to par with all improvements/bugfixes that come into the 6_x maintenance branch?
[20:08] * tom_desair (~tom@d8D874131.access.telenet.be) has joined #duraspace
[20:08] <bram_> I realise that might be difficult if they're going to be on different hibernate versions etc
[20:09] <bram_> My colleague tom also had concerns about this, and I'm happy to see that he just joined ;)
[20:09] <tdonohue> bram_: yes, API or REST (or other non-UI) fixes should be "forward-ported" from "dspace-6_x" maintenance branch to "master".
[20:10] <mhwood> Clearly there will be patches that we want to bring forward, but it's also clear that there may be patches to 6_x that make no sense for 7_x. We will have to take it case-by-case, I think.
[20:10] <tdonohue> That's no different from how we've done things in the past...although, in this case, we won't be porting UI fixes, and some forward-porting may require refactoring (cause of different versions of Hibernate and Spring)
[20:11] <hpottinger> or not necessary
[20:11] <tdonohue> mhwood: correct. Some fixes will make no sense to forward-port (if the code is entirely refactored, or the fixes are UI specific). Others should be ported
[20:11] <bram_> you're right, it's no different than how it happened in the past
[20:12] <bram_> Just thinking of what the most efficient flow might be to get fixes into 4x, 5x, 6x and master
[20:12] <mhwood> Hewing to JPA and CDI rather than product-specific things will help.
[20:12] <tdonohue> Exactly. It may be a slightly more careful balancing act here...since master may start moving rather quickly (at times)...and we'll still have fixes going into "dspace-6_x"
[20:12] <tom_desair> But having no UI available will make it difficult to test or develop fixes for the open Jira tickets.
[20:13] <mhwood> Ah, but that's where attention to our test suites will pay well.
[20:13] <tom_desair> So all current (and future) pull requests will need to go to dspace_6x?
[20:13] <hpottinger> well... hopefully that itch will bring some devs to scratch it
[20:14] <tdonohue> tom_desair: any pull requests relating to existing UIs should go to dspace_6x... correct. And, there will obviously be a UI for "master", but it'll be a work in progress for some time
[20:14] <mhwood> We'll need a set of tests to exercise REST. We can pay a little more attention to building code that is easy to drive with unit tests.
[20:14] <tdonohue> I also agree we'll need to get better at requiring unit tests on master. They will prove things work
[20:15] <tom_desair> Thus porting DSpace 6 fixes to master will have to wait untill there is a new UI so you can validate them
[20:15] <mhwood> That depends on what was fixed.
[20:16] <tdonohue> And in fact, I'd suggest that be the rule... Once XMLUI & JSPUI are removed, we REQUIRE unit (or integration) tests. Those can be what "validates" the fix, tom_desair
[20:16] <mhwood> Exactly. That's when I tend to write tests: when I am working on something that I'll need to test.
[20:16] <hpottinger> Oh, DSPR#1597 will impact the Remote-Handle-Resolver, which is, I'll admit, a "production" kind of tool, but, it does have a dependency on the existing UIs
[20:16] <kompewter> [ https://github.com/DSpace/DSpace/pull/1597 ] - DS-3422 Remove XMLUI and JSPUI from the official distribution by abollini
[20:17] <bram_> In JIRA, I think you can set multiple "Fix Version/s" in the field. We could leave the issues open in JIRA until the merge has happened in all of the versions that ar marked as fix versions
[20:17] <tdonohue> Don't get me wrong, there may be some edge cases here or difficulties that come up (and we'll look at them one by one). But, that'd be the general rule I'd want in place
[20:17] <tom_desair> That would be great, but the backend requires some more refactoring to make it easier to write unit tests. At the moment the context object (which requires a DB connection) makes it difficult to test things.
[20:17] <bram_> indicating whether we want the fixes in master, 6_x, 5_x and potentially 4_x if it's security related. We'll just have to be careful about that fix versions field and not close issues before they are merged in all target versions.
[20:18] <mhwood> One reason for that is that many of our "unit" tests are not unit tests.
[20:18] <tom_desair> I agree mhwood
[20:18] <tdonohue> bram_ is correct, we can add multiple "fix versions" in JIRA and use that as a tracking tool
[20:19] <bram_> take this one for example: https://jira.duraspace.org/browse/DS-3435
[20:19] <kompewter> [ https://jira.duraspace.org/browse/DS-3435 ] - [DS-3435] possible nullpointerexception at AccessStepUtil$populateEmbargoDetail - DuraSpace JIRA
[20:19] <kompewter> [ [DS-3435] possible nullpointerexception at AccessStepUtil$populateEmbargoDetail - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3435
[20:19] <tdonohue> tom_desair: completely understand the frustration there...and I'd encourage folks to help fix it. But, it's hard to fix the unit tests now, but may be possible to fix/cleanup some during the refactor (or post-refactor)
[20:20] <bram_> affects versions should actually say 6.0 and "master" since 7.0 is not released, and target fix versions should be 6.1 and 7.0
[20:20] <tdonohue> I just don't see any other way to approach this big effort. We cannot hold back the DSpace 7 team, and that means removing the UIs from master. It may end up being bumpy at times, but we'll get it smoothed out as DSpace 7 gets further along
[20:21] <hpottinger> I think we can jump the ravine
[20:21] <tom_desair> Yes I think that DSpace 7 offers the possibility to apply another refactor iteration (like the services refactoring), but doing a major refactoring when DSpace 6 fixes are still coming in will make it harder.
[20:22] <mhwood> Some of the testing work should be back-portable. That may make maintenance easier.
[20:23] <tdonohue> yes, I agree it'll be harder, but at the same time, we made it work for DSpace 5 -> 6. The DSpace 6 services refactoring was happening while DSpace 5 fixes were still coming in. It did make things harder initially, but after a while we figured it out.
[20:24] <tdonohue> This one might be just as complex or more so (with a new UI), but we'll make it work. It'll smooth out, and I hope we'll find *more* participants (on the DSpace 7 side) to help smooth things out more quickly
[20:24] <bram_> +1 on removing jspui and xmlui now, for the reason of being able to bump hibernate and spring to move forward.
[20:24] <bram_> didn't review/build the pull request though
[20:25] * hpottinger is spinning up Vagrant-DSpace to test DSPR#1597
[20:25] <kompewter> [ https://github.com/DSpace/DSpace/pull/1597 ] - DS-3422 Remove XMLUI and JSPUI from the official distribution by abollini
[20:25] <tdonohue> I'll email -commit about this too. We don't have to all vote here, but thanks for opinion anyhow :)
[20:25] <tdonohue> Ok. So, we should step back and talk about some of the DSpace 6 fixes, if we don't have further DSpace 7 questions or topics?
[20:26] <mhwood> OK
[20:27] <tom_desair> OK
[20:28] <tdonohue> Ok, then... before jumping into the list of 6.0 tickets, I do want to draw Committer attention to the recent security issue reported: https://jira.duraspace.org/browse/DS-3431 (This ticket is not publicly viewable, as it still requires a test of the proposed fix and formal public announcement)
[20:28] <kompewter> [ https://jira.duraspace.org/browse/DS-3431 ] - ('Unexpected error:', <type 'exceptions.AttributeError'>)
[20:28] <kompewter> [ Log in - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3431
[20:29] <tdonohue> I'd recommend Committers take a look at that soon (if possible) and give it a test, and/or help out pbecker. He said he'll have a patch ASAP (looks like he dropped off for today though, and I'm not sure his patch is posted yet)
[20:30] <tdonohue> In any case, please watch that space Committers. We could use more help/eyes here. Moving along now...
[20:30] <tdonohue> Starting from the top of our (growing) list of 6.0 tickets in the agenda.... DS-3435
[20:30] <kompewter> [ https://jira.duraspace.org/browse/DS-3435 ] - [DS-3435] possible nullpointerexception at AccessStepUtil$populateEmbargoDetail - DuraSpace JIRA
[20:31] <tdonohue> This has two PRs (for different versions)... DSPR#1599 and DSPR#1600
[20:31] <kompewter> [ https://github.com/DSpace/DSpace/pull/1599 ] - DS-3435 possible nullpointerexception at AccessStepUtil$populateEmbar… by samuelcambien · Pull Request #1599 · DSpace/DSpace · GitHub
[20:31] <kompewter> [ https://github.com/DSpace/DSpace/pull/1600 ] - DS-3435 possible nullpointerexception at AccessStepUtil$populateEmbar… by samuelcambien · Pull Request #1600 · DSpace/DSpace · GitHub
[20:31] <tdonohue> It needs a reviewer (or two). Any volunteers to help this along?
[20:31] <bram_> this is from one of our colleagues
[20:31] <tdonohue> It seems like a tiny change to me, so I'll gladly give it a code review on my end
[20:31] <bram_> so we're good with this, but should ideally be a non-atmire committer that merges this
[20:32] <bram_> as we don't want to merge our own contribs if we can avoid it
[20:33] <tdonohue> huh, it looks like Travis is not running properly on DSPR#1600. Cannot seem to restart Travis either (not sure why)
[20:33] <kompewter> [ https://github.com/DSpace/DSpace/pull/1600 ] - DS-3435 possible nullpointerexception at AccessStepUtil$populateEmbar… by samuelcambien · Pull Request #1600 · DSpace/DSpace · GitHub
[20:33] <mhwood> +1 by inspection.
[20:34] <tom_desair> Idem, adding an extra null check doesn’t do any harm
[20:35] <bram_> I don't see 1600 here https://travis-ci.org/DSpace/DSpace/pull_requests
[20:35] <kompewter> [ Travis CI - Test and Deploy Your Code with Confidence ] - https://travis-ci.org/DSpace/DSpace/pull_requests
[20:35] <bram_> weird
[20:36] <tdonohue> bram_: yes, it almost seems like Travis never got notified of that PR...maybe it was a random blip. Perhaps you could ask samuelcambien to either recreate the PR, or try rebasing the branch and pushing it back up (if any other changes have happened on master)
[20:37] <tdonohue> I've never seen Travis do this before, so I'm hoping updating the branch (or recreating the PR) will kick Travis into gear
[20:38] <tdonohue> merge 1599
[20:38] <tdonohue> merged 1599 (i mean)
[20:39] <tdonohue> ok, moving along for now... once 1600 gets Travis approval, I'll merge it. (I really prefer Travis approval)
[20:39] <tdonohue> next ticket up, DS-3425
[20:39] <kompewter> [ https://jira.duraspace.org/browse/DS-3425 ] - [DS-3425] outputstream gets closed in JSONDiscoverySearcher - DuraSpace JIRA
[20:39] <tdonohue> DSPR#1589
[20:39] <kompewter> [ https://github.com/DSpace/DSpace/pull/1589 ] - DS 3425 outputstream gets closed in JSONDiscoverySearcher by samuelcambien
[20:41] <bram_> for that one, the PR against 6_x is good, but I had to close the PR against dspace 5
[20:41] <hpottinger> I recall looking at this a while ago
[20:41] <bram_> so the one against 6 can be merged, but we have to leave the jira open to take care of 5_x
[20:42] <tdonohue> The change in 1589 seems tiny, but this seems like it needs a closer look to verify that "close()" really is unwanted
[20:43] <hpottinger> https://github.com/samuelcambien/DSpace/commit/738f6eaca28b1043cb702f92882322aedf369951#diff-7586e5dae6895cbe239e7d5ebe811796R137
[20:43] <kompewter> [ [DS-3246] Improve cleanup in recyclable components · samuelcambien/DSpace@738f6ea · GitHub ] - https://github.com/samuelcambien/DSpace/commit/738f6eaca28b1043cb702f92882322aedf369951#diff-7586e5dae6895cbe239e7d5ebe811796R137
[20:43] <tdonohue> Anyone want to take a closer look at 1589 and/or give it a test
[20:43] <tdonohue> ?
[20:43] <hpottinger> "Blame" let me to that commit
[20:44] <tdonohue> looks likely accidental then, based on that result from "blame"
[20:44] <tdonohue> i.e. it didn't exist before, and suddenly was added with no explanation during a refactor
[20:45] <hpottinger> I think that was part of the bug fix for DS-3246
[20:45] <kompewter> [ https://jira.duraspace.org/browse/DS-3246 ] - [DS-3246] Recyclable Cocoon components should clear local variables - DuraSpace JIRA
[20:45] <tdonohue> ok, well, this needs more analysis in my opinion. hpottinger, you interested in looking at this closer?
[20:46] <tdonohue> My gut tells me the fix is likely correct. But, I'll admit, I'm not going to have time myself to dig in here and test this out further
[20:46] <tom_desair> Maybe we should try moving the “out.close()” call to the recycle method.
[20:47] <mhwood> Yeah, six .close() calls were added in that patch.
[20:47] <hpottinger> I will ping Andrea Schweer and ask her, it's her work and she has been running that code in production for a while
[20:47] <tdonohue> ok, thanks hpottinger.
[20:48] <tdonohue> moving along to DS-3418
[20:48] <kompewter> [ https://jira.duraspace.org/browse/DS-3418 ] - [DS-3418] DSpace Build Error When Git is Not Present - DuraSpace JIRA
[20:48] <tdonohue> This one needs a volunteer still. It's not high priority, but if anyone is interested, it needs investigation!
[20:49] <tdonohue> moving along for now... DS-3410
[20:49] <kompewter> [ https://jira.duraspace.org/browse/DS-3410 ] - [DS-3410] Indexes are lost at oracle - DuraSpace JIRA
[20:50] <mhwood> Woops, that one is assigned to me. I need to get to work on it.
[20:50] <tdonohue> mhwood: you are assigned to this one... are you still doing a code review here? This would be one that we should get into a 6.1 release (if possible)
[20:50] <tdonohue> the next one is also mhwood (and a related issue): DS-3409
[20:50] <kompewter> [ https://jira.duraspace.org/browse/DS-3409 ] - [DS-3409] Handle of collections and communities are lost during migration using oracle - DuraSpace JIRA
[20:51] <tdonohue> moving along...DS-3406
[20:51] <kompewter> [ https://jira.duraspace.org/browse/DS-3406 ] - [DS-3406] Sub-communities and collections not sorted alphabetically - DuraSpace JIRA
[20:51] <tdonohue> I'd consider this one a high priority to fix (as it's unexpected behavior). Any volunteers for it?
[20:52] <tom_desair> You can assign it to me, it shouldn’t be too hard
[20:52] * tdonohue is realizing I need to take some time between meetings to reorg this list into "high priority" vs lower priority
[20:53] <tdonohue> Thanks, tom_desair!
[20:53] <tdonohue> moving along then... DS-3389 is still a known issue (assigned to hpottinger)
[20:53] <kompewter> [ https://jira.duraspace.org/browse/DS-3389 ] - [DS-3389] Replication Task Suite add-on doesn't work with DSpace 6 API - DuraSpace JIRA
[20:54] <tdonohue> Any updates, hpottinger? Or still working on it?
[20:54] <tdonohue> ok, assuming you are working on it
[20:55] <tdonohue> next up, DS-3381
[20:55] <kompewter> [ https://jira.duraspace.org/browse/DS-3381 ] - [DS-3381] Blocking error trying the versioning system - DuraSpace JIRA
[20:55] <hpottinger> oh, sorry, distracted by doorbell
[20:55] <tdonohue> This one needs a volunteer & seems to be a higher priority
[20:55] <tdonohue> Anyone interested?
[20:55] <hpottinger> no updates on 3389, other than I need to set up an IDE, and am taking suggestions
[20:56] <tdonohue> Please suggest IDE options outside of this meeting (that's quite a discussion topic!) ;)
[20:56] <tdonohue> So, 3381 needs a volunteer if anyone finds time.
[20:56] <bram_> just reproduced it on demo.dspace.org
[20:57] <tdonohue> moving along for now (as we are short on time here)... DS-3367
[20:57] <kompewter> [ https://jira.duraspace.org/browse/DS-3367 ] - [DS-3367] Configurable Workflow authorization denied error - DuraSpace JIRA
[20:58] <tdonohue> This one is now under code review (changing status now): DSPR#1596
[20:58] <kompewter> [ https://github.com/DSpace/DSpace/pull/1596 ] - DS-3367: Fix authorization error on claim by non-admin user by tomdesair
[20:58] <tdonohue> mhwood: you were assigned to this ticket, any chance you could help with code review on the PR?
[20:59] <mhwood> It's on my list.
[20:59] <bram_> (3381 doesn't seem to affect jspui)
[20:59] <tdonohue> thanks, mhwood!
[21:00] <tdonohue> bram_: feel free to add a comment to the ticket then on what you've found and/or how to reproduce on demo
[21:01] <bram_> DS-3367: can a non-atmire committer merge tom's PR's ?
[21:01] <kompewter> [ https://jira.duraspace.org/browse/DS-3367 ] - [DS-3367] Configurable Workflow authorization denied error - DuraSpace JIRA
[21:02] <tdonohue> Ok, we're not going to make it through all these tickets today. The next 6 all need Code reviews (we could use some testers/reviewers!)
[21:02] <tdonohue> bram_: mhwood said he'd review 3367
[21:02] <bram_> ah ok tnx
[21:03] <tdonohue> The last one on our list is also new... DS-3436 (needs volunteer)
[21:03] <kompewter> [ https://jira.duraspace.org/browse/DS-3436 ] - [DS-3436] Statistics Shard Corrupts owningComm field - DuraSpace JIRA
[21:04] <tdonohue> Sorry, I've skipped a lot of tickets there...I need to reorganize these for next week. But, I think it's rather easy in the wiki to see which "need code review", and it'd be good to find volunteers to do some reviews this week
[21:05] <terry-b> This issue has been present for a couple of years. We ran our shard today. Another long standing bug in the shard process is that the shard names are off by 1 digit. Our 2016 records were migrated into the statistics-2015 shard.
[21:06] <tdonohue> terry-b: thanks for noting this. Hopefully we can find someone to dig into this further, as it sounds like a not so fun bug :(
[21:07] <hpottinger> I've been meaning to look at the stats on our pilot repository, it has only been running since mid-2016, but it has shards
[21:07] <terry-b> I will log a separate ticket for the shard name issue and link it. If we have to build a shard repair tool, it would be a good time to apply that fix as well.
[21:08] <tom_desair> You can also assign the shard issue to me. If I don’t find it myself, I know some SOLR experts at Atmire that can help me ;-)
[21:08] <hpottinger> it's likely that the existing stats export/import/reindex tool can be modified to address this issue
[21:08] <bram_> it might be going on here: https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace-api/src/main/java/org/dspace/statistics/SolrLoggerServiceImpl.java#L1188
[21:08] <kompewter> [ DSpace/SolrLoggerServiceImpl.java at dspace-6_x · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace-api/src/main/java/org/dspace/statistics/SolrLoggerServiceImpl.java#L1188
[21:09] <tdonohue> One last thing to mention, before we close here. I have some increased time for DSpace in January (as opposed to late last year), so I should be able to do more coordination/mgmt work and some code reviews. Unclear if I'll have enough time to do much coding quite yet, but it's a step in the right direction.
[21:09] <hpottinger> tom_desair and bram_: I was hoping that you all might have a trick up your sleeves for this
[21:09] <hpottinger> hooray, tdonohue is back!
[21:10] <bram_> great news
[21:10] <tdonohue> I'm not going to bring up any other topics for today...but feel free to continue discussions here as long as needed.
[21:10] <tom_desair> I still need to create a Jira ticket for this: https://groups.google.com/forum/#!topic/dspace-tech/tBNckjJ0ocE
[21:10] <kompewter> [ Google Groups ] - https://groups.google.com/forum/#!topic/dspace-tech/tBNckjJ0ocE
[21:10] <hpottinger> My brain tells me we have two camps of IDE users: IntelliJ IDEA and Netbeans
[21:10] <tdonohue> Well, I'm "back" to coordinator role(s). But, you cannot count on me to volunteer to code anything yet ;) Still, it's a step in the right direction
[21:11] <tom_desair> It seems there are still some hibernate problems if you have a largo community-collection tree. Those users send me more details off list, and I’ll try to reproduce their problem.
[21:12] <tdonohue> hpottinger: when I use a Java IDE, I use NetBeans...that said, I admit to not always using an IDE, unless I'm hitting an issue I truly need to step through with a debugger. We still have free IntelliJ licenses for Committers though
[21:13] <terry-b> https://jira.duraspace.org/browse/DS-3437 has been created.
[21:13] <kompewter> [ https://jira.duraspace.org/browse/DS-3437 ] - [DS-3437] When sharding statistics, the destination shard name is off by one year - DuraSpace JIRA
[21:13] <kompewter> [ [DS-3437] When sharding statistics, the destination shard name is off by one year - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3437
[21:14] <terry-b> tom_desair, I added a comment that you volunteered for https://jira.duraspace.org/browse/DS-3436. I am unable to assign you to the ticket.
[21:14] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3436.
[21:14] <kompewter> [ https://jira.duraspace.org/browse/DS-3436 ] - [DS-3436] Statistics Shard Corrupts owningComm field - DuraSpace JIRA
[21:15] <tom_desair> We always use IntelliJ. It has very good search and code completion capabilities.
[21:17] <tom_desair> https://www.youtube.com/watch?v=mrLl1qPsy6I
[21:17] <kompewter> [ IntelliJ IDEA 13 setup for DSpace development on Mac OS X - YouTube ] - https://www.youtube.com/watch?v=mrLl1qPsy6I
[21:18] <bram_> might be worth while to update that video soonish
[21:18] <bram_> especially because it doesn't cover local.cfg that got in with DSpace 6
[21:19] <bram_> got to go - have a good day & evening
[21:19] <peterdietz> bye all
[21:19] <hpottinger> bye!
[21:19] <kompewter> see ya!
[21:19] * bram_ (~bram@94-225-37-203.access.telenet.be) Quit (Quit: bram_)
[21:19] * hpottinger (~hpottinge@vpn-128-97-245-147.host.ucla.edu) Quit (Quit: Leaving, later taterz!)
[21:22] <tom_desair> I’m also leaving, have a nice day!
[21:22] * tom_desair (~tom@d8D874131.access.telenet.be) has left #duraspace
[21:22] * tom_desair (~tom@d8D874131.access.telenet.be) has joined #duraspace
[21:23] * tom_desair (~tom@d8D874131.access.telenet.be) has left #duraspace
[22:01] * cwilper (~user@cpe-74-74-245-64.rochester.res.rr.com) Quit (Quit: cwilper)
[22:12] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[22:49] * tdonohue (~tdonohue@dspace/tdonohue) Quit (Read error: Connection reset by peer)
[23:42] * cwilper (~user@50.49.122.146) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.