Timestamps are in GMT/BST.
[0:21] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Remote host closed the connection)
[1:10] * terry-b3 (~chrome@71-212-101-240.tukw.qwest.net) has joined #duraspace
[1:10] * terry-b (~chrome@71-212-101-240.tukw.qwest.net) Quit (Read error: Connection reset by peer)
[2:22] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[2:26] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 268 seconds)
[4:23] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[4:28] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 250 seconds)
[6:24] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[6:29] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 276 seconds)
[6:59] -tepper.freenode.net- *** Looking up your hostname...
[6:59] -tepper.freenode.net- *** Checking Ident
[6:59] -tepper.freenode.net- *** Found your hostname
[7:00] -tepper.freenode.net- *** No Ident response
[7:00] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[7:00] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[7:00] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:49] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[7:50] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Remote host closed the connection)
[7:50] * Insanity_ (~Insanity@86.39.200.115.static.hosted.by.easyhost.be) has joined #duraspace
[8:02] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[12:09] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:07] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) has joined #duraspace
[14:15] * th5 (~th5@unaffiliated/th5) has joined #duraspace
[14:39] * hpottinger (~hpottinge@mu-161168.dhcp.missouri.edu) has joined #duraspace
[14:43] * ChanServ (ChanServ@services.) Quit (*.net *.split)
[14:55] * ChanServ (ChanServ@services.) has joined #duraspace
[15:43] * Insanity_ (~Insanity@86.39.200.115.static.hosted.by.easyhost.be) Quit (Remote host closed the connection)
[17:36] * terry-b3 (~chrome@71-212-101-240.tukw.qwest.net) Quit (Remote host closed the connection)
[17:36] * terry-b (~chrome@71-212-101-240.tukw.qwest.net) has joined #duraspace
[17:44] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[17:48] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 250 seconds)
[17:50] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[18:46] <hpottinger> I just now figured out I have a conflicting meeting that was scheduled over the weekly Dev Meeting, so I'll be attempting to do both today
[18:48] <hpottinger> bbl
[18:48] * hpottinger (~hpottinge@mu-161168.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[19:07] * hpottinger (~hpottinge@161.130.188.172) has joined #duraspace
[19:58] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[20:00] <tdonohue> Hi all, welcome. it's DSpace DevMtg time. https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-04-27
[20:00] <kompewter> [ DevMtg 2016-04-27 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-04-27
[20:01] <tdonohue> We seem to be a bit of a small group today...
[20:01] <tdonohue> our agenda is mostly just checking in on Testathon updates/issues/PRs, etc
[20:02] <tdonohue> Prior to this meeting, in #dspace, we had started to review the JIRA tickets labeled "testathon". https://jira.duraspace.org/browse/DS-3184?jql=labels%20%3D%20testathon
[20:02] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3184?jql=labels%20%3D%20testathon
[20:02] <kompewter> [ https://jira.duraspace.org/browse/DS-3184 ] - [DS-3184] Adding a new bitstream format fails - JSPUI Test Plan Ref ADM18 - DuraSpace JIRA
[20:03] <tdonohue> Overall, I'd say there's been a lot of great testing here (and thanks to everyone who has done testing, and especially to DCAT folks for creating some Test Plans for both UIs)
[20:04] <mhwood> It's good to have a plan.
[20:04] <tdonohue> There is some repetition to the issues at hand...quite a few NPE ones, UUID issues, etc. (all seemingly related back to the Service API refactor). Quite a few also seem low hanging, so hopefully they are solvable quickly
[20:05] <tdonohue> Since it looks like we have mostly the same group here (as was in #dspace), perhaps we should start from the *bottom* of our list (earliest issues noted), and review a few there that already have possible PRs (plus there's some bigger issues there)
[20:06] <mhwood> I'd like to note in passing that two of these are already at Code Review.
[20:07] <tdonohue> yep, I was going to jump to the code review ones first, in fact. I'd like to get PRs merged, so we can concentrate on solving other issues
[20:07] <terry-b> Im here if you have questions on those
[20:07] <tdonohue> here's one... DS-3145 / DSPR#1366
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-3145 ] - [DS-3145] DSpace REST reports assume /handle - need to consider /xmlui/handle or /jspui/handle on demo.dspace.org - DuraSpace JIRA
[20:07] <kompewter> [ https://github.com/DSpace/DSpace/pull/1366 ] - [DS-3145] Configure rootpath in REST Reports (/handle, /xmlui/handle, /jspui/handle) by terrywbrady
[20:08] <tdonohue> In the PR here, I just gave a +1. I like that this pulls the path out into a config. It's also nice to have a default that happens to work on demo.dspace.org
[20:09] <terry-b> Since this is running at the javascript layer, I am less certain how to pull a config value
[20:09] <terry-b> We would almost need a /rest/config endpoint
[20:10] <hpottinger> that's kind of a cool idea, actually
[20:10] <tdonohue> For now, this seems "good enough". Have you tested it terry-b?
[20:10] <terry-b> I have tested it
[20:10] <tdonohue> FWIW, we probably *will* end up with a REST config endpoint at some point in time...but it's too late for 6.x for that.
[20:10] <mhwood> It does at least manifest the path in a single place.
[20:11] <tdonohue> so, I'm in favor of 1366. It seems like a clean solution until we have a REST config endpoint
[20:11] <terry-b> I will create a ticket (for the future to suggest a rest config endpoint)
[20:11] <mhwood> It's +2 now.
[20:12] <tdonohue> terry-b: sounds like you should go ahead and merge it then. Thanks
[20:12] <terry-b> Will do
[20:12] <mhwood> Hmmm. Config includes things like db.password.
[20:13] <mhwood> API keys and such.
[20:13] <terry-b> I would imagine a very controlled set
[20:13] <mhwood> Indeed.
[20:13] <tdonohue> mhwood: right, I'm not saying a REST config would share *everything*. It'd just share configs needed by the UI display layer
[20:13] <terry-b> The merge put 1369 in conflict. It will be easy to resolve
[20:14] <tdonohue> we can move on to that one... DS-3170 / DSPR#1369
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-3170 ] - [DS-3170] Rest Report Tools - Allow Password Auth If Configured - DuraSpace JIRA
[20:14] <kompewter> [ https://github.com/DSpace/DSpace/pull/1369 ] - [DS-3170] Allow Password Auth to be enabled for Rest Reports by terrywbrady
[20:15] <terry-b> This is a bit of a fix/ a bit of a feature. I will defer to you all if this looks good to merge
[20:16] <tdonohue> terry-b: just a general note...in GitHub it looks like your lines are all aligned oddly (probably spaces vs tabs in your IDE). It's not a huge deal, but just something you might want to look at in your IDE at some point
[20:16] <terry-b> I have a new computer, and I have not reset those preferences everywhere. I noticed that as well.
[20:17] <tdonohue> yep, it happens. No big deal. I just sometimes have a harder time reading code when it's misaligned ;)
[20:17] <mhwood> "Not just you" says Mr. Picky Reader.
[20:18] <terry-b> What is the magic incantation in git to rebase a branch?
[20:19] <tdonohue> git checkout master (switch to master); git remote update (pulls down latest from upstream); git merge upstream/master (update your local master); git checkout [branch] (switch to branch); git rebase master
[20:19] <tdonohue> that's a long "incantation", but it's what I tend to do ;)
[20:19] <terry-b> thanks
[20:20] <tdonohue> In any case, 1369 looks reasonable overall to me. I guess my only question would be whether this Authentication should be "off" by default (and turned on for demo), or truly "on" by default
[20:21] <tdonohue> I might lean towards leaving it "off" by default if this could be perceived as a security issue by anyone. It shouldn't be hard to custom on demo.dspace.org to just flip it to "true"
[20:22] <terry-b> I am conflicted on that. Without the feature, people will not see all of their items.
[20:22] <terry-b> That sounds reasonable to me.
[20:22] <mhwood> "You are not logged in. Some items may be excluded."
[20:23] <terry-b> I will make that change as well
[20:23] <tdonohue> yea, I think we just document this, or add a note in the report (as mhwood implies). But, it might be best to turn off by default, as some folks don't use Password Auth anyhow
[20:24] <mhwood> The feature is temporary anyway, with a broader implementation to follow.
[20:24] <terry-b> I should have these changes up later today. Thanks.
[20:24] <hpottinger> my other meeting is done, I'm going to be moving to another location, brb
[20:24] <tdonohue> thanks terry-b
[20:24] <mhwood> Yes.
[20:24] <tdonohue> Ok, are there others that are waiting on PR review?
[20:25] <mhwood> yes
[20:25] <mhwood> DS-3166
[20:25] <kompewter> [ https://jira.duraspace.org/browse/DS-3166 ] - [DS-3166] bin/make-handle-config script is broken - DuraSpace JIRA
[20:26] <mhwood> There may be more urgent issues. It seems as though this is not broken everywhere. It just happened to break on demo.
[20:26] <tdonohue> DSPR#1371
[20:26] <kompewter> [ https://github.com/DSpace/DSpace/pull/1371 ] - [DS-3166] bin/make-handle-config script is broken by mwoodiupui
[20:26] <mhwood> OTOH this is really small.
[20:27] <tdonohue> have you tested 1371? It looks OK. I'm wondering how this worked before with dspace.hostname as an IP?
[20:28] <mhwood> I've tested the actual patch locally and I've tested on demo by hacking the script by hand.
[20:29] <tdonohue> Well, it looks fine. Just wondering how long this has been broken ;)
[20:29] <mhwood> On demo it works, but builds the config. in the wrong location because 'dspace dsprop' was not working properly.
[20:30] <mhwood> Java classes for handling IP addresses are funny: you can initialize one with a name and it will resolve it if it can. There's something about the setup on demo, apparently, that makes that fail.
[20:30] * hpottinger (~hpottinge@161.130.188.172) Quit (Quit: Leaving, later taterz!)
[20:30] <tdonohue> I've added a +1 to it. It is small, looks pretty obvious
[20:30] <mhwood> Thanks.
[20:31] <tdonohue> Looking at tickets labeled "testathon" and needing code review, that seems to be the last of them.
[20:31] <mhwood> I think so.
[20:31] <tdonohue> But, before we move on to other testathon tickets, is there any other PRs that need reviewing (that may have fixed earlier bugs)?
[20:32] <mhwood> Nothing comes to mind.
[20:33] <tdonohue> aha..this is one...DSPR#1326. It's too large to review, but it could use a tester or two at some point
[20:33] <kompewter> [ https://github.com/DSpace/DSpace/pull/1326 ] - DS-3086 OAI Harvester is broken by DylanMeeus
[20:33] <tdonohue> This is a "blocker" for 6.0 final: DS-3086
[20:33] <kompewter> [ https://jira.duraspace.org/browse/DS-3086 ] - [DS-3086] OAI Harvester is broken (NPEs around several classes) - DuraSpace JIRA
[20:34] <tdonohue> I'm not saying we need to review it now/today...but if anyone could help test it, I'd appreciate it
[20:35] <tdonohue> it touches a lot of files though, and I admit, I haven't had a chance to go through it yet mysefl
[20:35] <mhwood> 120 files is indeed a lot of files.
[20:37] <tdonohue> in any case, I could use help/eyes. Looks like hpottinger (who dropped off) already noted that "ON DELETE CASCADE" might be worrisome (see his comment on JIRA ticket). But, I'd encourage others to add thoughts when you get a chance
[20:38] <tdonohue> In any case, we can probably move along...we'll just need to look at that ticket/PR more closely
[20:39] <tdonohue> Ok, so back to our list of "testathon" tickets
[20:40] <tdonohue> https://jira.duraspace.org/issues/?jql=resolution%20%3D%20Unresolved%20AND%20labels%20%3D%20testathon
[20:40] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/issues/?jql=resolution%20%3D%20Unresolved%20AND%20labels%20%3D%20testathon
[20:40] <tdonohue> I'm going to start at the *bottom* (earliest ticket first), skipping any that we already reviewed in this mtg
[20:40] <tdonohue> DS-3146
[20:40] <kompewter> [ https://jira.duraspace.org/browse/DS-3146 ] - [DS-3146] NPE when starting a new JSPUI submission with BTE metadata import enabled - DuraSpace JIRA
[20:41] <tdonohue> This is one I noted. Haven't had a chance to look into it. Another NPE though
[20:42] * hpottinger (~hpottinge@mu-161168.dhcp.missouri.edu) has joined #duraspace
[20:42] <tdonohue> flagging as needs volunteer
[20:42] <mhwood> Yes
[20:42] <tdonohue> next, DS-3147
[20:42] <kompewter> [ https://jira.duraspace.org/browse/DS-3147 ] - [DS-3147] Empty author lookup returns cryptic error - DuraSpace JIRA
[20:42] <tdonohue> sounds like an error...needs investigation as to its root cause
[20:43] <mhwood> If you look up nothing, you might well get an error back. But we could say it more plainly. Or not look up empty names in the first place.
[20:43] <mhwood> Or both.
[20:43] <mhwood> Yes, it's a bug.
[20:44] <tdonohue> flagged needs volunteer
[20:44] <tdonohue> DS-3148
[20:44] <kompewter> [ https://jira.duraspace.org/browse/DS-3148 ] - [DS-3148] Missing left padding - DuraSpace JIRA
[20:44] <tdonohue> another small bug
[20:45] <tdonohue> DS-3149 is a bit bigger
[20:45] <kompewter> [ https://jira.duraspace.org/browse/DS-3149 ] - [DS-3149] SWORDv2 does not seem to be available - DuraSpace JIRA
[20:46] <mhwood> Something is definitely broken in SWORDv2 but I couldn't figure out what.
[20:46] <mhwood> It starts "normally" but won't do anything, and throws errors.
[20:46] <tdonohue> huh.
[20:47] <tdonohue> SWORD v1 also seems to be broken (doesn't even respond): http://demo.dspace.org/sword/servicedocument
[20:47] <mhwood> Perhaps a similar problem.
[20:47] <tdonohue> It might be. My guess is that it could either be Commons Config (as configs changed here)..or Service API.
[20:48] <mhwood> Needs Volunteer.
[20:48] <tdonohue> that's a total guess, but yes, needs volunteer
[20:51] <tdonohue> ok. next up, DS-3150
[20:51] <kompewter> [ https://jira.duraspace.org/browse/DS-3150 ] - [DS-3150] Got an error when I tried to send my request for an embargoed file. - DuraSpace JIRA
[20:52] <tdonohue> need to determine underlying error here
[20:52] <tdonohue> still, needs volunteer
[20:53] <tdonohue> All of these seem like small errors individuals could easily reproduce locally (FYI for anyone listening, we could use your help!)
[20:53] <tdonohue> DS-3151
[20:53] <kompewter> [ https://jira.duraspace.org/browse/DS-3151 ] - [DS-3151] Error when accessing statistics page - DuraSpace JIRA
[20:54] <tdonohue> Huh, comment here that it might be related to log4j issues (recently fixed)
[20:54] <tdonohue> oh, wait. log.dir is used by something else?
[20:55] <mhwood> Hmm, I think the Handle startup script may refer to it as well.
[20:55] <mhwood> Grepping...
[20:55] <tdonohue> crud. So it seems.. 13 usages: https://github.com/DSpace/DSpace/search?utf8=%E2%9C%93&q=%22log.dir%22&type=Code
[20:55] <kompewter> [ Search Results · GitHub ] - https://github.com/DSpace/DSpace/search?utf8=%E2%9C%93&q=%22log.dir%22&type=Code
[20:56] <tdonohue> some are for log4j, but others are not
[20:56] <mhwood> Some are in JS test code.
[20:58] <tdonohue> so, it seems like log.dir was being used by more than log4j. Since log4j needs its own log.dir, we now need to decide whether to give dspace.cfg back its own (separate) log.dir setting, or something else
[21:00] <tdonohue> Or...hmmm.. I wonder if ConfigurationService could just read it from log4j.properties
[21:00] <mhwood> Aha! We've overloaded the log directory. Something I'd like to fix anyway. The old statistics code grinds out "logs" that it then summarizes.
[21:00] <mhwood> We should separate the stat. stuff from actual logs.
[21:00] <tdonohue> yes, we've overloaded log.dir
[21:00] <tdonohue> mhwood: true
[21:00] <mhwood> The stat. stuff is pure DSpace. We can configure that in dspace.cfg.
[21:02] <tdonohue> The problem is...that "stat" stuff gets its stats from the *logs*
[21:03] <tdonohue> see LogAnalyser, which also uses log.dir to generate stats: https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/app/statistics/LogAnalyser.java#L188
[21:03] <kompewter> [ DSpace/LogAnalyser.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/app/statistics/LogAnalyser.java#L188
[21:03] <tdonohue> So, if DSpace is going to analyze it's logs...it needs to know where they are
[21:04] <mhwood> But that's a commandline tool, no? We can just tell it.
[21:04] <tdonohue> oh..hmm.
[21:04] <tdonohue> true. I guess we could *require* a log dir be passed in
[21:04] <mhwood> The way I look at it, it's making an assumption that we no longer support.
[21:05] <tdonohue> Yea, I'm seeing your point now
[21:05] <tdonohue> I think you are correct. Perhaps we need to describe this in more detail in the ticket. It seems like we need to refactor these "stats" scripts to no longer rely on "log.dir"
[21:06] <tdonohue> (but pass it in via commandline)
[21:06] <mhwood> Anyway this needs more study, but we do need to fix it.
[21:07] <tdonohue> yep, agreed. I'll try to add some notes in the ticket
[21:07] <mhwood> Good. Thanks.
[21:07] <mhwood> And, with that, I've got to leave fairly soon.
[21:08] <tdonohue> We are now overtime. I'm not sure there's much more to really dig into today. But, I would encourage everyone here (or reading later) to help us fix the bugs reported in testathon. Here they are again: https://jira.duraspace.org/issues/?jql=resolution%20%3D%20Unresolved%20AND%20labels%20%3D%20testathon
[21:08] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/issues/?jql=resolution%20%3D%20Unresolved%20AND%20labels%20%3D%20testathon
[21:08] <tdonohue> There are a lot of reported bugs, but many seem small, low-hanging. Any help is appreciated!
[21:09] <tdonohue> With that though, I'm going to just close out today's meeting.
[21:10] <mhwood> 'bye.
[21:10] * mhwood (~mhwood@mhw.ulib.iupui.edu) has left #duraspace
[21:23] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) Quit (Quit: Leaving.)
[21:27] * hpottinger (~hpottinge@mu-161168.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[21:37] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[21:39] * terry-b (~chrome@71-212-101-240.tukw.qwest.net) Quit (Remote host closed the connection)
[21:45] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[21:50] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 268 seconds)
[22:09] * th5 (~th5@unaffiliated/th5) Quit (Remote host closed the connection)
[23:47] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[23:51] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 246 seconds)
[23:59] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.