Timestamps are in GMT/BST.
[6:51] -cameron.freenode.net- *** Looking up your hostname...
[6:51] -cameron.freenode.net- *** Checking Ident
[6:51] -cameron.freenode.net- *** Found your hostname
[6:51] -cameron.freenode.net- *** No Ident response
[6:51] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:51] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:51] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:12] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:07] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[13:46] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[14:20] * awoods (~awoods@c-98-245-50-182.hsd1.co.comcast.net) Quit (Read error: Connection reset by peer)
[14:21] * awoods (~awoods@c-98-245-50-182.hsd1.co.comcast.net) has joined #duraspace
[14:40] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) has joined #duraspace
[15:34] * jcreel (~jcreel@nat-165-91-13-219.tamulink.tamu.edu) has joined #duraspace
[15:40] * jcreel (~jcreel@nat-165-91-13-219.tamulink.tamu.edu) Quit (Quit: jcreel)
[15:58] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[16:04] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) has joined #duraspace
[16:34] * srobbins (~srobbins@libstfsdg02.library.illinois.edu) has joined #duraspace
[19:13] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) Quit (Quit: Leaving.)
[19:59] * aschweer (~andrea@d127.itstaff.waikato.ac.nz) has joined #duraspace
[20:01] <mhwood> Tim is unavailable today. Who is running the meeting?
[20:02] <aschweer> mhwood: probably either you or me :)
[20:03] <hpottinger> yay, I was going to suggest exactly that
[20:03] <aschweer> there is no agenda on the wiki for today it seems, but I guess the main topic is 5.4
[20:04] <hpottinger> 5.4 and pending 6.0 deadlines
[20:04] <hpottinger> in absence of other discussion, we can always keep working the 5.4 milestone "backlog" which is what we were just doing over the past hour
[20:05] <aschweer> shall we start with 5.4? I'm happy to run that part but I'm not at all up to date on the status for 6.0, so someone else should take over for that
[20:05] <aschweer> ah sorry, I always forget about the backlog hour since I just can't make that time
[20:06] <aschweer> I just marked all Jira issues with a PR with the 5.4 milestone as fix version = 5.4
[20:06] <hpottinger> no worries, as I said, we can just pick that back up if we run out of things to talk about
[20:06] <mhwood> Thanks for updating the issues.
[20:06] <aschweer> the other way round isn't synchronised up yet, as in, there are more tickets in Jira marked 5.4 than there are PRs marked 5.4
[20:07] <aschweer> with me having been away all last week, I'm a little behind. It looked like one big "maybe" for 5.4 is the solr one? DS-2823
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-2823 ] - [DS-2823] Discovery doesn't let you LIMIT the size of full text indexed, which can cause memory issues. - DuraSpace JIRA
[20:09] <aschweer> those of you who've been working on that one, can you give a quick update?
[20:09] <mhwood> The PR was lingering due to discussion of exporting the magic limit number to a property (plus a default). That isn't working out for some reason, but if we're happy with the simpler approach then I think it's about ready?
[20:10] <aschweer> I guess the only question is, are we happy to go with the simple approach now even if it may change to the property approach later?
[20:11] <hpottinger> mhwood's summary is correct, we have code that is "less magic" but there's no reason to hold it up for "more magic"
[20:12] <mhwood> If it works and is beneficial with the simple constant then I would say do that now and worry about making it fancy later.
[20:12] <aschweer> the only objection I can see is that people who _don't_ want this change will have to change the new default in one place for 5.4 and (probably) in a different place later
[20:12] <mhwood> Point.
[20:12] <aschweer> but, I'm personally happy to have the simple approach in 5.4 given that good Discovery performance will be important for pretty much everyone
[20:13] <hpottinger> If I understand correctly, the method of changing this default now would be compatible with the future way
[20:14] <aschweer> hpottinger: wouldn't you have to change schema.xml now but some properties file with the "magic" approach?
[20:14] <aschweer> also noting that for the default search operator the decision in the end was against trying any magic (I believe), but I guess that's something to be made consistent for 6.x
[20:14] <hpottinger> aschweer: any change to schema.xml would still get picked up, the suggested "more magic" would enable an alternate route to change the number
[20:15] <aschweer> hpottinger: ah cool, I hadn't picked up on the default coming from schema.xml. So we're not asking people to change things twice then.
[20:15] <hpottinger> I could be wrong, but I'm pretty sure I'm right :-)
[20:17] <aschweer> ok. So the summary for DS-2823 then is, if someone figures out the magic approach before 5.4 we go with that, otherwise fine to merge to 5_x as-is. Correct?
[20:17] <kompewter> [ https://jira.duraspace.org/browse/DS-2823 ] - [DS-2823] Discovery doesn't let you LIMIT the size of full text indexed, which can cause memory issues. - DuraSpace JIRA
[20:18] <hpottinger> correct, I clarified on DSPR1120 that my +1 still counts for the code as-is
[20:18] <aschweer> Excellent
[20:19] <aschweer> Another one for 5.4 that's a little tricky is DS-2542/DS-2524; if I remember right then one/both of these need a new version of xoai to be released (happy to be corrected on this one)
[20:19] <kompewter> [ https://jira.duraspace.org/browse/DS-2542 ] - [DS-2542] XOAI does not support non granular YYYY-MM-DD harvesting properly - DuraSpace JIRA
[20:19] <kompewter> [ https://jira.duraspace.org/browse/DS-2524 ] - [DS-2524] XOAI - from/until argument only works with date including the time - DuraSpace JIRA
[20:21] <mhwood> That's the way it looks to me as well.
[20:22] <mhwood> So how do we get an XOAI 3.x update released?
[20:22] <aschweer> mhwood: I was just halfway through typing that same question :)
[20:23] <aschweer> Who can do the release? xoai is under the DSpace umbrella in github now, but is that enough for the maven magic?
[20:23] <hpottinger> only one way to find out
[20:24] <aschweer> hpottinger: thanks for volunteering to try cutting the xoai release ;)
[20:24] <hpottinger> har har har, I actually think that someone who knows what they are doing with Maven ought to handle the first release, I'm just a button presser
[20:25] <hpottinger> also, I'm leaving for a week's vacation this afternoon
[20:25] <aschweer> :) I agree, it would be great for someone who knows what they're doing to do the xoai release
[20:25] <mhwood> So is the current 3.x in a release-able state?
[20:26] <mhwood> How do we determine that?
[20:26] <aschweer> the 3.x branch still has com.lyncode as the groupId
[20:26] <aschweer> https://github.com/DSpace/xoai/blob/3.x/pom.xml#L10
[20:26] <kompewter> [ xoai/pom.xml at 3.x · DSpace/xoai · GitHub ] - https://github.com/DSpace/xoai/blob/3.x/pom.xml#L10
[20:26] <mhwood> So at a minimum we'll need a patch to fix that.
[20:27] <hpottinger> see? complicated, you don't want a noodle-head like me pressing that button :-)
[20:27] <peterdietz> I volunteer tim to do 3x
[20:27] <hpottinger> tdonohue++
[20:28] <peterdietz> any other 5.4 issues to look at?
[20:28] <aschweer> I think it might be helpful for tdonohue to do this, yes. I'll e-mail him.
[20:29] <aschweer> Looking further over the list of jira tickets marked 5.4, there is DS-2788 that doesn't have a PR yet - cwilper is working on it and says there may be an update soon
[20:29] <kompewter> [ https://jira.duraspace.org/browse/DS-2788 ] - [DS-2788] Performance degradation of SOLR Discovery indexing in DSpace 5 - DuraSpace JIRA
[20:32] <aschweer> So I think that's it for looking over 5.4 -- obviously there are still a few things to iron out. But apart from that I guess it's down to setting a date for the release?
[20:32] <mhwood> If it is 'dspace index-discovery' itself that bloats up and crashes then tweaking Solr is not going to help.
[20:33] <aschweer> I think those are two separate things, agreed. Looks like for 2788 they're currently looking at the context objects, so not just solr tweaking.
[20:34] <aschweer> (just an aside, some solr tweaking might be a good idea too, eg the extracted fulltext is currently stored in 2-3 fields using the copy field mechanism IIRC)
[20:36] <mhwood> Oh, yes, I'm sure we can do better in configuring and using Solr. But in this case the problem seems to occur in a different process.
[20:36] <aschweer> I admit I haven't looked at 2788 in too much detail, but I got the impression that it set out to address one thing and somewhat morphed into addressing a different one
[20:38] * starsun (~g@194.44.84.246) has joined #duraspace
[20:38] <aschweer> I guess the question is, is 2788 serious enough that it would be worth delaying 5.4?
[20:39] <mhwood> It does sound pretty bad for large sites.
[20:40] * starsun (~g@194.44.84.246) has left #duraspace
[20:40] <mhwood> cwilper believed he would have something more definite perhaps today. I think another day or three might not hurt, if there is a good chance of figuring this one out.
[20:42] <aschweer> I was thinking about Nov 4 or Nov 5 my time for the release (evening of Nov 3 or of Nov 4 in the US I believe), so there is a little bit more time
[20:42] * hpottinger wonders how many cwilper mentions we can work into this conversation?
[20:42] <mhwood> Maybe make a decision tomorrow or Monday?
[20:43] <mhwood> Uh, forgot what day it is. Thursday or Friday?
[20:43] <hpottinger> I can be available as backup on the 5th, I cannot on the 4th
[20:44] <aschweer> hpottinger: hang on, what timezone are those dates?
[20:44] <aschweer> my morning is your evening the day before :)
[20:45] <mhwood> 04-Nov EST would be difficult for me, but I think I could be on IRC the evening of 03-Nov.
[20:46] <mhwood> (Next week we in .us will be coping with the end of DST on Sunday 01-Nov. Extra vigilance is indicated.)
[20:46] <hpottinger> I was figuring 20UTC-ish?
[20:46] <mhwood> It is 20:46 UTC now.
[20:47] <aschweer> ah right. if 20 UTC is good for people then it will have to be my Thursday, so 3 Nov 20 UTC (I have a meeting that time on my Wednesday)
[20:48] <aschweer> hpottinger: what was your backup availability?
[20:48] <hpottinger> I'll be traveling 3 Nov and 4 Nov, 5 Nov I'll be working again
[20:49] <hpottinger> (aka "Thursday")
[20:49] <aschweer> right. mhwood, what about you on Nov 5 EST?
[20:50] <mhwood> I can probably arrange to be available on 05-Nov.
[20:51] <aschweer> Cool. Because I can do my Nov 6 easily and it gives us a couple extra days. And I guess "no releases on a Friday" doesn't really apply in this case anyway.
[20:52] <aschweer> So, tentatively scheduling 5.4 for 4 Nov 20 UTC ish, but I'll also check with Tim re xoai (since that has to come first)
[20:53] <aschweer> Everyone, please feel encouraged to review PRs :)
[20:53] <mhwood> Now I'm confused again: late 04-Nov UTC would be daytime 05-Nov in .nz?
[20:54] <aschweer> argh I grabbed the wrong day. Tentatively scheduling 5.4 for _5_ Nov 20 UTC ish
[20:54] <aschweer> sorry about that
[20:54] <aschweer> I better make sure to have more coffee before the release than I've had today!
[20:55] <mhwood> OK, I have a note on my calendar for 05-Nov-2015 2000UTC.
[20:55] <aschweer> Right. I guess that's it for 5.4? Anything we need to discuss for 6.0? (sorry to have taken up so much of the meeting time)
[20:56] <hpottinger> I just closed DS-2698 as fixed (merged to 6, backported to 5.4)
[20:56] <kompewter> [ https://jira.duraspace.org/browse/DS-2698 ] - [DS-2698] XMLUI metadata browse cache validity doesn't consider value count - DuraSpace JIRA
[20:56] <aschweer> yay (to both)
[20:59] <hpottinger> aschweer: you just commented on DS-1821, I think the possibility of saving that improvement is worth avoiding the revert
[20:59] <kompewter> [ https://jira.duraspace.org/browse/DS-1821 ] - [DS-1821] Internationalize the bitstream access icon alt text - DuraSpace JIRA
[21:00] <aschweer> hpottinger: well it needs someone to volunteer to see whether the Mirage 2 approach actually works here. I don't know how broken things are at the moment (ie how much the revert fixes). We may have to revert then make a new change anyway.
[21:03] <aschweer> oh, also looking at the actual code, I think my suggestion probably won't work :(
[21:03] <hpottinger> Hmm... the referenced Jira is for the original fix, we need a new Jira to consider this PR
[21:04] <aschweer> I wondered about that
[21:04] <mhwood> I'm going to have to leave now, sorry.
[21:05] <aschweer> I'll need to leave soon too
[21:05] <aschweer> mhwood thanks for volunteering as backup for the release (and hpottinger too)
[21:05] <mhwood> You're welcome. For now, goodbye all.
[21:06] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:07] <aschweer> Anyway, I need to leave now. Bye everyone.
[21:07] * aschweer (~andrea@d127.itstaff.waikato.ac.nz) Quit (Quit: leaving)
[21:19] <peterdietz> master appears quite broken. Error creating bean with name 'org.dspace.statistics.SolrLoggerUsageEventListener#0' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class
[21:19] <peterdietz> [org.dspace.statistics.SolrLoggerUsageEventListener]: Constructor threw exception; nested exception is java.lang.NullPointerException
[21:27] <hpottinger> attempting to verify, one moment please
[21:34] <peterdietz> I'm gonna step out and get some fresh air
[21:40] <hpottinger> peterdietz: I can see excpetions in catalina.out, about beans, the ones I see are lots and lots of Failed to startup the DSpace Service Manager: failure starting up spring service manager: Error creating bean with name 'org.dspace.servicemanager.spring.DSpaceBeanPostProcessor#0' defined in class path resource [spring/spring-dspace-applicationContext.xml]: Unsatisfied dependency expressed through constructor argument with index 0 of t
[21:40] <hpottinger> ype [org.dspace.servicemanager.config.DSpaceConfigurationService]: : Cannot find class [org.springframework.orm.hi
[21:40] <hpottinger> anyway, yeah, it's not starting up at the moment
[21:41] <hpottinger> so far, the only webapps I show as running are non-DSpace: probe and Solr
[21:43] <hpottinger> hold on, shared container with 5_x stuff... need to clean this thing out
[21:48] <peterdietz> nothing starts for me. Its been a depressing week development wise. I've spent loads of time on non-development.
[21:49] <peterdietz> Well, gotta commute for dinner. ~8 seconds
[21:54] <hpottinger> it's loading for me now
[21:55] <hpottinger> all webapps, I just had to actually change to master and build/deploy
[21:56] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[23:18] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) Quit (Quit: Leaving.)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.