Timestamps are in GMT/BST.
[6:29] -barjavel.freenode.net- *** Looking up your hostname...
[6:29] -barjavel.freenode.net- *** Checking Ident
[6:29] -barjavel.freenode.net- *** Found your hostname
[6:29] -barjavel.freenode.net- *** No Ident response
[6:30] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:30] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:30] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:30] -barjavel.freenode.net- [freenode-info] please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup
[8:13] * kostasp (5e44e61a@gateway/web/freenode/ip.94.68.230.26) has joined #duraspace
[9:49] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[12:19] * kostasp (5e44e61a@gateway/web/freenode/ip.94.68.230.26) Quit (Quit: Page closed)
[13:14] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has joined #duraspace
[13:15] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:19] * peterdietz (~peterdiet@server112.longsightgroup.com) has joined #duraspace
[14:41] * kevin (~KevinVdV@85.234.195.109.static.edpnet.net) has joined #duraspace
[14:42] * kevin is now known as Guest58541
[14:43] * Guest58541 is now known as KevinVdV
[14:43] * bram-atmire (~bram@85.234.195.109.static.edpnet.net) has joined #duraspace
[14:44] * roeland_atmire (~roeland_a@85.234.195.109.static.edpnet.net) has joined #duraspace
[15:01] * robint (81d7ec36@gateway/web/freenode/ip.129.215.236.54) has joined #duraspace
[15:01] * kdweeks (~Adium@2001:468:c80:a103:39e0:da53:2060:1451) has joined #duraspace
[15:01] <tdonohue> Hi all, my clock shows it's 15:00 UTC, which means it is time for our weekly DSpace Developers Meeting
[15:02] <tdonohue> https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-11-05
[15:02] <kompewter> [ DevMtg 2014-11-05 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-11-05
[15:02] <robint> tdonohue: how many weeks/days before you expect to go "on holiday" :)
[15:02] <tdonohue> A few quick notes before we get started...and robint just asked about one ;)
[15:03] <tdonohue> I'm heading on holiday (paternity leave) from Thurs, Nov 20 - Mon, Dec 8 (returning on that monday). My plan is to be completely offline during that timeperiod
[15:04] <tdonohue> So, it's not a long holiday, but I'll keep reminding you as it gets closer (just a few weeks away now).
[15:04] <tdonohue> (and dates may change slightly, but that's the latest estimate)
[15:04] <hpottinger> you'll be back in time to watch the new release roll out, but you'll miss testathon :-)
[15:05] <helix84> tdonohue: good luck with your own release. 3.0, right?
[15:06] <tdonohue> A few other notes: With the ending of Daylight Savings, I've pushed the JIRA Backlog Hour for today to 16UTC (as 14UTC is 8:00am for me, and too hard to achieve these days). So, for the time being, whenever there's a 15UTC meeting, JIRA Backlog will be *afterwards*
[15:06] <tdonohue> helix84: actually, 2.0... we have a 2 year old girl (almost 3), with another girl on the way
[15:06] <hpottinger> OK by me
[15:07] <hpottinger> My +1 was for the time change, in case it's not clear. :-)
[15:07] <tdonohue> One final note before business: You probably have already noticed the banners on the Wiki & JIRA. But, both systems will be unavailable from 9am-5pm EST on Saturday for system/server maintenance. I'll be posting this to all DSpace lists after this meeting as well.
[15:08] <tdonohue> I believe that's all the notes I have for today...but I'll let you know if I remember anything else ;)
[15:10] <tdonohue> So, moving along now to 5.0 Topics. I'm wondering if one of our RT fearless leaders (peterdietz or hpottinger) would like to update us on latest status, next steps, etc.?
[15:12] <tdonohue> are our RT fearless leaders around? :)
[15:13] <hpottinger> I refuse to accept the label of leader, as it might get me fired :-)
[15:13] <tdonohue> I'm aware that we have a rescheduled Testathon starting next week (needs an announcement to go out today/tomorrow). We need to get the demo site updated, an RC1 cut, some last bugs fixed prior to RC1...just don't have all the specifics myself
[15:13] <helix84> well, we're waiting for the last new feature to be merged (DSPR#621) which Pascal and Mark are working on, even as we speak.
[15:13] <kompewter> [ https://github.com/DSpace/DSpace/pull/621 ] - DS-2119. EZID IdentifierProvider Metadata Mapping. by mohideen
[15:13] <pbecker> helix84: I think we are close a solution. ;-)
[15:14] <tdonohue> I'll note I have a few more minor fixes for Flyway automatic DB updates to get in prior to RC1 (which I'll work on getting done today)... One of which was identified by CTU Developers (DS-2244)
[15:14] <helix84> other than that, we're finding and fixing a lot of bugs. We'd appreciate everyone to test these bugs which have a PR: https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+label%3Abug
[15:14] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+label%3Abug
[15:14] <kompewter> [ https://jira.duraspace.org/browse/DS-2244 ] - [DS-2244] Flyway migration failed - DuraSpace JIRA
[15:14] <bram-atmire> Is there any chance the SOLR version bump will still make it in RC1?
[15:14] <bram-atmire> or is this something we may address later, or reschedule for DSpace 6?
[15:15] <tdonohue> bram-atmire: good question. I'm not aware of anyone working on that....but maybe I'm not up-to-date?
[15:15] <helix84> bram-atmire: I've seen your comment, but do we need a Solr version bump? I'm not aware of anything in DSpace 5 that requires it.
[15:16] <hpottinger> bram-atmire, I actually tried bumping Solr up, as it looks like it might address our transitive dependeny issue with restlet, but it died in flames
[15:17] <helix84> on a related note, one of the big features in 5.0 is easy multi-version upgrade from virtually any previous release thanks to Flyway (DB migration). We'll also need migration for Solr data. I wrote up a proposal here: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.0+Status#DSpaceRelease5.0Status-Solrupgrade(WIP)
[15:17] <kompewter> [ DSpace Release 5.0 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.0+Status#DSpaceRelease5.0Status-Solrupgrade(WIP)
[15:18] <bram-atmire> Our current version is plagued by this bug: https://issues.apache.org/jira/browse/SOLR-5173
[15:18] <kompewter> [ [SOLR-5173] Solr-core's Maven configuration includes test-only Hadoop dependencies as indirect compile-time dependencies - ASF JIRA ] - https://issues.apache.org/jira/browse/SOLR-5173
[15:18] <bram-atmire> causing DS-1997
[15:18] <kompewter> [ https://jira.duraspace.org/browse/DS-1997 ] - [DS-1997] INFO: validateJarFile message in catalina.out - DuraSpace JIRA
[15:18] <bram-atmire> other than that, a version bump will allow pdietz to also bump elasticsearch
[15:18] <bram-atmire> and in general, performance is better and more features are available
[15:19] <bram-atmire> Those are the reasons I know of, maybe others have other reasons as well
[15:19] <roeland_atmire> I had a look at the version bump earlier today and the furthest I can cleanly go is to 4.6.1
[15:19] <helix84> bram-atmire: sounds good. let's collaborate on a plan to also enable easy Solr migration from 1.6 to whatever we decide to upgrade to.
[15:19] <bram-atmire> “cleanly” meaning without massive rework?
[15:20] <tdonohue> bram-atmire: I think we all agree a version bump would be *nice*. It's just a matter of timing at this point. We'd need someone to do the work to make it happen ASAP, and ensure that it's still stable.
[15:20] <roeland_atmire> the later versions pull in a lot of jetty stuff through sloppy maven dependencies
[15:20] <roeland_atmire> so the same exclusions would have to be applied
[15:22] <tdonohue> Anyone want to take on the challenge of looking how far we can "easily" bump up Solr?
[15:22] <helix84> would it work for Atmire if the RT gives you free reins in this?
[15:22] <peterdietz> (missed this #duraspace window) yeah. As far as we can move to newer version the better. If its just extra dependencies, then maybe we can add the exclusions
[15:24] <roeland_atmire> one remark. I would prefer *not* to bump lucene: this will probably break the lucene indices. as solr is a separate webapp we can have a higher lucene version in the solr webapp than in the dspace-api
[15:24] <hpottinger> oh, speaking of free reins, I asked grahamtriggs if he wanted to "just fix" some of his findbugs bugs
[15:24] <helix84> roeland_atmire++
[15:25] <hpottinger> no reply from grahamtriggs yet
[15:25] <peterdietz> Doesn't bumping solr/ES kind of require lucene to bump as well?
[15:25] <helix84> hpottinger: he did reply - that he won't have the time before the release, but he'll prepare some materials about how to use findbugs
[15:26] <peterdietz> probably too late in the release process to remove lucene index code
[15:26] <helix84> peterdietz: lucene jars are bundled in the solr war
[15:26] <roeland_atmire> the solr and lucene version need to be the same within the solr webapp but not in the dspace-api
[15:27] <hpottinger> aha, I see the note now, helix84, thanks for letting me know
[15:27] <pbecker> roeland: doesn't using a newer lucene version in solr bump the lucene index to that version automatically?
[15:29] <roeland_atmire> it could but shouldn’t
[15:29] <roeland_atmire> if it does it’s a bug
[15:29] <pbecker> roeland: even if solr is writing stats?
[15:30] <pbecker> s/stats/access statistics
[15:30] <kompewter> pbecker meant to say: roeland: even if solr is writing access statistics?
[15:30] <helix84> pbecker: pom.xml has separate lucene.version and solr.version. We pull in the Solr war from Maven Central whole, with its own Lucene jars included.
[15:30] <pbecker> alright.
[15:31] <helix84> pbecker: the statistics core is written to by the Solr webapp. DSpace Lucene doesn't access it directly, AFAIK.
[15:31] <roeland_atmire> helix84++: that is precisely why we can have separate versions
[15:31] <pbecker> I was just wondering if lucene would make some kind of auto upgrade to an index. so if solr would write (using a newer lucene) some indexes....
[15:31] <pbecker> I see.
[15:31] <helix84> peterdietz: maybe Anja's statistics for REST did that, but that's not in 5.0
[15:32] <peterdietz> ok, so someone may or may not bump the lucene/solr/ES versions in time for release.
[15:32] <tdonohue> So, does @mire (roeland_atmire) plan to investigate bumping up Solr here in the next few days? Or do we need to find a volunteer
[15:32] <hpottinger> first up we need a JIRA issue for the work
[15:32] <tdonohue> +1 to a JIRA ticket
[15:32] <helix84> RT: let's confirm the deadlines first. Obviously the Solr bump would need to happen before rc1.
[15:33] <helix84> currently we have November 6 - Release Candidate 1 tagged. https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.0+Status#DSpaceRelease5.0Status-TimelineandProcessing
[15:33] <kompewter> [ DSpace Release 5.0 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.0+Status#DSpaceRelease5.0Status-TimelineandProcessing
[15:33] <tdonohue> Current deadlines (as I know them): RC1 would be released tomorrow (or Fri at latest), Testathon is scheduled to start on Monday (Nov 10)
[15:34] <hpottinger> also, that status page has the Solr version on it...
[15:34] <helix84> I volunteer to upgrade demo
[15:34] <tdonohue> thanks helix84!
[15:34] <helix84> hpottinger: that's just WIP, suggestion how to ensure that multi-version upgrades work
[15:35] <helix84> hpottinger: it won't be in release notes in this form
[15:35] <hpottinger> understood, just saw it so I thought I'd mention it
[15:35] <tdonohue> So, with regards to Solr version bump, it sounds like we don't have anyone jumping forward to volunteer. There's still some time to make this happen, but it'd need to be ASAP and the RT would need to be aware of the work.
[15:36] <roeland_atmire> i will upgrade it
[15:36] <helix84> so, is Atmire willing to do the work within the current deadlines?
[15:36] <helix84> OK, RT, are we fine with it? I'm adding my +1
[15:36] <hpottinger> we're hoping to sneak in DSPR#621, I think, so we can also get the Solr bump then
[15:36] <kompewter> [ https://github.com/DSpace/DSpace/pull/621 ] - DS-2119. EZID IdentifierProvider Metadata Mapping. by mohideen
[15:36] <tdonohue> thanks roeland_atmire! Please create a JIRA ticket for the work as well. We'll look forward to seeing a PR soon
[15:37] <pbecker> Can we go on and talk about DS-2249 or is anything left regarding solr?
[15:37] <kompewter> [ https://jira.duraspace.org/browse/DS-2249 ] - [DS-2249] Tomcat 7 JSP compiler Jasper defaults to Java 6 - DuraSpace JIRA
[15:37] <tdonohue> I'd be +1 a Solr version bump, as long as the PR shows it to be "stable" enough for an RC1. We need to be careful that it doesn't destabilize "master" obviously.
[15:38] <tdonohue> we can move along..I think we are done with the Solr version bump discussion
[15:38] <hpottinger> I'm +1 a Solr version bump, maybe it will address DS-1921?
[15:38] <kompewter> [ https://jira.duraspace.org/browse/DS-1921 ] - [DS-1921] Solr 4.4 has dependency on non Maven Central repository - DuraSpace JIRA
[15:38] <helix84> tdonohue: just a minute
[15:38] <helix84> we still don't have an automated upgrade for Solr <1.6,1.8> to 5
[15:39] <helix84> I prepared the plan and tested it using CLI tools, but we need someone to write the Java code
[15:39] <helix84> I thought to ask mhwood because it sounds like a fun little project, but he's working on EZID now
[15:39] <tdonohue> helix84 is talking about the fact that we need a clean path to upgrade Solr *Indexes* from older versions to latest version in DSpace 5.0.
[15:39] <tdonohue> his notes are here: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.0+Status#DSpaceRelease5.0Status-Solrupgrade(WIP)
[15:39] <helix84> roeland_atmire: could I work with you on this? I realize the schedule is tight.
[15:39] <kompewter> [ DSpace Release 5.0 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.0+Status#DSpaceRelease5.0Status-Solrupgrade(WIP)
[15:40] <roeland_atmire> @roeland_atmire I don’t think the two issues are related
[15:40] <tdonohue> (Just want to clarify that this is slightly *different*. It's about making sure older Solr indexes work with the latest version of Solr)
[15:40] <tdonohue> or, get *updated* to work with the latest version of Solr
[15:40] <helix84> roeland_atmire: They aren't. We just need both before rc1.
[15:41] <tdonohue> helix84: with regards to older Solr indexes, there's two options...(1) we try to find a way to 'script it' (i.e. automate it), or (2) we document clearly the steps involved to upgrade your Solr index if you are going from DSpace 1.6/1.7/1.8 to DSpace 5
[15:41] <hpottinger> doesn't the optimize script do this "update"?
[15:42] <tdonohue> hpottinger: "optimize" does the update, but newer versions of Solr cannot optimize really old indexes
[15:42] <helix84> tdonohue: correct on both counts
[15:42] <tdonohue> hpottinger: see helix84's notes...the Solr indexes created in DSpace 1.6/1.7/1.8 CANNOT be optimized by the Solr in DSpace 5
[15:44] <tdonohue> helix84: to be honest, I am worried this will be complex / time consuming to automate. I'm starting to lean towards just taking your notes and giving step-by-step documentation specific to DSpace 1.6/1.7/1.8
[15:44] <roeland_atmire> in newer versions of csv there is the data import handler that may extract it from the old type core and import it as new version
[15:44] <helix84> it would be nice to automate this sice DSpace 5 already automates DB upgrades so nicely
[15:44] <roeland_atmire> csv=solr
[15:44] <helix84> tdonohue: well, I can do it under 5 shell script lines...
[15:44] <tdonohue> roeland_atmire: do you have a link to that?
[15:45] <tdonohue> helix84: well, if you get a shell script that works (in time for RC1), then maybe we can quickly find someone to translate that to Java
[15:46] <helix84> roeland_atmire: right, but you would need to either have the old and new Solr both running at the same time or do the export beforehand, which adds additional manual steps anyway - in other workds, it doesn't improve the current options
[15:46] <hpottinger> +1 Solr + DSpace5 hackathon
[15:46] * tdonohue notes we are already at just 15mins left in this mtg
[15:47] <helix84> tdonohue: Sure, I can do that today. Just know that translating it to Java probably won't be a 1:1 mapping.
[15:47] <roeland_atmire> http://wiki.apache.org/solr/DataImportHandler
[15:47] <kompewter> [ DataImportHandler - Solr Wiki ] - http://wiki.apache.org/solr/DataImportHandler
[15:47] <tdonohue> helix84: understood. I think that a shell script is a good "proof of concept" solution. Once we have that, I hope we can find a way to recreate in Java (even if that step happens just post-RC1)
[15:48] * hpottinger notices there are still open tickets for PRs that were merged
[15:48] <helix84> tdonohue: the complications are mostly just in timing (we have to do the upgrade before we start the new Solr)
[15:48] <helix84> hpottinger: yes, some are still missing docs
[15:49] <helix84> hpottinger: we need a checklist for docs
[15:49] * pbecker would like to talk at least 5 minutes about DS-2249
[15:49] <kompewter> [ https://jira.duraspace.org/browse/DS-2249 ] - [DS-2249] Tomcat 7 JSP compiler Jasper defaults to Java 6 - DuraSpace JIRA
[15:49] <tdonohue> Ok, are we wrapped up with Solr discussions for now? It sounds like we have a few next steps. (1) roeland_atmire is going to investigate bumping up our Solr version, (2) helix84 is going to investigate creating a shell script to auto-update old Solr indexes (and then we'll find someone to help translate to Java)
[15:50] <helix84> I'd prefer to find someone now or decide to skipt it for RC1, I've had the steps documented on the wiki for a couple of days now. And I can write the script today.
[15:50] <tdonohue> Let's move along. Two more major topics for today. We have DS-2249, and we have to finalize our plans for Testathon.
[15:50] <kompewter> [ https://jira.duraspace.org/browse/DS-2249 ] - [DS-2249] Tomcat 7 JSP compiler Jasper defaults to Java 6 - DuraSpace JIRA
[15:51] <tdonohue> helix84: if you give me a shell script, I'll work to translate to Java. But, I'm NOT going to have time to do so prior to RC1. So, I'd suggest we just work towards a shell script for RC1, and then Java later.
[15:51] <helix84> tdonohue: agreed
[15:52] <tdonohue> So, DS-2249 next
[15:52] <kompewter> [ https://jira.duraspace.org/browse/DS-2249 ] - [DS-2249] Tomcat 7 JSP compiler Jasper defaults to Java 6 - DuraSpace JIRA
[15:52] <pbecker> first thanks again to roeland_atmire about bringing DS-2249 up. Just to give you a quick sum up: DSpace 4 requires tomcat 7 and java 1.7, DSpace 5 does as well (at least yet). but tomcat 7 uses by default java 1.6 to compile jsps.
[15:52] <kompewter> [ https://jira.duraspace.org/browse/DS-2249 ] - [DS-2249] Tomcat 7 JSP compiler Jasper defaults to Java 6 - DuraSpace JIRA
[15:52] <pbecker> so either we are going on to use java 1.6 for jsps and 1.7 for the rest of DSpace which can be confusing or we are looking for a solution.
[15:52] <tdonohue> is there any fix for this from the Tomcat team?
[15:53] <pbecker> you can configure tomcat to use 1.7 for jsps.
[15:53] <pbecker> that's easy but it has to be done *global* for all webapps run by this instance of tomcat.
[15:53] <helix84> and of course, it's an extra step for the dspace admin
[15:53] <pbecker> there is even a way to configure it by servlet but that would require to add tomcat specific code to our web.xml which I don't like.
[15:54] <tdonohue> why does it need to be done global, if only the JSPUI actually has JSPs to compile?
[15:54] <pbecker> I haven't found a way I like yet.
[15:54] <helix84> pbecker: do you know what happens when a different servlet container encounters the tomcat-specific elements in web.xml?
[15:54] <pbecker> it has to be done as init parameter for the jasper servlet which is the jsp engine in tomcat.
[15:54] <pbecker> helix84: not yet.
[15:54] <pbecker> the toppic come up to day (and I should have done other things. ;-))
[15:55] <pbecker> http://stackoverflow.com/questions/20370619/how-do-i-set-jasper-init-parameters-globally-for-all-servlets-in-tomcats-web-xm
[15:55] <kompewter> [ java ee - How do I set Jasper init parameters globally for all servlets in Tomcat's web.xml? - Stack Overflow ] - http://stackoverflow.com/questions/20370619/how-do-i-set-jasper-init-parameters-globally-for-all-servlets-in-tomcats-web-xm
[15:55] <pbecker> The first answer has an update that tells it is possible to add the jasper servlet init to the web.xml of any webapp.
[15:55] <pbecker> sorry, I just mixed it up. It can be done by webapp and not by servlet (my fault).
[15:56] <tdonohue> so, why not just tweak the JSPUI 'web.xml' to init properly?
[15:56] <pbecker> so we could add this to the jspuis web.xml, but I don't know yet what this means for any other servlet container then tomcat.
[15:56] <helix84> tdonohue: those would be tomcat-specific parameters in web.xml
[15:56] <pbecker> tdonohue: cause it seems to be tomcat specific code.
[15:56] <roeland_atmire> what they said
[15:57] <tdonohue> TBH, I don't think we have many users who do NOT use Tomcat. I think you're worrying about 1% of the user base...unless you all know of a large amount of users on a different servlet container
[15:57] <pbecker> I would suggest to leave the situation as it is and use java 1.6 in the jsps. With DSpace 6 I would like to require tomcat 8 which uses java 1.7 by default to compile jsps.
[15:57] <tdonohue> So, if it "works" for 99% of the users, then we just add a comment that says: "If you are NOT using Tomcat, you may wish to comment out these Tomcat specific params"
[15:57] <hpottinger> I'd be more comfortable depending on documentation for this, it's not our job to fix a Tomcat bug
[15:58] <helix84> tdonohue: what about jetty for automated testing? (although that probably won't aply to JSP)
[15:58] <tdonohue> we don't use jetty, helix84
[15:59] * hpottinger has seen Jetty testing setups for DSpace, there's a writeup on one somewhere...
[15:59] <pbecker> I would go with hpottinger: we already have tomcat specific documentation. We can add it there. Or leave the situation as it is and require tomcat 8 for DSpace 6 which would solve it as well.
[15:59] <tdonohue> Honestly, DSpace is extremely Tomcat specific already. While it should be *possible* to run it on other servlet containers, as far as I'm aware, we NEVER test on anything other than Tomcat
[16:00] <pbecker> tdonohue: I would prefer to loosen the tomcat dependency then to increase it.
[16:00] <helix84> tdonohue: If you're arguing for just documenting it, then we're not making DSpace any more Tomcat specific (not modifying jspui's web.xml)
[16:00] <tdonohue> So, we have two options. Add these init-params to the JSPUI, web.xml, or just document it.
[16:00] <helix84> pbecker++
[16:00] <hpottinger> I'm +1 document it
[16:00] <helix84> I notice we're mostly XMLUI guys here making a JSPUI decision
[16:01] <helix84> we don't have to decide now
[16:01] <pbecker> the question is: do we want to document it and use the same java version for jsps and the rest or do we want to use java 1.6 for dspace-5-jsps and upgrade to tomcat 8 with dspace 6?
[16:01] <tdonohue> pbecker: but that's a completely different discussion. I'd rather we not mix up two conversations. I'd be OK with loosening our requirements, but that's a *much bigger* discussion than this 2249 ticket (and one that'd need to happen *after* 5.0 at this point)
[16:01] <roeland_atmire> I would say document now and see if we can find a better solution by rc2
[16:01] <helix84> roeland_atmire++
[16:02] <tdonohue> documenting it for now is fine by me
[16:02] <pbecker> perhaps I should mention that we currently have only one jsp using java 1.7 which was fixed to day.
[16:02] <pbecker> okay. So I document it in the ticket and the DSpace 5 docs.
[16:02] <tdonohue> sounds good
[16:02] <pbecker> and I leave the ticket open for now.
[16:03] <helix84> we also should put keep track of these outstanding tasks to the release status page
[16:03] <hpottinger> OK, so, to be clear, it's OK to keep letting Tomcat 7 using 1.6 for JSPs, just it might catch someone else out
[16:03] <pbecker> and thanks again to roeland: his comment was really helpful on investigating this!
[16:03] <tdonohue> So, moving along to 5.0 Testathon next week. We need an announcement sent to lists (any volunteer?), we need demo updated (helix84 already volunteered), we need someone to actually cut RC1 (volunteer?)
[16:04] <pbecker> sorry, one minute
[16:04] * robint (81d7ec36@gateway/web/freenode/ip.129.215.236.54) has left #duraspace
[16:04] <hpottinger> I can pull the lever on RC1, but one of the new people might want to give it a shot
[16:04] <pbecker> was this a decision to use java 1.7 in jsps and document how to configure it in tomcat? that's what I understood.
[16:04] <KevinVdV> <= Needs to run, until next time
[16:04] * KevinVdV (~KevinVdV@85.234.195.109.static.edpnet.net) Quit (Quit: KevinVdV)
[16:05] <tdonohue> pbecker: you're asking a JSPUI question to folks who mostly work with XMLUI. I'm fine with delegating this to those of you who use JSPUI on a regular basis
[16:06] <pbecker> alright.
[16:06] <tdonohue> pbecker: so whatever you feel is best
[16:06] <hpottinger> pbecker: I think the decision was to document how to get Tomcat to use Java 1.7 in JSPs, so no new development is caught in the same trap
[16:06] <pbecker> thanks.
[16:06] <tdonohue> no, on to Testathon. We need to finalize Testathon details today obviously.. Volunteer to send out the announcement?
[16:08] <hpottinger> I volunteer to send the announcment, as long as we work out the details now, otherwise I'll just be making them up :-)
[16:08] <tdonohue> hpottinger: you probably can steal some text from the 4.0 Testathon announcement last year
[16:08] <tdonohue> and thanks!
[16:08] <hpottinger> will do
[16:09] <tdonohue> here was the 4.0 announcement: http://dspace.2283337.n4.nabble.com/DSpace-4-0-Testathon-begins-Nov-4-Users-Feedback-wanted-tt4668505.html
[16:09] <kompewter> [ DSpace - Tech - DSpace 4.0 Testathon begins Nov 4 -- Users / Feedback wanted | Threaded View ] - http://dspace.2283337.n4.nabble.com/DSpace-4-0-Testathon-begins-Nov-4-Users-Feedback-wanted-tt4668505.html
[16:09] <tdonohue> Any other details the RT would like help on regarding 5.0 or Testathon?
[16:10] <tdonohue> Or any other questions/comments anyone has on 5.0 next steps?
[16:11] <tdonohue> Ok, not hearing any other topics. We'll close out the meeting for today. Thanks all! Honestly 5.0 is looking amazing, and thank you all for your hard work here!
[16:12] * tdonohue is moving over to #dspace at this point
[16:13] * roeland_atmire (~roeland_a@85.234.195.109.static.edpnet.net) has left #duraspace
[16:16] * hpottinger is very distracted, may have to reconsider running IRC on another computer
[16:17] * helix84 updated Tomcat 7 on demo.dspace.org to use Java 7 for JSPs
[16:25] <pbecker> helix84: thanks!
[16:35] * hpottinger (~hpottinge@mu-161251.dhcp.missouri.edu) Quit (Quit: Later Taterz!)
[16:36] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has joined #duraspace
[16:41] * bram-atmire (~bram@85.234.195.109.static.edpnet.net) Quit (Quit: bram-atmire)
[19:12] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[19:31] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[22:05] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:18] * peterdietz (~peterdiet@server112.longsightgroup.com) Quit (Quit: peterdietz)
[23:11] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has left #duraspace
[23:22] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.