Timestamps are in GMT/BST.
[0:00] * jonathangee (~jonathang@142.68.37.238) has joined #duraspace
[0:06] * fasseg (~fas@HSI-KBW-095-208-235-163.hsi5.kabel-badenwuerttemberg.de) Quit (Ping timeout: 260 seconds)
[1:27] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Read error: Connection reset by peer)
[1:27] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[6:36] -cameron.freenode.net- *** Looking up your hostname...
[6:36] -cameron.freenode.net- *** Checking Ident
[6:36] -cameron.freenode.net- *** Found your hostname
[6:36] -cameron.freenode.net- *** No Ident response
[6:36] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:36] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:36] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:20] * helix84 (~ctenar@195.178.95.132) Quit (Remote host closed the connection)
[13:01] * fasseg (~fas@HSI-KBW-095-208-235-163.hsi5.kabel-badenwuerttemberg.de) has joined #duraspace
[13:11] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[13:54] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has joined #duraspace
[14:50] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[17:03] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[18:26] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[18:53] * helix84 (~ctenar@195.178.95.132) has joined #duraspace
[19:51] * Daryl (67044126@gateway/web/freenode/ip.103.4.65.38) has joined #duraspace
[19:58] * lap_ (~chatzilla@87.19.8.26) has joined #duraspace
[19:59] * lap_ (~chatzilla@87.19.8.26) has left #duraspace
[20:00] <tdonohue> Hi all, it's time for the weekly DSpace Developers Mtg. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-11-20
[20:00] <kompewter> [ DevMtg 2013-11-20 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-11-20
[20:00] * lap1 (~l.pascare@87.19.8.26) has joined #duraspace
[20:01] <tdonohue> Most of today's meeting is obviously 4.0 updates, status, etc.
[20:01] <tdonohue> But, first off, just thought I'd pause to welcome lap1 as our newest DSpace Committer!
[20:01] <lap1> Hi all :-)
[20:02] <mhwood> Welcome!
[20:02] <tdonohue> welcome lap1! As mentioned, glad to have you on the team
[20:02] <hpottinger> welcome!
[20:02] <lap1> let me to say thank you for this opportunity
[20:03] <helix84> welcome!
[20:04] <tdonohue> Feel free to continue the welcome messages :) But, in the essence of time, I'm going to go ahead and get us started on 4.0 status updates / topics
[20:04] <lap1> and let's go start for my first irc chat as committer
[20:05] <mhwood> DS-1621, then?
[20:05] <kompewter> [ https://jira.duraspace.org/browse/DS-1621 ] - [DS-1621] Search in Item mapper don't work without lucene search provider - DuraSpace JIRA
[20:05] <tdonohue> So, status check: Testathon is now ended. We are ~2 weeks from our estimated release day. But, we still have a large amount of "fix for 4.0" tickets: https://jira.duraspace.org/browse/DS/fixforversion/11140
[20:05] <kompewter> [ DSpace: 4.0 - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS/fixforversion/11140
[20:06] <tdonohue> yes, we can dig right into some of the highest priority tickets... DS-1621 being one of them (thanks mhwood)
[20:06] <kompewter> [ https://jira.duraspace.org/browse/DS-1621 ] - [DS-1621] Search in Item mapper don't work without lucene search provider - DuraSpace JIRA
[20:07] <tdonohue> I haven't done enough looking into 1621 myself, but if we need a new config, then maybe that's the best we can do for now
[20:09] <mhwood> I think that's all we have time for. Unless someone knows a clever way to figure out which service to use, we need to just tell DSpace with a configuration setting.
[20:09] * bollini (~bollini@host167-106-dynamic.55-79-r.retail.telecomitalia.it) has joined #duraspace
[20:09] <tdonohue> mhwood: well, if JSPUI does the same (which it sounds like it does), then that's "good enough" for XMLUI too.
[20:09] <hpottinger> I think cleverness would be wasted on a a deprecated search index, yes?
[20:09] <tdonohue> so, we just need a volunteer to fix 1621 then
[20:09] <mhwood> Shall I just take this one and do that?
[20:10] <hpottinger> look, look, a volunteer!
[20:10] <tdonohue> mhwood: sure, if you are willing. I think hpottinger is also right that we don't need to get too clever, as we've been talking about deprecating Lucene anyhow
[20:10] <mhwood> I'm just going to add the parallel configuration setting and use it.
[20:11] <tdonohue> sounds good. go ahead and claim 1621 then. thanks, mhwood
[20:11] <mhwood> Claimed.
[20:11] <tdonohue> another high priority ticket for 4.0: DS-1776
[20:11] <kompewter> [ https://jira.duraspace.org/browse/DS-1776 ] - [DS-1776] Unable to read statistics core after upgrade to DSpace 4.0 - DuraSpace JIRA
[20:12] <mhwood> bollini has claimed this one.
[20:12] <bollini> not exactly :-)
[20:12] <tdonohue> do we want to do a status check then? This is a definite "blocker"
[20:12] <bollini> it is mostly solved just need to be placed in configuration
[20:13] <bollini> s/placed in configuration/noted in documentation/
[20:13] <kompewter> bollini meant to say: it is mostly solved just need to be noted in documentation
[20:14] <bollini> my only concern here is that that could make hard an updgrade from < 1.8 to dspace 4
[20:14] <tdonohue> So, it sounds like we need to note two things in the documentation: (1) the recommendation to run "stats-util -o" *before* upgrading to 4.0, and (2) how you can fix things if you forgot to run "stats-util -o" (or didn't follow directions)
[20:15] <bollini> (2) also apply in the case you are coming from a very old dspace version
[20:15] <tdonohue> yep, exactly, bollini. So, I think we need to add your "wget" call to the upgrade documentation as the "fix" if you hit these errors
[20:16] <bollini> it not works if you have very old indexes
[20:16] <tdonohue> oh, so is there a different fix for very old indexes? If so, we may want to document that
[20:17] <bollini> on the demo site we had index files from solr 1.4 (lucene format < 3)
[20:17] <mhwood> Is there an intermediate step that would turn very old indexes into not so old indexes? We could add that to the upgrade instructions for an earlier version.
[20:17] <bollini> you cannot run optimize using solr 4 on lucene format index < 3
[20:18] <tdonohue> mhwood++
[20:18] <bollini> mhwood: exactly, I had to setup a "dspace 3.2 solr webapp" just to update the index format
[20:18] <PeterDietz> I wonder if we can recommend someone use a standalone java -jar lucene3.jar command to optimize their thing, if they are jumping a version
[20:18] <bollini> so if you come from old dspace you need to update to dspace 3.2, run optimize and go to dspace4
[20:19] <bollini> PeterDietz: there are not lucene cmd line tools for that as far as I know
[20:19] <tdonohue> I'm worried here that others will not be re-optimizing their indexes on each upgrade. Maybe we need to make that a *common instruction* in all our upgrade instructions
[20:19] <mhwood> PeterDietz++. User doesn't need DSpace 3.2, just a Lucene-based tool that is new enough. If there is one.
[20:20] <mhwood> tdonohue++
[20:20] <bollini> probably that but I haven't tested http://manpages.ubuntu.com/manpages/hardy/man1/lucli.1.html
[20:20] <kompewter> [ Ubuntu Manpage: lucli - command line interface to the Lucene full-text indexing library ] - http://manpages.ubuntu.com/manpages/hardy/man1/lucli.1.html
[20:20] <hpottinger> oh, so we just need upgrade docs and to test them :-)
[20:21] <tdonohue> well, it sounds like we need (1) 4.0 upgrade docs & test them (2) also tweaks to older upgrade docs (e.g. 1.8->3.x) to add the optimization step
[20:21] <bollini> or https://code.google.com/p/luke/
[20:21] <kompewter> [ luke - Luke - Lucene Index Toolbox - Google Project Hosting ] - https://code.google.com/p/luke/
[20:22] <tdonohue> Plus, it would be good to see if there are any general Lucene tools that can help folks who hit this issue
[20:23] <mhwood> Maybe in 5.0 we can have a built-in tool for updating indexes, and let 'ant update' depend on it.
[20:23] <tdonohue> So, do we have any volunteers to tackle either the docs updates or looking into Lucene tools?
[20:24] <tdonohue> mhwood++ great idea. I'd rather it happen "automatically" myself. Having to depend on folks running a series of commands is not the best solution (as people make mistakes)
[20:24] <mhwood> I can polish doco. but I don't know enough about Lucene/Solr yet to write these.
[20:25] <tdonohue> mhwood: I think the general recommendation is just to add a "./dspace stats-util -o" command to *every* recent upgrade script (including our 4.0 one). As that ensures your stats indexes are optimized & up to date.
[20:26] <tdonohue> for 4.0 though, we also want to recommend they run "stats-util -o" *before* upgrading (Just in case they have never run it previously)
[20:26] <mhwood> But apparently it is not simple to determine whether stats-util -o will work, if you have been running DSpace through several releases.
[20:27] <bollini> no, if you run stats-util -o with dspace 3.2 it will be fixed always
[20:27] <bollini> lucene brokes compatibility in 4.0 so you cannot solve using SOLR4 (DSpace 4) but you can solve it in dspace 3.2
[20:28] <hpottinger> gosh, I don't know how anyone would be able to keep DSpace standing up without regularly running optimize on their Solr stats core
[20:28] <tdonohue> it will work if you run it between each upgrade...it just won't work if you skip upgrade steps. So, to go 1.8->3.x->4.x (and run stats-util -o in between each), you should be fine. Which is why we need the 1.8->3.x docs to say to run optimization, and the 3.x->4.x to also say to run optimization.
[20:29] <mhwood> Can I use an earlier version of DSpace, if that's what I'm upgrading from? How much earlier? Is there a version that both has Solr and is too old to produce indexes that Solr 4 can upgrade?
[20:29] <hpottinger> DS-615
[20:29] <kompewter> [ https://jira.duraspace.org/browse/DS-615 ] - [DS-615] Ability to perform maintenance on SOLR with solr.optimize - DuraSpace JIRA
[20:30] <tdonohue> 1.8.0 was the first version. This only effects 1.8.x->3.x->4.x
[20:30] <PeterDietz> Hey.. Who's the wise person who thought of including an easy way to run solr optimize on DSpace ;)
[20:31] <bollini> ok the stop version is dspace .18
[20:31] <mhwood> So if I'm upgrading 1.8.1 -> 4.x I have to do *two* upgrades? One is bad enough!
[20:31] <bollini> if you have at least dspace 1.8 you can just run optimize before to upgrade to dspace 4
[20:32] <mhwood> I can run optimize *in DSpace 1.8*?
[20:32] <bollini> if you have any version before dspace 1.8 (1.7,1.6, etc.) you need to do a two step upgrade passing for 1.8 or 3 and running optimize
[20:32] <PeterDietz> I think you usually have to do the DB-upgrade script even if you skip an intermediate version. So, if you want to skip 3.0, you'll atleast need to git clone DSpace/DSpace; git checkout dspace-3.x; mvn package; ... ; dspace stats-util -o
[20:32] <bollini> mhwood: you can always run it using wget
[20:33] <hpottinger> and, I'd be really surprised if you weren't running optimize every night
[20:33] <PeterDietz> I think "to skip DSpace 3", we can recommend people try java luke3.jar optimize
[20:33] <mhwood> PeterDietz: exactly. Two upgrades. Merging the database and config. tweaks is much less trouble than installing the whole thing a second time.
[20:34] <tdonohue> I feel like we are taking too long on this topic. Per our "Support Policy" we only promise fixes to the last 3 major releases. As of the point of 4.0, that will mean 1.8->3.x->4.x. So, we really just need to concentrate on updating the 1.8->3.x docs and the 3.x->4.x docs
[20:35] <PeterDietz> Well not quite two upgrades. I was thinking to just have a route for the person to get access to solr3 tools. They don't need OUR solr optimize command, just plain old solr.optimize.
[20:35] <PeterDietz> https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/statistics/SolrLogger.java#L1263 == solr.optimize();
[20:35] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/statistics/SolrLogger.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/statistics/SolrLogger.java#L1263
[20:36] <mhwood> And, 1.8.x -> 4.0 only needs to run optimize? No intermediate installs?
[20:36] <helix84> http://www.getopt.org/luke/
[20:36] <kompewter> [ 1 ] - http://www.getopt.org/luke/
[20:36] <helix84> CLI for optimization. Sorry if I'm late to the discussion.
[20:36] <bollini> Ok. I will try to use luke tomorrow to fix very old index and report the result on the jira issue
[20:37] <bollini> so we just need a voluntair to take this information in the documentation
[20:37] <tdonohue> can we get a few folks to report things back to JIRA ticket. I feel like we are spending too much meeting time on something we likely can document in JIRA and then have someone copy to official docs
[20:38] <tdonohue> we likely don't need to figure out all the answers now, but if we have a few folks willing to work together here, we can get this fixed/documented in the coming days.
[20:39] <bollini> go ahead I have add a note to the jira issue
[20:39] <mhwood> I can write documentation if someone can tell me what it should convey.
[20:39] <tdonohue> sounds like bollini is willing to try figuring out what works, and mhwood is willing to help with docs. sound good?
[20:39] <bollini> s/add/added/
[20:39] <kompewter> bollini meant to say: go ahead I have added a note to the jira issue
[20:39] <hpottinger> I can pitch in with testing docs
[20:39] <tdonohue> sounds like we have a plan for 1776 then. thanks all!
[20:40] <tdonohue> next up, DS-1788
[20:40] <kompewter> [ https://jira.duraspace.org/browse/DS-1788 ] - [DS-1788] Rename Indexing scripts for clarity - DuraSpace JIRA
[20:40] <hpottinger> someone ping me when/if they need testing
[20:40] <tdonohue> I think this 1788 ticket just needs a volunteer to rename the scripts & update our docs appropriately
[20:41] <tdonohue> (as we had discussed this renaming last week)
[20:42] <mhwood> If it's just renaming commands, I can do that & document it.
[20:42] <bollini> mhwood++ thanks!
[20:42] <tdonohue> yep, it's just renaming commands, and then documenting the new ones (and making sure other areas of the 4.x docs are updated to newest commands)
[20:42] <tdonohue> thanks mhwood!
[20:43] <mhwood> Got it.
[20:43] <tdonohue> moving along...https://github.com/DSpace/DSpace/pull/379 (DS-1483)
[20:43] <kompewter> [ DS-1483 Generate citation_pdf_url in more cases by aschweer · Pull Request #379 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/379
[20:43] <kompewter> [ https://jira.duraspace.org/browse/DS-1483 ] - [DS-1483] Store link to "primary bitstream" in citation_pdf_url for Google Scholar (request from Google) - DuraSpace JIRA
[20:44] <tdonohue> I thought we had discussed this as being a "bug fix", but I don't recall who was going to test it out, etc.
[20:45] <mhwood> Andrea Schweer provided a PR.
[20:45] <tdonohue> yep, I think it mainly just needs a review & merger then
[20:46] <hpottinger> I volunteered to test
[20:47] <tdonohue> hpottinger, do you want to test & merge (if testing is successful) then?
[20:47] <hpottinger> yes, it's on my list
[20:47] <mhwood> Thank you.
[20:48] <tdonohue> yes, thanks!
[20:49] <tdonohue> OK. I guess the other questions to bring up are similar to those that mhwood asked on dspace-release: How do folks feel about 4.0? Are things "stabilizing"? Do we need more time? Do we need a second testathon?
[20:49] <hpottinger> I haven't been able to do any Oracle testing, and as I mentioned on _commit, I'm not likely to
[20:50] <mhwood> With all these issues being worked, it seems likely that RC2 will slip a day or so.
[20:50] <hpottinger> mhwood has been doing some Oracle testing
[20:50] <tdonohue> I will note that we also still have 71! tickets marked "fix for 4.0". Some of those look like they are just doc updates, or possibly could be rescheduled for 4.1 or 5.0. But, we probably should review them too: https://jira.duraspace.org/browse/DS/fixforversion/11140
[20:50] <kompewter> [ DSpace: 4.0 - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS/fixforversion/11140
[20:50] <bollini> we are going to work much on oracle just not sure if in time for the official release
[20:50] <helix84> I let the Oracle users here know that if something is broken, it's up to them to report it. I got one acknowledgement, but no reports. So hopefully, nothing is broken.
[20:50] <mhwood> Well, I have a recent master using Oracle 10g, but I don't know Oracle very well and don't really know how to exercise it.
[20:51] <hpottinger> do we need a meeting just to review our 4.0 tickets?
[20:51] <mhwood> BTW concerning hardware spec.s, 10g is running on an old Dell Optiplex GX280 desktop. :-/
[20:52] <tdonohue> hpottinger ++ , yes, we could have a separate meeting to go through 4.0 tickets to see if there's any "low hanging fruit" or ones to reschedule/etc.
[20:52] <hpottinger> You can run Oracle on anything that'll run vbox
[20:52] <hpottinger> https://wiki.duraspace.org/display/DSPACE/DSpace+with+Oracle+DB+test+instance
[20:52] <kompewter> [ DSpace with Oracle DB test instance - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+with+Oracle+DB+test+instance
[20:53] <tdonohue> Another task for 4.0: we probably should review our Software Prerequisites/Requirements. For example, I'm assuming we will now require Java 7 (since Java 6 is end-of-life)?
[20:54] <PeterDietz> Do we recommend JDK7 (openjdk), or Oracle JDK7 ?
[20:54] <PeterDietz> I find oraclejdk7 such a PITA to install...
[20:54] <hpottinger> mhwood, and anyone else interested int testing Oracle, I'd suggest just trying to batch load some AIPs, and then mash away on the interface (try to add stuff manually, add an eperson, etc.)
[20:55] <mhwood> I hope the answer to that is "yes". I'm running on OpenJDK. Too much foolishness to get Oracle JDK installed.
[20:55] <hpottinger> OpenJDK is running fine on Demo, I think
[20:55] <tdonohue> PeterDietz: we support both. Demo.dspace.org runs OpenJDK. I'm running OpenJDK for all DSpaceDirect customers
[20:55] <hpottinger> Vagrant-DSpace uses OpenJDK7
[20:55] <tdonohue> DSpace 3 works fine on OpenJDK...as far as I've seen, so does DSpace 4
[20:56] <mhwood> I've had no problems with DSpace 4 on OpenJDK 7.
[20:56] <PeterDietz> elasticsearch.org recommends oraclejdk7... for performance reasons. I'm not sure that they've re-evaluated this position, or if its just old mantra. SunJava is better ...
[20:56] <helix84> I ran DSpace 1.6-4.0, always on OpenJDK (mostly 6)
[20:56] <bollini> we strongly recomend oracle jdk to our customers but mostly due to some strange behaviour of openjdk6 and specific customization that we have done
[20:56] <tdonohue> (I've never done any performance analysis...so, it's possible there's slight performance differences, but there's no errors thrown by running DSpace with OpenJDK)
[20:57] <bollini> openjdk7 seems to work much better but not really streassed
[20:57] <mhwood> I thought that OpenJDK and Oracle JDK are mostly the same code, without/with a few Oracle-proprietary classes.
[20:57] <tdonohue> So, all in all... DSpace works with both. You should be allowed to choose whichever one you want to run
[20:58] * jonathangee (~jonathang@142.68.37.238) has left #duraspace
[20:58] <tdonohue> But, I do suspect we should say that 4.0 requires Java 7 or above.
[20:58] <mhwood> Does anybody know whether DS 4 still works well on Tomcat 6?
[20:58] <PeterDietz> I think things are better in JDK7. With openjdk being the "reference implementation", whatever that means... Sounds like we can recommend openjdk7 as our stance. You are free to use oracle-jdk7, as you might have some (as-of-yet un-noticed) improvements
[20:59] <tdonohue> mhwood: I'm running Tomcat 7 these days
[20:59] <hpottinger> I think I was running DS4 on Java 6/Tomcat 6, as part of my failed attempt at brining my Oracle development stack back from the dead
[20:59] <mhwood> TC 6's days are numbered, but TC 8 is not yet out.
[20:59] <helix84> mhwood: there was one issue with OAI on Java6, but I don't remember if it was fixed yet
[20:59] <tdonohue> PeterDietz: I don't think we have to recommend one over the other. We can just say that DSpace 4 requires Java 7 or above. You are welcome to choose either Oracle Java 7 or OpenJDK 7
[20:59] <PeterDietz> I would say that DS4 will have some weird issues if you try to run it in tomcat5.5.. The REST API requires at least servletAPI2.5 (which is in tomcat6 and above)
[21:00] <mhwood> We can say that developers have tested on OpenJDK and Oracle JDK. Can't say the same for IBM JDK or Gnu Classpath or....
[21:00] <hpottinger> oh, that's good info, thanks PeterDietz
[21:00] <mhwood> I would expect weird issues if one ran *anything* in Tomcat 5.5 these days.
[21:01] <tdonohue> Our DS3 recommendations were Tomcat 6 or above. So we don't need to worry about Tomcat 5 or less. We just need to decide if we stay at Tomcat 6 or bump up to Tomcat 7
[21:01] <bollini> I will prefer to suggest tomcat7 (we will move on it with dspace 4)
[21:02] <mhwood> So we're going to recommend Java 7 and up, and Tomcat 6? 7? and up?
[21:02] <tdonohue> Java 7 + Tomcat 7 seems reasonable to me. (If folks want to run Tomcat 6, they can try it...but we just won't guarantee it's gonna work 100% right)
[21:04] <mhwood> So our recommendation is Java 7+, Tomcat 7+? Has anyone tried out Tomcat 8? I haven't.
[21:04] <mhwood> (Tomcat 8 is not yet released, but very near.)
[21:04] <tdonohue> I haven't tried Tomcat 8, as it's not released
[21:05] <tdonohue> since these are just *recommendations* I think we just detail what we know works. We can clear up whether Tomcat 8 has issues later on by tweaking docs or adding JIRA tickets later as needed
[21:06] <mhwood> So we recommend Java 7+, Tomcat 7. And we may update that in late winter or spring.
[21:06] <tdonohue> yep. It's just like always. We tweak those recommendations often after releases (especially if we notice issues with specific versions of Tomcat or similar)
[21:07] <tdonohue> So, do we want a separate meeting to review tickets still marked "fix for 4.0"? Should we schedule that now?
[21:08] <bollini> I want to suggest to use the next jira backlog hour to do that
[21:09] <mhwood> I think we also require Maven 3? Should we burn that into the dspace-parent POM?
[21:09] <bollini> it is the week before the release so it should be not surprising for the community that we are strongly focused on dspace 4
[21:10] <tdonohue> We can use the next JIRA backlog hour. I do want to note that there's a major US holiday next week (Thurs, Nov 28 is Thanksgiving). I will be around on Weds for our meeting as normal, but I wasn't sure others will be traveling that day?
[21:11] <mhwood> I think I will be here.
[21:11] <tdonohue> (I.e. most folks in the USA will not be working on Nov 28 & 29...some also choose to take off Nov 27 for travel)
[21:11] <bollini> mhwood: oh yes, maven 3 what else? I'm just forget about older versions ;-)
[21:11] <tdonohue> Maven 3 sounds fine to me too
[21:12] <hpottinger> maven 3 is fine, and good luck to anyone trying to use anything less
[21:12] <tdonohue> Honestly, we should work to update all our version numbers to versions we are *actively* using (of Maven/Java/Tomcat/Postgres/Oracle). If folks want to try older versions, they can do so...but we are not actively testing older versions
[21:13] <hpottinger> 11/27 I will be at home with my kids, but I can check in to the meeting
[21:13] <helix84> again, I had no problems with Maven 2.2.1
[21:13] <mhwood> Versions: goes for Maven dependencies and plugins too.
[21:14] <helix84> we don't have many reports on newer postgres versions. 9.1 seems to be the latest that more than a couple of people reported on.
[21:14] <tdonohue> we're using 9.1 postgres for DSpaceDirect.
[21:14] <hpottinger> oh, hey, speaking of calendar stuff, I have RC2 on my calendar for tomorrow
[21:14] <helix84> I only tested DSpace 4 on Pg 9.1
[21:15] <bollini> mmm... RC2, it is to early
[21:15] <mhwood> Tested on 9.2, our production (older) is on 9.1.
[21:16] <mhwood> RC2 will have to slip to early next week, yes? :-(
[21:16] <bollini> I will prefer to have in at least the index renamed stuff fixed and also the embargo improvements
[21:16] <hpottinger> fine by me, RC2 on 11/28? the big cooking holiday?
[21:16] <tdonohue> I'm OK with pushing back.
[21:17] <hpottinger> 12/4 is the final release date
[21:17] <tdonohue> not sure who would release RC2 on 11/28 though. I'm going to be offline (completely) on 11/28 and 11/29
[21:17] <mhwood> Better to get more into RC2 than to push it out hastily and then have to do RC3.
[21:17] <hpottinger> same here, I was mostly being silly
[21:17] <tdonohue> And, it is worth noting that pushing back RC2 likely means we will need to push back Final Release (not definite, but more likely)
[21:18] <mhwood> :-( :-(
[21:18] <tdonohue> but, again, I think that's OK. The schedule is a *goal*. If we miss slightly, no big deal.
[21:18] <hpottinger> we could bump RC2 to 12/4 and final release to 12/11
[21:18] <tdonohue> we just want to try not to "miss" by too much...hopefully we'll still get final release out in early-to-mid Dec
[21:19] <bollini> why not try to RC2 on 11/25 ?
[21:20] <hpottinger> mhwood, you available to pull the lever on RC2 on 11/25?
[21:20] <tdonohue> I think we should aim for RC2 next week (keeps us trying to get the next fixes in), if possible. We then can see where we are...possibly an RC3 the week of 12/4, or if we are "stable" maybe we can still do Final Release that week.
[21:20] <mhwood> I could do 25-Nov if that's what we want. Are we reasonably confident that RC2 can become release?
[21:20] <hpottinger> I'm liking the way things look, honestly
[21:21] <mhwood> We don't seem to have broken very much yet.
[21:21] <bollini> we will try to finalize the residual issues on the jspui side over the weekend
[21:21] <mhwood> Thank you.
[21:22] <bollini> thanks to lap1 to volunteer :-D
[21:22] <lap1> who is lap1?
[21:23] <lap1> :-)
[21:23] <tdonohue> On the XMLUI side, I think things look pretty good. I still want to see what we (re-)discover in our review of the "Fix for 4.0" issues too...I'm hoping that there's nothing "hiding" there
[21:25] <tdonohue> we obviously can do as many (or as few) "RC" releases as we want to. So, after RC2 we can decide if we are ready for "Final Release" or if we want an RC3, etc.
[21:25] <tdonohue> but, it seems like things are stabilizing...so I don't think we are very far from a "final release"
[21:27] <bollini> well, it looks as we have a plan. RC2 on 11/25, final meeting for 4.0 on 11/27 and hopeful final release on 12/4
[21:27] * hpottinger scribbles on his calendar...
[21:27] <tdonohue> Ok, I don't have any other official topics for today. Next week we'll do "Fix for 4.0" reviews at 19:00UTC (Weds, Nov 27) instead of JIRA Backlog hour, prior to the 20:00 UTC mtg.
[21:28] <mhwood> Versions updated in docs.
[21:28] <tdonohue> and bollini's goal sounds good. If needed, we can push back final release slightly too...but we can see how things look next week
[21:29] <tdonohue> So, the official mtg is ended here. But, I'll be around for a while if anyone has anything else to discuss
[21:30] <mhwood> Looks like the DCAT forum is members-only? I will join, mention Ds-1631, and lurk.
[21:32] * Daryl (67044126@gateway/web/freenode/ip.103.4.65.38) has left #duraspace
[21:36] * lap1 (~l.pascare@87.19.8.26) has left #duraspace
[21:36] <tdonohue> mhwood: I think DCAT mailing list is similar to other lists...all our lists actually require you join before you can post
[21:37] <mhwood> "You do not have permission to join this forum."
[21:39] <tdonohue> hmmm... I *thought* anyone could join
[21:40] <mhwood> This is the Google Group "DSpace Community Advisory Team".
[21:40] <tdonohue> Yep. that's the right one. Well, maybe Val had to lock it down for some reason. In any case, you should be able to request membership and she'll add you right away.
[21:41] <tdonohue> Val's not online right now, or else I'd ask her. She controls the "keys" to that Google Group
[21:41] <mhwood> That's what I did: "apply for membership".
[21:42] <tdonohue> and it gave you a "permission denied"? Ugh. We might need to email Val. I don't have any access control in that group... I'm just a normal "member".
[21:42] <mhwood> There is "contact the owner". Trying that.
[21:44] <mhwood> It didn't complain.
[21:44] <helix84> just noting that they don't use the mailing list for discussions, only some announcements and planning. they do their discussions in their ~monthly phone calls
[21:45] <mhwood> I presume that will straighten things out sometime soon.
[21:45] <tdonohue> their mailing list though is still the best place to ping them about feedback on JIRA tickets..which is what mhwood is trying to do
[21:45] <mhwood> I just want to get some DCAT attention onto Ds-1631.
[21:54] * bollini (~bollini@host167-106-dynamic.55-79-r.retail.telecomitalia.it) has left #duraspace
[21:56] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has left #duraspace
[22:00] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:06] * dspace_jvm (4c584c43@gateway/web/freenode/ip.76.88.76.67) has joined #duraspace
[22:06] <dspace_jvm> greetings to all
[22:06] <dspace_jvm> where do we set the dspace jvm args
[22:11] <PeterDietz> hi dspace_jvm.. Are you talking about things like JAVA_OPTS ? i.e. how much memory to assign to dspace, or to run it in -server mode?
[22:12] <PeterDietz> typically these things are best done however your OS does these things. However, you can usually easily bump the amount of memory that your /dspace/bin/dspace script gets, by editing that file itself.
[22:12] <PeterDietz> https://github.com/DSpace/DSpace/blob/master/dspace/bin/dspace#L66
[22:12] <kompewter> [ DSpace/dspace/bin/dspace at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace/bin/dspace#L66
[22:12] <PeterDietz> #Allow user to specify java options through JAVA_OPTS variable
[22:12] <PeterDietz> if [ "$JAVA_OPTS" = "" ]; then
[22:12] <PeterDietz> #Default Java to use 256MB of memory
[22:12] <PeterDietz> JAVA_OPTS=-Xmx256m
[22:12] <PeterDietz> fi
[22:13] <dspace_jvm> thanks peter
[22:14] <PeterDietz> You can see that I've customized mine: https://github.com/osulibraries/DSpace/blob/osukb/dspace/bin/dspace#L69 It looks like: JAVA_OPTS="-server -Xmx512m -XX:MaxPermSize=128m -XX:+CMSClassUnloadingEnabled"
[22:14] <kompewter> [ DSpace/dspace/bin/dspace at osukb · osulibraries/DSpace · GitHub ] - https://github.com/osulibraries/DSpace/blob/osukb/dspace/bin/dspace#L69
[22:21] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[22:27] <dspace_jvm> Java HotSpot(TM) 64-Bit Server VM warning: Insufficient space for shared memory file: /tmp/hsperfdata_root/16918 Try using the -Djava.io.tmpdir= option to select an alternate temp location.
[22:27] <dspace_jvm> thoughts? anyone
[22:42] * dspace_jvm (4c584c43@gateway/web/freenode/ip.76.88.76.67) Quit (Ping timeout: 250 seconds)
[23:01] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has left #duraspace
[23:02] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has left #duraspace
[23:39] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Quit: Ex-Chat)
[23:40] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.