Timestamps are in GMT/BST.
[0:07] * sbayliss (bcde58ad@gateway/web/freenode/ip.188.222.88.173) Quit (Quit: Page closed)
[6:53] -kornbluth.freenode.net- *** Looking up your hostname...
[6:53] -kornbluth.freenode.net- *** Checking Ident
[6:53] -kornbluth.freenode.net- *** Found your hostname
[6:53] -kornbluth.freenode.net- *** No Ident response
[6:53] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:53] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:53] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[9:34] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has joined #duraspace
[11:34] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) Quit (Quit: Leaving.)
[11:34] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has joined #duraspace
[12:21] * kshepherd (kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (*.net *.split)
[12:21] * kompewter (~kompewter@peterdietz.lib.ohio-state.edu) Quit (*.net *.split)
[12:21] * scottatm (~scottatm@voyager108.evans.tamu.edu) Quit (*.net *.split)
[12:21] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) Quit (*.net *.split)
[12:21] * elschlomo (8d421324@gateway/web/freenode/ip.141.66.19.36) Quit (*.net *.split)
[12:21] * ChanServ (ChanServ@services.) Quit (*.net *.split)
[12:21] * ablemann (~alexleman@lemanal.xen.prgmr.com) Quit (*.net *.split)
[12:21] * cbeer (~cbeer@198.147.175.203) Quit (*.net *.split)
[12:21] * GargantuaSauce (~Gargantua@142.176.125.39) Quit (*.net *.split)
[12:21] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) Quit (*.net *.split)
[12:24] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has joined #duraspace
[12:24] * GargantuaSauce (~Gargantua@142.176.125.39) has joined #duraspace
[12:24] * scottatm (~scottatm@voyager108.evans.tamu.edu) has joined #duraspace
[12:24] * ablemann (~alexleman@lemanal.xen.prgmr.com) has joined #duraspace
[12:24] * cbeer (~cbeer@198.147.175.203) has joined #duraspace
[12:24] * ChanServ (ChanServ@services.) has joined #duraspace
[12:24] * elschlomo (8d421324@gateway/web/freenode/ip.141.66.19.36) has joined #duraspace
[12:24] * kompewter (~kompewter@peterdietz.lib.ohio-state.edu) has joined #duraspace
[12:24] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) has joined #duraspace
[12:24] * kshepherd (kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[13:44] * GargantuaSauce (~Gargantua@142.176.125.39) Quit (*.net *.split)
[13:48] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[13:48] * GargantuaSauce (~Gargantua@142.176.125.39) has joined #duraspace
[14:33] * GargantuaSauce (~Gargantua@142.176.125.39) Quit (*.net *.split)
[14:41] * GargantuaSauce (~Gargantua@142.176.125.39) has joined #duraspace
[15:14] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Ping timeout: 240 seconds)
[15:39] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[15:54] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[19:13] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has left #duraspace
[19:57] <tdonohue> hi all, reminder that our DSpace Devel meeting starts here in a few minutes (at top of hour): https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-11-16
[19:57] <kompewter> [ DevMtg 2011-11-16 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-11-16
[19:57] * KevinVdV (~KevinVdV@d54C14B50.access.telenet.be) has joined #duraspace
[19:58] <KevinVdV> Hi everybody
[20:01] <tdonohue> Hi all. Seems like a smaller group today for our DSpace Developers meeting. But, maybe folks are running a bit late today. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-11-16
[20:01] <kompewter> [ DevMtg 2011-11-16 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-11-16
[20:01] <tdonohue> First up today is our normal JIRA catch-up. https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-892+ORDER+BY+key+ASC
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-892 ] - [#DS-892] Performance issues in update enabling the StatisticsLoggingConsumer - DuraSpace JIRA
[20:02] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-892+ORDER+BY+key+ASC
[20:02] <tdonohue> we kick off JIRA review with DS-892
[20:02] <kompewter> [ https://jira.duraspace.org/browse/DS-892 ] - [#DS-892] Performance issues in update enabling the StatisticsLoggingConsumer - DuraSpace JIRA
[20:03] <kshepherd> morning!
[20:03] <mhwood> Afternoon!
[20:03] <PeterDietz> hi
[20:04] <kshepherd> ok, 892 looks like a discussion more than a patch ;)
[20:04] <kshepherd> but it sounds like a useful discussion
[20:04] <tdonohue> true, now that I read it I see it is more a discussion (even though it's marked as a "bug")
[20:04] <mhwood> It's both?
[20:04] <kshepherd> maybe ask the folks with the biggest stats indexes to chip in with their experiences in the comments (experiences of autocommit impact, how long bactch updates take, etc)
[20:05] <KevinVdV> Well my experience is the fastest way to update is how it is done in DS-599
[20:05] <kompewter> [ https://jira.duraspace.org/browse/DS-599 ] - [#DS-599] SOLR statistics file download displays all files and not only those in the Bundle Original - DuraSpace JIRA
[20:05] <kshepherd> KevinVdV's patch to remove non-original bitstream entries will help get some index sizes down
[20:06] <PeterDietz> What does StatsLogConsumer not enabled by default mean?
[20:06] <tdonohue> mhwood -- actually you are right. It is a "bug" cause it is a problem in existing code (even though it's not enabled by default).
[20:06] <mhwood> If it was just slow, I'd say: find out why it's slow. But if auto-commit interferes, then we need to step back and look at the whole process.
[20:06] <kshepherd> hm, well, ok
[20:07] <KevinVdV> @ PeterDietz: if an item moves from the collection the stats records would NOT be updated, the consumer takes care of this
[20:07] <KevinVdV> Updating all the records indivualy
[20:07] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[20:07] <KevinVdV> Which can take a long time
[20:07] <mhwood> Pull it out into another thread.
[20:07] <kshepherd> stuartlewis: DS-892
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-892 ] - [#DS-892] Performance issues in update enabling the StatisticsLoggingConsumer - DuraSpace JIRA
[20:09] <PeterDietz> so if you didn't want to pay penalty during changes, you'd need a way to invoke statslogConsumer by cron
[20:09] <kshepherd> PeterDietz: i think the suggestion is to do batch updates from logs rather than use consumer at all
[20:10] <kshepherd> or did i mistunderstand?
[20:10] <KevinVdV> That could be doable...
[20:10] <PeterDietz> and then the other issue is stat activity that occurs when I might be restarting tomcat to change in input-form or something.. the last entries, are not committed to solr
[20:10] <mhwood> So we need a listener to catch container shutdown and flush?
[20:10] <PeterDietz> hmm. okay, well then if you want to disable the real-time stat logger, then everything is already built
[20:11] <PeterDietz> stats-log-converter, stats-log-importer
[20:11] <PeterDietz> no loss
[20:12] <PeterDietz> mhwood: Right, mdiggory had hinted at something like that, I haven't seen any traction
[20:12] <tdonohue> So it sounds like there's a couple things to investigate further here? Anyone want to pull these ideas back over to comments of Ds-892, or even volunteer to do some more investigation of options here?
[20:13] <tdonohue> (admittedly, this is an area that I'm not as familiar with yet -- so, if someone else would like to summarize some of these brainstorms over on Ds-892, that'd be helpful)
[20:14] <KevinVdV> I would be willing to look into it
[20:14] <KevinVdV> *assigning to me unless somebody objects ?*
[20:14] <tdonohue> go for it, KevinVdV
[20:14] <tdonohue> thanks!
[20:14] <PeterDietz> go for it.. I'm sure I've misread this issue
[20:14] <tdonohue> moving on then to DS-893
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-893 ] - [#DS-893] suggestion for a re-implementation of Bundles in the DSpace data model - DuraSpace JIRA
[20:15] <tdonohue> this is a larger "conceptual" discussion. Any quick comments here, or should we set this aside for later (i.e. a full discussion in a future meeting)
[20:15] <PeterDietz> I kind of hate bundles
[20:15] <mhwood> Seems to be related to discussion of spreading metadata to all objects.
[20:16] <tdonohue> +1 mhwood
[20:16] <PeterDietz> I would prefer something more akin to tagging the bitstream with some characteristics (i.e. bitstream metadata).
[20:16] <tdonohue> also, PeterDietz -- I think we all agree. Many of us are not fans of Bundles, but we just need to work to fix it :)
[20:16] <tdonohue> +1 PeterDietz
[20:17] <tdonohue> ok, I'll move on for now. One last one for today, DS-894
[20:17] <kompewter> [ https://jira.duraspace.org/browse/DS-894 ] - [#DS-894] Context Sensitive help for the XMLUI - DuraSpace JIRA
[20:17] <mhwood> Yes, adding bitstream metadata will make bundles go away.
[20:18] <tdonohue> I like the idea behind Ds-894. Would just need a volunteer or two to start chipping away at it little by little
[20:19] <tdonohue> any other thoughts on this? Do others at least agree with this conceptually?
[20:19] <mhwood> I agree.
[20:20] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:20] <tdonohue> ok. Ds-894 Summary: has some general support, just needs to have volunteer or two.
[20:20] <mhwood> It might be worth a little time to look at this more abstractly and see if there are ways to consolidate the texts, for example.
[20:21] <tdonohue> +1 mhwood
[20:21] <PeterDietz> I think jspui help still refers to netscape
[20:21] <tdonohue> Ok, we'll stop Jira review there for today. Anything left unassigned will be immediately assigned to latecomers like mdiggory (kidding)
[20:22] <kshepherd> lol
[20:22] <KevinVdV> lol
[20:22] <mhwood> I wonder if there's any way to extract from the full doco. automatically.
[20:22] <tdonohue> yea, JSPUI help needs updates too I'm sure.
[20:22] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:22] <mdiggory> thank you, as if I don't already have enough to do ;-)
[20:23] <tdonohue> Ok, in essence of time, I suggest we move along to Discussion topics: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-11-16 (Feel free to add any other comments to Ds-894 directly)
[20:23] <kompewter> [ DevMtg 2011-11-16 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-11-16
[20:23] <mdiggory> per full text indexing.... Solr already supports full text indexing of many formats, text extract is really not needed.
[20:24] <tdonohue> The main discussion topic for today is Release Coordination. Essentially, do we want to stay with the current "Release Coordinator" model, or move to a "Release Team" model? (This discussion already began on dspace-commit list late last week)
[20:24] <mhwood> We just need to stuff the text *into* Solr then, annotated with targets that can be indexed and called up by the UIs.
[20:25] <tdonohue> Anyone want to express opinions/thoughts/questions on Release Coordination and the idea of RC vs. RT? (I don't want to go into a whole summary here again, unless people need it -- I'm assuming you are all mostly up-to-speed though)
[20:26] <mdiggory> mhwood: Solr Cell... http://wiki.apache.org/solr/ExtractingRequestHandler
[20:26] <kompewter> [ ExtractingRequestHandler - Solr Wiki ] - http://wiki.apache.org/solr/ExtractingRequestHandler
[20:26] <PeterDietz> Tim, you don't like being the de facto Backup RC?
[20:26] * tdonohue recommends Solr discussion move to JIRA or #dspace -- it's a worthy discussion, but it's hard having two discussions here at once
[20:27] <mdiggory> uses Tika... http://tika.apache.org/
[20:27] <kompewter> [ Apache Tika - Apache Tika ] - http://tika.apache.org/
[20:27] <tdonohue> PeterDietz -- I'm always glad to be a *resource*. But, no, I'd rather not be the "de facto" Backup RC (as it essentially means I'm able to do less programming for that given release, and less of other things in general)
[20:27] <kshepherd> re RC vs RT, i see the idea, sounds good.. just not sure how it'd be organised
[20:27] <mhwood> If several who have done it agree that the job is becoming too large, then it probably is.
[20:28] <kshepherd> who organises it? how is that different from RC organising committers (who have volunteered) to help
[20:28] <mhwood> I imagine that there is still an RC, now assisted by his trusty lieutenants. Would the RC ask for volunteers?
[20:29] <PeterDietz> It somewhat makes sense to have one person be the maven-release doer, one person for ensuring the docs get updated, another person for pestering people to make their code public for big-features-in-progress (and potentially having jenkins/hudson do automated builds of some feature branches on the demo server)
[20:29] <kshepherd> split some roles up? new features vs bugfixes vs doco vs scheduling vs updates to/from DCAT and dspace-tech
[20:29] <kshepherd> PeterDietz: right
[20:30] <tdonohue> my view here is the RT would be slightly more "formalized" than just "committers who have volunteered". It would be essentially the same concept, but the RT is a way for the RC to feel more comfortable with delegating to these folks various tasks
[20:30] * kshepherd feels disappointed he never got a chance at a release :(
[20:30] <tdonohue> kshepherd +1 -- yea, RT folks would share various tasks (or volunteer for specific ones). The RC (or co-RC) would likely still delegate tasks to RT members
[20:30] <PeterDietz> I vote kshephed as RC for a simultaneous 1.9 and 3.0 release
[20:30] <kshepherd> (not *too* disappointed, mind, hehe)
[20:30] <kshepherd> lol
[20:31] <mhwood> Maybe the RC decides (with others' advice) how to build the team.
[20:31] <mhwood> And how to distribute the work.
[20:32] <tdonohue> so, in my mind, the RT is rather similar to a "group of committers who have volunteered to help" -- but, becoming a member of the RT actually means you are setting aside a small amount of time (1-2hrs a week, if that) to chip in on the release (in whatever way is needed)
[20:32] <kshepherd> yep that sounds good
[20:32] <tdonohue> that's what I mean by it's a bit more "formalized". You are a known resource for release tasks, and not just someone who said "sure, I can help if you need it, let me know!"
[20:33] <mdiggory> sounds fine with me
[20:33] <kshepherd> tdonohue: and you can use your role at duraspace to support that RT instead of being the general dogs body in the frantic last few weeks ;)
[20:33] <mhwood> A specific commitment, IOW, negotiated with the RC.
[20:33] <PeterDietz> dogs body?
[20:33] <kshepherd> maybe that's a british phrase
[20:34] <tdonohue> *exactly* kshepherd. I'd still be a resource, but hopefully we'd have more people who could share the tasks of that last few frantic weeks
[20:34] <mhwood> Dogsbody: something like assistant, henchman, minion?
[20:34] <tdonohue> mhwood -- yea, I'd agree with that too. The specific commitment could be worked out with the RC. Different RCs could also decide how they want to manage their Release Team (there's flexibility there too)
[20:36] <tdonohue> So, it's sounding like we are approaching a consensus to at least attempt the idea of an RT?
[20:36] <tdonohue> (obviously the first time around I'm sure we'll find things we can improve upon or tweak as we go)
[20:36] <mhwood> I imagine an RC posting a preliminary sketch of the way the work will be organized and asking for volunteers for pieces of it.
[20:38] <tdonohue> mhwood -- I think that's a good general idea, but that also assumes that the RC is well organized themselves :) I guess I'm willing to allow for flexibility here based on working styles. But, I like the idea of at least putting up a general sketch of how a release *normally* works
[20:38] <tdonohue> (that "general sketch" could even be done now by myself & recent RCs -- and then the upcoming 3.0 RC can use or adapt it as he/she sees fit)
[20:39] <mhwood> Isn't there already some material on the wiki about release coordination? Could it be fleshed out a bit?
[20:39] <tdonohue> +1 yea, there's some older material there that we could build from
[20:40] <tdonohue> https://wiki.duraspace.org/display/DSPACE/ReleaseCoordinating
[20:40] <kompewter> [ ReleaseCoordinating - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/ReleaseCoordinating
[20:40] <mhwood> Checklist item.last: "update this document with lessons learned"
[20:40] <tdonohue> good idea :)
[20:40] <PeterDietz> Do we want to cover some of the other "Developer Discussions" today? Since next week is a skip-week. I imagine that the details of next RC/RT will flesh itself out over time.
[20:41] <KevinVdV> Is next week a skip week ?
[20:41] <mhwood> Actually the topic of skipping next week is still to discuss.
[20:41] <PeterDietz> next week is US holiday, for eating turkey
[20:41] <tdonohue> yea, "possibly canceling next week" was the next topic to discuss
[20:41] <PeterDietz> so non-US will have to take it over
[20:42] <tdonohue> sounds like we are done with the RC/RT discussion for today. Dare I ask: Is anyone potentially interested in RC or RT-member for next release? You need to say right now, but you can email me if you are even "thinking about it"
[20:42] <kshepherd> we've been waiting for this since the 40s
[20:42] <kshepherd> WORLD DOMINATION IS IN OUR GRASP, COMRADES
[20:43] <kshepherd> THE AMERICANS WILL BE BUSY EATING TURKEY
[20:43] <mhwood> Well, some of us aren't travelling.
[20:43] <PeterDietz> hmm, maybe thats why Obama is in Oceana (Australia) right now... to sabotage military pre-empters
[20:44] <tdonohue> ok, so, as PeterDietz mentions -- in the USA, next Thurs is Thanksgiving holiday (where we all become slow & sleepy & weak after eating too much turkey). Many of us will also be traveling on Weds.
[20:44] <tdonohue> I cannot attend next week's meeting, myself. But, if others *can* still attend, you are obviously welcome to still have a meeting
[20:45] <KevinVdV> I will also not be able to attend next week since I have a futsal game
[20:45] <PeterDietz> I somewhat dispise this holiday. You do become sleepy by about 4pm, and then have to carry on the rest of the day while wearing an itchy wool sweater, and drinking profusely with relatives.
[20:45] <tdonohue> so, I guess the questions are: Do others want to meet next week? Or should we cancel next week?
[20:45] <aschweer> I'm fine either way -- I would be able to attend next week
[20:46] <kshepherd> we could have a quick jira review instead of meeting?
[20:46] <tdonohue> if several of you want to meet, you need not even have an agenda -- you can just chat DSpace or look at some JIRA issues, or just joke around :) It's all up to you. (just remember all that you say is logged)
[20:47] <mhwood> Unless we definitively cancel, I'll look in whether I have any issues or not.
[20:48] <tdonohue> yep, feel free to meet to just have a quick JIRA review. This week we left off at Ds-894. So, you'd start next week at Ds-895 (or just throw out specific issues if there are specific ones you want to bring to the discussion)
[20:48] <mhwood> If there are enough present, it would be good to keep slogging through JIRA.
[20:49] <mhwood> It sounds like there will be sort-of a meeting next week. Other issues?
[20:49] <tdonohue> Ok, so it sounds like: There will be a meeting next week for all who can make it. It will likely just involve a quick JIRA review
[20:49] <aschweer> https://jira.duraspace.org/browse/DS-1070 would be good to get some eyes on
[20:49] <kompewter> [ https://jira.duraspace.org/browse/DS-1070 ] - [#DS-1070] DSpaceObjectManager unnecessarily keeps references to DSpace objects - DuraSpace JIRA
[20:49] <kompewter> [ [#DS-1070] DSpaceObjectManager unnecessarily keeps references to DSpace objects - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1070
[20:50] <tdonohue> I had no other topics, so discussion of Ds-1070 sounds good to me
[20:50] <aschweer> it seems to have fixed the problem for us, but we've been having some other issues (most likely unrelated), so it'd be great to have others look at it
[20:50] <aschweer> essentially, Ds-1070 made 1.7.2 pretty much unuseable for us. the problem is still in trunk, so it's in 1.8 as well
[20:51] <tdonohue> aschweer -- I admit I haven't looked at this in much detail, but it looks reasonable to me at a glance (as long as it doesn't cause major performance areas elsewhere?). Though I personally don't understand why that ArrayList was there in the first place
[20:51] <KevinVdV> *Adds Ds-1070 to his long TODO list*
[20:52] <aschweer> tdonohue: I don't understand it either, which is why I think it's fine to just kick it out
[20:52] <tdonohue> I meant to say "major performance issues elsewhere"
[20:52] <PeterDietz> is there any reason why these objects get added to an arrayList?
[20:52] <aschweer> I think it's probably left over from refactoring
[20:52] <aschweer> or something
[20:52] <kshepherd> +1 to this patch, it's beautiful
[20:52] <aschweer> it's been in the code ever since xmlui was released as a standard dspace module
[20:52] <kshepherd> we have only tested for a few days so far
[20:53] <kshepherd> but results are looking *very* good, in terms of memory footprint
[20:53] <tdonohue> no idea, PeterDietz. Anyone know why this is? Maybe someone who helped build XMLUI in the first place (ahem, scottatm) would know or have an idea?
[20:53] <aschweer> I have some scary before/after heap usage graphs if anyone is interested...
[20:53] <scottatm> What's the question?
[20:53] <mhwood> So what does DSpaceObjectManager *do*, after the patch?
[20:53] <aschweer> thanks kshepherd
[20:53] <tdonohue> scottatm: DS-1070 -- any idea why all these objects are cached in an ArrayList?
[20:53] <kompewter> [ https://jira.duraspace.org/browse/DS-1070 ] - [#DS-1070] DSpaceObjectManager unnecessarily keeps references to DSpace objects - DuraSpace JIRA
[20:55] <tdonohue> scottam -- as noted in ticket & discussion above, this seems to cause XMLUI to have a large memory footprint, and aschweer & others wonder if we can just remove that caching altogether
[20:55] <scottatm> I believe that array is left over from previous version of DRI where objects were included inline with the document.
[20:56] <KevinVdV> +1 to the patch after looking into it
[20:56] <tdonohue> aha. thanks scottatm! So, it likely is an artifact of some refactoring/reworking
[20:56] <aschweer> scottatm: I suspected something like that. So you think my patch is fine?
[20:56] <scottatm> Yes, it's definitaly left over after refactoring.
[20:56] <scottatm> yes.
[20:56] <tdonohue> I'd say assuming this is been well tested, then +1 to the patch (and it may be a good reason to release a 1.8.1 in near future)
[20:56] <mhwood> Eww, in the copy I am looking at I see a bug: "handel.prefix"
[20:56] <scottatm> It quite litteraly dosn't do anything with the array.
[20:57] <PeterDietz> you can also remove the throws WingException
[20:57] <aschweer> tdonohue: yes, I'd wondered about a 1.8.1 for this
[20:57] <tdonohue> yea, I think this would be a good reason for a 1.8.1
[20:57] <aschweer> ok so I'll apply the patch to trunk and the 1.8 branch, and also look at the things mhwood and PeterDietz mentioned just now while I'm at it?
[20:57] <tdonohue> +1
[20:58] <mhwood> getRepositoryURL calls ConfigurationManager to get the prefix, while getAllManagedRepositories callse HandleManager.getPrefix() which is probably better.
[20:59] <aschweer> great, thanks everyone who had a look, and especially scottatm for your comments
[20:59] <tdonohue> I'll add a "1.8.1" version to JIRA shortly and schedule this for 1.8.1. I personally wouldn't want to wait for a year to get this big fix out
[21:00] <aschweer> tdonohue: thanks. yeah there's at least one discussion on dspace-tech where this patch would probably fix their problem
[21:01] * joseB (8dd32b9d@gateway/web/freenode/ip.141.211.43.157) has joined #duraspace
[21:01] <tdonohue> ok. we're now at time & we just finished up that discussion. So, we might as well close up the meeting now. I'll hang around though if anyone has anything else they really want to discuss
[21:01] * joseB (8dd32b9d@gateway/web/freenode/ip.141.211.43.157) Quit (Client Quit)
[21:03] <KevinVdV> I just wanted to quickly add a small comment, I noticed the other day that oracle released a java update for java 7 & now solr & lucene should be operational with java 7 (http://lucene.apache.org/solr/#26+October+2011+-+Java+7u1+fixes+index+corruption+and+crash+bugs+in+Apache+Lucene+Core+and+Apache+Solr) So I am willing to test & see if DSpace is compatible with java 7.
[21:03] <kompewter> [ Welcome to Solr ] - http://lucene.apache.org/solr/#26+October+2011+-+Java+7u1+fixes+index+corruption+and+crash+bugs+in+Apache+Lucene+Core+and+Apache+Solr)
[21:04] <tdonohue> KevinVdV - excellent. Yeah, that'd be good to test. If it is Java 7 compatible, we can change our docs. If there are small fixes required to be Java 7 compatible, we may be able to schedule those for 1.8.1 as well
[21:04] * elschlomo (8d421324@gateway/web/freenode/ip.141.66.19.36) Quit (Ping timeout: 265 seconds)
[21:05] <KevinVdV> I will look into it in the near future (will attempt to create a JIRA placeholder for this tomorrow)
[21:05] <tdonohue> +1 sounds good. thanks!
[21:07] <KevinVdV> Need to go now, cya all
[21:08] * KevinVdV (~KevinVdV@d54C14B50.access.telenet.be) Quit (Quit: KevinVdV)
[21:31] * hghghg (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[21:47] * hghghg (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Quit: Page closed)
[21:48] * aschweer (~schweer@schweer.its.waikato.ac.nz) has left #duraspace
[22:02] * mhwood (~mhwood@mhw.ulib.iupui.edu) has left #duraspace
[22:57] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Quit: stuartlewis)
[23:04] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[23:55] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.