Timestamps are in GMT/BST.
[6:36] -hobana.freenode.net- *** Looking up your hostname...
[6:36] -hobana.freenode.net- *** Checking Ident
[6:36] -hobana.freenode.net- *** Found your hostname
[6:37] -hobana.freenode.net- *** No Ident response
[6:37] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:37] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:37] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:18] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:51] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[13:16] * PeterDietz (~peterdiet@dhcp-164-107-110-35.osuwireless.ohio-state.edu) has joined #duraspace
[13:57] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[13:59] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[14:28] * PeterDietz (~peterdiet@dhcp-164-107-110-35.osuwireless.ohio-state.edu) Quit (Remote host closed the connection)
[14:29] * PeterDietz (~peterdiet@128.146.173.70) has joined #duraspace
[14:59] * PeterDie_ (~peterdiet@dhcp-164-107-110-35.osuwireless.ohio-state.edu) has joined #duraspace
[15:03] * PeterDietz (~peterdiet@128.146.173.70) Quit (Ping timeout: 264 seconds)
[15:52] * PeterDietz (~peterdiet@dhcp-164-107-110-35.osuwireless.ohio-state.edu) has joined #duraspace
[15:53] * PeterDie_ (~peterdiet@dhcp-164-107-110-35.osuwireless.ohio-state.edu) Quit (Ping timeout: 240 seconds)
[15:55] * PeterDietz (~peterdiet@dhcp-164-107-110-35.osuwireless.ohio-state.edu) Quit (Remote host closed the connection)
[15:56] * PeterDietz (~peterdiet@dhcp-164-107-110-35.osuwireless.ohio-state.edu) has joined #duraspace
[16:01] * PeterDietz (~peterdiet@dhcp-164-107-110-35.osuwireless.ohio-state.edu) Quit (Ping timeout: 264 seconds)
[18:15] * PeterDietz (~peterdiet@dhcp-164-107-110-35.osuwireless.ohio-state.edu) has joined #duraspace
[19:01] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[19:07] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[19:41] * bollini (~chatzilla@host56-223-dynamic.181-80-r.retail.telecomitalia.it) has joined #duraspace
[19:46] * KevinVdV (~KevinVdV@d5153D041.access.telenet.be) has joined #duraspace
[20:00] <tdonohue> Hi all. Time for our weekly DSpace Developers Mtg. Agenda posted at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-08-07
[20:00] <kompewter> [ DevMtg 2013-08-07 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-08-07
[20:00] <tdonohue> We'll start off with a few PR reviews. Here's our list: https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:00] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:01] <tdonohue> today we begin with #203 https://github.com/DSpace/DSpace/pull/203
[20:01] <kompewter> [ Ds 1510 by MinDogger · Pull Request #203 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/203
[20:01] <tdonohue> related to DS-1510
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-1510 ] - [#DS-1510] Reference theme breaks Collection page flow when license text entered - DuraSpace JIRA
[20:02] <tdonohue> hmm.. that PR has an extra change in it related to copying LDAP configs to build.properties. https://github.com/DSpace/DSpace/pull/203/files
[20:02] <kompewter> [ Ds 1510 by MinDogger · Pull Request #203 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/203/files
[20:03] <mhwood> Wait until you see #204, which is the same for 3.x.
[20:03] <helix84> -1 to the LDAP part
[20:03] <mhwood> Er, some other branch anyway.
[20:04] <tdonohue> yikes. Yea, both #203 and #204 seem to have accidental "extra commits" in the PR. https://github.com/DSpace/DSpace/pull/204/files
[20:04] <kompewter> [ Ds 1510 by MinDogger · Pull Request #204 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/204/files
[20:04] <tdonohue> So, sounds like we need to request a "fresh PR" in both cases. The fix (from what I can tell) *seems* reasonable. But, it might require a quick verification
[20:06] <mhwood> I'd want to know why the additional test was put in, before taking it out.
[20:07] <tdonohue> which "additional test" are you talking about? I think I'm missing the context
[20:07] <tdonohue> oh, I see.. the part after the "OR" that he removed from the XSL
[20:07] <tdonohue> nevermind..I understand
[20:07] <mhwood> Yes.
[20:10] <tdonohue> ok.. added a comment to #203 and #204. Please feel free to add more notes as needed.
[20:11] <tdonohue> let's try one more (as we're a bit behind in PRs)... #205 : https://github.com/DSpace/DSpace/pull/205
[20:11] <kompewter> [ [DS-1519] Workflow and submission process selection based on community hierarchy by nesovi · Pull Request #205 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/205
[20:11] <tdonohue> related to DS-1519
[20:11] <kompewter> [ https://jira.duraspace.org/browse/DS-1519 ] - [#DS-1519] Submission process and workflow selection considering the community's hierarchy - DuraSpace JIRA
[20:13] <hpottinger> sounds pretty handy, actually
[20:13] <tdonohue> it does, I agree...skimming code
[20:13] <hpottinger> oh, good grief, a green merge button
[20:14] <tdonohue> would definitely need some docs along with it. But, it looks promising to me, at a glance (skim of code)
[20:15] <bollini> ok for me too
[20:15] <tdonohue> But, it sounds really powerful..."inheritance of workflow/submission forms" - nice flashy feature possibly for 4.0
[20:16] <hpottinger> +1 tdonohue, I was thinking the same
[20:16] <mhwood> Sounds good but needs thorough review, more than we can do here.
[20:16] <tdonohue> Anyone want to take a moment to try it out? I'd be +1 getting this in 4.0...just might be worth someone trying to run it and make sure it "works" reasonably enough
[20:17] <hpottinger> I wonder if we have any other PRs to fit in the "inheritance" theme?
[20:17] <tdonohue> (obviously we'd also need some doc updates....but those could come later on.. and we could bang on this more during Testathon)
[20:18] <tdonohue> so, all we need right now is a volunteer to review/try it out? any takers?
[20:21] <tdonohue> ok, hearing none... I'll just add a comment & mark it for 4.0 for now
[20:22] <tdonohue> ok..stopping there
[20:23] <hpottinger> sorry, I'm going to volunteer for reviewing 1519, as it would be immediately useful for our consortium-run repository
[20:23] <helix84> regarding DS-1609 - I reminded Joao via SMS, but he hasn't responded. He might be on holiday, can't get hold of him.
[20:23] <tdonohue> go for it hpottinger.
[20:23] <kompewter> [ https://jira.duraspace.org/browse/DS-1609 ] - [#DS-1609] DSpace 3.2 OAI-PMH Functionality needs JDK 1.7 (Java 7) - DuraSpace JIRA
[20:24] <mhwood> Thanks helix84
[20:24] <helix84> I think if we want to make progress here, we should just release 3.3 with the OAI patch reverted
[20:24] <tdonohue> ok. yea, I was gonna ask about Joao. I haven't heard anything from him either. We're essentially waiting on him for 1609
[20:24] <helix84> and I'm sorry about that, because I called the vote about that broken patch
[20:25] <tdonohue> what do others think here? Should we push out an immediate 3.3 and revert the OAI patch causing this issue? Should we give Joao a few more days (or week max) to respond?
[20:26] <helix84> the thing is, Joao had now 2 weeks (I think) to respond
[20:26] <bollini> oai without the patch doesn't really work right?
[20:27] <bollini> so people can use the new version if they already have java7 or disable oai if they are on java6
[20:27] <helix84> OAI in 3.1 works, but doesn't work for a few people (timezone issue)
[20:27] <helix84> OAI in 3.2 doesn't work at all
[20:27] <tdonohue> 1609 was opened one week ago (31st). Discussion on the lists about this issue started on July 29th. So, Joao has just been unresponsive for a little over a week.
[20:29] <hpottinger> the license on xoai would allow us to "bring it in" similar to what we had to do with Cocoon, I think?
[20:29] <tdonohue> yes, hpottinger. It's licensed Apache 2, which allows for re-distribution & modification
[20:30] <hpottinger> I realize one does not fork lightly... but, you know... 3.2 is a security release...
[20:31] <tdonohue> yep. I agree. we don't want to discourage fixing that security issue
[20:32] <tdonohue> So, we could technically "fork" XOAI into a new "DSpace/xoai" project, apply the fix, and release it to Maven under "org.dspace.dspace-xoai" (Then apologize later to Joao but explain the reasons why we had to temporarily do so)
[20:33] <tdonohue> My only questions were around whether it's worth that effort. At this point, it may be...as Joao seems to be unresponsive.
[20:33] <helix84> that would work, if there's a volunteer
[20:33] <mhwood> Or we could back that PMH update out and re-add it later when it's tidied up.
[20:34] <helix84> yes, I suggested that because it sounds like less work, with more work in the future to do a proper fix
[20:34] <tdonohue> yea...the other option is backout the PMH change (essentially "undo" DS-1479 and some other minor bug fixes) and release 3.3
[20:34] <kompewter> [ https://jira.duraspace.org/browse/DS-1479 ] - [#DS-1479] In OAI-PMH "Identify" response, the <description> is no longer configurable - DuraSpace JIRA
[20:36] <tdonohue> Here's the exact commit to "backout" from 3.x branch: https://github.com/DSpace/DSpace/commit/a27254f8c5a9eb384130104a4d69936151ebd04b
[20:36] <kompewter> [ backport DS-1479 to 3.x (bugfix, but also a small new feature and depend... · a27254f · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/commit/a27254f8c5a9eb384130104a4d69936151ebd04b
[20:36] <hpottinger> choice is: a) take on more responsibility, and do two releases or b) choose to keep a bug, and do one release
[20:38] <tdonohue> yep, essentially that's the choice. (And I don't recall what other bugs may be fixed in XOAI itself between the "2.2.9" and "3.0.0" releases)
[20:38] <tdonohue> wait? https://github.com/lyncode/xoai/commits/master JOAO!
[20:38] <kompewter> [ Commits · lyncode/xoai · GitHub ] - https://github.com/lyncode/xoai/commits/master
[20:39] <tdonohue> he merged the fixes into XOAI
[20:39] * hpottinger is dizzy
[20:39] <tdonohue> (yesterday)
[20:40] <helix84> yay, SMS worked && Joao is alive!
[20:40] <hpottinger> already in Maven Central: http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22xoai%22
[20:40] <kompewter> [ The Central Repository Search Engine ] - http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22xoai%22
[20:41] <helix84> wait... on maven? how is it possible? I still see 3.0.0 there
[20:41] <tdonohue> oh, so he just re-released XOAI 3.0.0? Huh. Didn't know you could actually do that to Maven Central
[20:41] <tdonohue> 3.0.0 release date now says yesterday though (Aug 6)
[20:42] <tdonohue> So, it looks like he pushed out a new release yesterday... I wonder if that fixes things for 3.2 (if you run "mvn -U package" that should *force* maven to pull down new copies from Central)
[20:43] <mhwood> Or you can just delete 3.0.0 from ~/.m2/repository/ and Maven will *have* to refetch it.
[20:43] <tdonohue> Anyone want to give that a try? i.e. rebuild DSpace 3.2 (using "mvn -U package") with Java 6 and see if our issue is fixed?
[20:43] <helix84> but yes, the re-released xoai requires java 1.6
[20:43] <helix84> sure, i'll tray it later today
[20:44] <tdonohue> thanks, helix84. I'm hoping that means we can close 1609 and tell folks to run "mvn -U package"! (fingers crossed)
[20:44] <helix84> even if it works, we might still want to release a clarification to the lists for those who already upgraded to 3.2 and use java 1.6
[20:44] <tdonohue> yes..we definitely should respond to that thread on the lists..and add a comment to Ds-1609 to explain things
[20:45] <tdonohue> thanks to Joao though!
[20:45] <helix84> hpottinger: so did the new xoai you patched work for you locally?
[20:46] <hpottinger> helix84: it did, but I'd want to test this new artifact anyway :-)
[20:46] <helix84> sure, i just wanted to double check (this time ;))
[20:46] <tdonohue> Ok. running short on time here... so, I'm gonna move along to the next topic
[20:46] <helix84> ok, we can move on
[20:46] <tdonohue> next up is DS-1188
[20:46] <kompewter> [ https://jira.duraspace.org/browse/DS-1188 ] - [#DS-1188] collection view doesn't show content by default - DuraSpace JIRA
[20:47] <helix84> there are now patches for both JSPUI and XMLUI
[20:47] <helix84> I just put the JSPUI one on demo: http://demo.dspace.org/jspui/handle/10673/24
[20:47] <hpottinger> so, I can scratch 3.3 off my todo list
[20:47] <kompewter> [ DSpace Demo Repository: test 1 collection ] - http://demo.dspace.org/jspui/handle/10673/24
[20:47] <tdonohue> hpottinger: yes, hopefully, if all goes well :)
[20:47] <helix84> meanwhile I broke XMLUI on demo, sorry
[20:48] <helix84> here's the agenda point I wrote: Change how default collection page works. Comment on patches available for both JSPUI and XMLUI (thanks Keiji & Kevin!). In both cases implementation slightly differs from the specification in the ticket, but is still much more user-friendly than what we've had before. Does it require more work? Should we merge it anyway and perhaps keep improving it?
[20:48] <tdonohue> in my opinion, "something > nothing". But, I want something that doesn't break XMLUI ;)
[20:49] <tdonohue> the JSPUI one on demo looks fine to me..it's better than currently
[20:49] <helix84> tdonohue: no, it works on XMLUI on master, I just broke demo by backporting the XMLUI patch
[20:49] <KevinVdV> WHat does break mean ?
[20:50] <hpottinger> (fyi, Joao is emailing on dspace-tech right now)
[20:50] <helix84> KevinVdV: nevermind, I just failed the backport to 3.x, I tested it successfully on master
[20:50] <tdonohue> Also, to be honest, we probably shouldn't be making these changes to Demo (yet). Demo is supposed to be 3.2 right now. We shouldn't be adding 4.0 features until we get closer to Testathon, etc.
[20:50] <helix84> I put it on demo just a few minutes ago for this DevMtg
[20:50] <KevinVdV> Oh ok great, as long as it works on the master.
[20:51] <helix84> sure, I'll revert it back to 3.1, it's just for your convenience
[20:51] <bollini> but are not the slf4j issues actually blocking the master to work...?
[20:52] <tdonohue> helix84: thanks. Yea, we should revert back on demo
[20:52] <KevinVdV> I kinda had to fix the sl4J issue to get my patch to work :D
[20:52] <helix84> tdonohue: reminding you about our OR13 talk about multiple demo servers :p
[20:52] <KevinVdV> Excluding it from the solrj in xoai solved it FOR NOW.
[20:52] <tdonohue> but in any case...what I see for the JSPUI looks "good enough" to me for Ds-1188. A screenshot of XMLUI would be nice.
[20:52] <KevinVdV> Gimme a second for the xmlui screen !
[20:53] <KevinVdV> Although I will need to make a small alteration, it shouldn't be enabled by default (for now)
[20:53] <tdonohue> helix84: yea...if I had more hands we could have more demo servers ;) Otherwise, we are more than welcome to add *more* webapps to that same demo server (e.g. "xmlui-test")
[20:53] <hpottinger> (more FYI, Joao seems to be asking us to "merge" xoai library)
[20:54] <helix84> I'll provide the XMLUI screenshot in a few minutes
[20:54] <tdonohue> seriously though, on demo.dspace.org server, anyone should be allowed to add more webapps. So, if you want to put up test content, just create a /xmlui-test/ webapp or similar.
[20:54] <KevinVdV> Oh ok thx helix
[20:55] <helix84> anyway, my point with the specification (as opposed to these implementations) was that the initial collection page should not be special (recent items should be just another normal index). both implementations still treat it specially, but it's much better than what we had until now.
[20:56] <mhwood> So you want us to revisit this later with a more comprehensive approach.
[20:56] <helix84> I'd like to
[20:56] <mhwood> I.e. don't close the issue yet.
[20:57] <helix84> I'd create two separate issues for the implementations and leave the original spec open.
[20:58] <helix84> http://i.imgur.com/01dycaK.png
[20:59] <tdonohue> I'd just suggest we rename or recreate the "spec" ticket -- currently the name of Ds-1188 is just "collection view doesn't show content by default"...and both these implementations now resolve that (as they show content by default)
[20:59] <helix84> (btw this kills two birds with one stone - there was also a request for a "more" link on "recently added")
[20:59] <KevinVdV> I would like to add a small commit to disable the XMLUI by default ?
[20:59] <helix84> KevinVdV: why?
[21:00] <KevinVdV> Are we in agreement that this should be the default view for collections ? If so fine for me ofc
[21:00] <helix84> +1
[21:01] <helix84> (that was the point)
[21:01] <KevinVdV> But no collection log/metadata is shown
[21:01] <KevinVdV> log == logo
[21:01] <tdonohue> I'd rather the default view show some content. But, the Collection logo & Metadata *must* still be shown
[21:01] <helix84> I see
[21:02] <helix84> heretic idea: could we just drop collection logo & description?
[21:02] <tdonohue> people would be angry if we took away the Collection logo & intro text. That's used heavily by Departments & also when you put a Journal Issue in DSpace (where the Issue = Collection, and Articles = Items)
[21:03] <helix84> ouch, point of my spec is defeated
[21:03] <hpottinger> I just want to be sure before we all go that we talk about DS-1586/PR 242, which KevinVdV mentioned (not specifically) a little while ago.
[21:03] <kompewter> [ https://jira.duraspace.org/browse/DS-1586 ] - [#DS-1586] SLF4J and JCL Bridge version incompatibility - DuraSpace JIRA
[21:03] <helix84> but I agree, that with the current implementation we need a simple option to switch back to the old behaviour
[21:05] <KevinVdV> I can disable the behaviour by default but leave the config option available for those who want to make the switch.
[21:05] <KevinVdV> It isn't a definitive solution but it is a start
[21:05] <helix84> KevinVdV: Agreed on off by default. Let me get back to the drawing board for a few days. Do you think you'll still have time to improve this before 4.0 if I figure out a solution?
[21:06] <tdonohue> yea, as-is, Ds-1188 would need to be "off" by default. Hopefully we can find a way to just display collection logo & intro text at the top of the page again, as needed.
[21:06] <KevinVdV> It will be very difficult to improve this further for 4.0 I fear
[21:07] <KevinVdV> I would also like to add that 1188 also includes a VIEW MORE link by default if disabled
[21:07] <helix84> KevinVdV: time-wise or code-wise difficult?
[21:07] <KevinVdV> time-wise
[21:07] <KevinVdV> Got my hands full with my daughter ;)
[21:07] <mhwood> Eh, we have to leave *something* for 5.0.
[21:07] <helix84> I know, thanks that you have worked on it anyway
[21:08] <tdonohue> time-wise could just mean we look for other volunteers to chip in...once the basics are there, maybe someone can help enhance
[21:08] <KevinVdV> Added commit to disable by default
[21:09] <tdonohue> Ok..we've run over time here. We seem to never get to nailing down 4.0 Schedule. I'd like to suggest we try this on -release again. It'll be topic #1 next week as well. We cannot delay this much more...otherwise we don't give folks time to plan.
[21:09] <tdonohue> hpottinger also mentioned DS-1586 above
[21:09] <kompewter> [ https://jira.duraspace.org/browse/DS-1586 ] - [#DS-1586] SLF4J and JCL Bridge version incompatibility - DuraSpace JIRA
[21:09] <helix84> Thanks, Kevin. I already have an idea about the final solution, I'll work on it and add it to the spec. Meanwhile I'll create separate tickets for these implementations. Is it OK if I merge them to master now?
[21:10] <hpottinger> there's a PR for 1586, #242, but there's also a patch submitted by mhwood, which I think he's planning to submit as a PR, thoughts?
[21:10] <KevinVdV> Perhaps we should discuss 1586 before merge ?
[21:10] <helix84> right
[21:11] <KevinVdV> All I did to fix was exclude the newer, but perhaps the better solution should be to upgrade the version.
[21:12] <KevinVdV> If anybody has tested this I would be +1 for this
[21:13] <tdonohue> regarding #242 - I think it's a good start, but I'd prefer mhwood's patch attached to DS-1586. I think we need to move this dependency up to 'dspace-parent' and manage it there.
[21:13] <kompewter> [ https://jira.duraspace.org/browse/DS-1586 ] - [#DS-1586] SLF4J and JCL Bridge version incompatibility - DuraSpace JIRA
[21:13] <mhwood> I did build with my patch and check the SLF4J JAR versions.
[21:13] <tdonohue> (but, as mdiggory noted on our commit list, we need to avoid accidentally overriding SLF4J for things like Solr....but, I think mhwood's patch looks safe)
[21:13] <KevinVdV> I can always adjusted my pull request accordingly
[21:13] <hpottinger> there's been a private discussion on the general topic on -commit, I'm generally in favor, though I don't know that we get to say what version of SLF4J Solr gets to use
[21:14] <mhwood> There is yet another issue for pulling dspace-solr into the main DSpace repository, and we'd have to be careful about insulating it from dependencyManagement.
[21:14] <KevinVdV> solr uses 1.6.1
[21:15] <mhwood> Yes, our problem was that we didn't keep up with slf4j and others do.
[21:15] <tdonohue> we don't get to say what version of SLF4J things like Solr use :) And yea, that is something to be aware of... if we pulled in "dspace-solr", we have to be *very careful* it doesn't inherit the wrong dependencies
[21:15] <mhwood> The stock POM should be specifying what they want. We just have to leave that in.
[21:16] <KevinVdV> I wouldn't worry about pulling in dspace-solr, the only thing using this is the solr webapp
[21:16] <tdonohue> mhwood: yep, agreed...it shouldn't be a bit deal. we just don't want to change the Solr "stock POM"
[21:16] <KevinVdV> The slfj dependency solr uses is pulled in by solrj which is the java intterface to talk to solr
[21:17] <tdonohue> ok. So, then...it all sounds reasonable (just needs testing). seems like we should be able to make mhwood's changes for Ds-1586, and also merge in dspace-solr
[21:18] <mhwood> I will do a PR for my patch. BTW the merge issue is DS-1612.
[21:18] <kompewter> [ https://jira.duraspace.org/browse/DS-1612 ] - [#DS-1612] Merge DSpace/dspace-solr project into DSpace/DSpace - DuraSpace JIRA
[21:18] <KevinVdV> the dspace-solr merge in requires some work though ;) doesn't pass the travis build
[21:19] <hpottinger> mhwood does a PR for 1586, I will test and merge ASAP (though I trust him if he wants to race me) :-)
[21:19] <mhwood> I'm going to have to leave soon but will do a PR tomorrow.
[21:19] <hpottinger> works for me
[21:20] <KevinVdV> Great, please log this in DS-1188 also so we don't forget about it
[21:20] <tdonohue> KevinVdV -- looks like Travis CI is just complaining about file headers (missing our default license) in dspace-solr. Likely they just need the default DSpace license pasted in the top
[21:20] <kompewter> [ https://jira.duraspace.org/browse/DS-1188 ] - [#DS-1188] collection view doesn't show content by default - DuraSpace JIRA
[21:20] <KevinVdV> Yep I noticed
[21:21] <mhwood> Anything else for me before I go?
[21:21] <tdonohue> Ok. I think we're wrapping up now. I have to head out shortly here too
[21:22] <tdonohue> so, I have no more topics to call. Just the reminder that we need to get 4.0 scheduling figured out soon
[21:22] <hpottinger> I need to run, too, but will be in IRC tomorrow morning and will test XOAI (DS-1609) and the new PR for DS-1586
[21:22] <kompewter> [ https://jira.duraspace.org/browse/DS-1609 ] - [#DS-1609] DSpace 3.2 OAI-PMH Functionality needs JDK 1.7 (Java 7) - DuraSpace JIRA
[21:22] <kompewter> [ https://jira.duraspace.org/browse/DS-1586 ] - [#DS-1586] SLF4J and JCL Bridge version incompatibility - DuraSpace JIRA
[21:23] <mhwood> OK, thanks all, 'bye.
[21:23] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:23] <hpottinger> and since "test XOAI" involves the exact changes the new PR will put in place, I'll probably test that first :-)
[21:24] <helix84> hpottinger++
[21:25] <helix84> btw now I don't know what I should be testing, so please prod me when you have it ready
[21:25] <hpottinger> helix84: I was just aluding to the fact that you can't actually get :master to install right now, due to the SLF4J version mismatch
[21:26] <KevinVdV> https://github.com/DSpace/DSpace/pull/267 should be fixed now
[21:26] <kompewter> [ [DS-1612] Merge DSpace/dspace-solr project into DSpace/DSpace by KevinVdV · Pull Request #267 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/267
[21:26] <helix84> I was able to do that with Kevin's patch to 1188, so that's one fix. But now with Mark's fix, I don't know what I should be testing.
[21:28] <KevinVdV> I believe ant updating & attempting to reindex discovery should do the trick, if that fails you know it ain't fixed.
[21:29] <helix84> I'm now officially lost :) I'll call it a night. Please, let me know when you have something you need me to test. Thanks.
[21:30] <KevinVdV> I also need to run now… until next week, if you need me feel free to email me
[21:30] <KevinVdV> I do keep track of those
[21:30] * KevinVdV (~KevinVdV@d5153D041.access.telenet.be) Quit (Quit: KevinVdV)
[21:31] <hpottinger> gotta run, will be here tomorrow
[21:31] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has left #duraspace
[21:31] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has left #duraspace
[21:37] * bollini (~chatzilla@host56-223-dynamic.181-80-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212])
[22:00] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has left #duraspace
[22:15] * PeterDietz (~peterdiet@dhcp-164-107-110-35.osuwireless.ohio-state.edu) Quit (Remote host closed the connection)
[22:15] * PeterDietz (~peterdiet@dhcp-164-107-110-35.osuwireless.ohio-state.edu) has joined #duraspace
[22:20] * PeterDietz (~peterdiet@dhcp-164-107-110-35.osuwireless.ohio-state.edu) Quit (Ping timeout: 248 seconds)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.
