Timestamps are in GMT/BST.
[0:47] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Remote host closed the connection)
[6:51] -moorcock.freenode.net- *** Looking up your hostname...
[6:51] -moorcock.freenode.net- *** Checking Ident
[6:51] -moorcock.freenode.net- *** Found your hostname
[6:51] -moorcock.freenode.net- *** No Ident response
[6:51] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:51] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:51] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[11:24] * fasseg (~fas@HSI-KBW-085-216-049-078.hsi.kabelbw.de) has joined #duraspace
[12:11] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:30] * scheglov (~guest@188.19.21.52) has joined #duraspace
[12:30] * scheglov (~guest@188.19.21.52) Quit (Excess Flood)
[12:57] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[12:59] * mastermisha (~mastermis@l37-192-29-11.novotelecom.ru) has joined #duraspace
[13:03] * mastermisha (~mastermis@l37-192-29-11.novotelecom.ru) Quit (Remote host closed the connection)
[13:13] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[18:17] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[19:42] * fasseg (~fas@HSI-KBW-085-216-049-078.hsi.kabelbw.de) Quit (Ping timeout: 260 seconds)
[19:59] * sveteca (~sveteca@37.45.236.249) has joined #duraspace
[20:00] <tdonohue> Hi all, it's now time for our weekly DSpace Developers Mtg. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-10-30
[20:00] <kompewter> [ DevMtg 2013-10-30 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-10-30
[20:01] <tdonohue> So, as has been the "hot topic", today is all about 4.0
[20:02] <tdonohue> Before we get into some of the tickets that are specifically mentioned in the Agenda, I wonder if we should first ensure we have a RC1 & Testathon plan in place (I.e. who is going to do what). I just want to be sure not to leave that till the very end
[20:03] <tdonohue> So, I'd like to open the floor to the 4.0 Release Team.. I'm not sure if there have been any plans made yet, or if we need to do that now?
[20:03] <hpottinger> erm, plan? :-)
[20:04] <mhwood> Good point. No formal plan yet. It's time to be stabilizing the tree temporarily for RC1 tomorrow. Bugs not yet tackled can be dealt with in RC2.
[20:05] <mhwood> Priority right now should be stabilizing what we have already put in, yes?
[20:05] <hpottinger> So, my calendar is free, I can pull the lever, but I think someone else might want to, since I did it last year.
[20:06] <hpottinger> I'm also planning on setting up a testathon instance based on Oracle
[20:06] <mhwood> Unless someone else wants to, I can tag it.
[20:06] <mhwood> Then start looking at how to deploy to demo....
[20:06] <tdonohue> Well, as I see it, the following needs to happen in the next few days (before Testathon): 1. Stabilize "master" (small bug fixes are OK as long as they don't destabilize), 2. Release RC1 (tomorrow or Fri), 3. Update demo.dspace.org with 4.0RC1
[20:07] <tdonohue> Preferably we get some *basic* 4.0 docs ready (esp. upgrade docs)...though it's not the end of the world if we are still working on those some next week.
[20:07] <hpottinger> and part of "update demo" is "update demo's HTML content to indicate it is now running 4.0 RC1"
[20:08] <tdonohue> yes, that's correct. We have some general notes on how to "update demo.dspace.org" at: https://wiki.duraspace.org/display/DSPACE/demo.dspace.org+Notes
[20:08] <kompewter> [ demo.dspace.org Notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/demo.dspace.org+Notes
[20:08] <mhwood> Ah, good!
[20:08] <tdonohue> (I'll link those notes to hpottinger's "4.0 tasks", for easy reference)
[20:09] <hpottinger> they're not just my tasks ;-)
[20:09] <tdonohue> oh, yea, right :)
[20:09] <mhwood> Oh, didn't we tell you?
[20:09] <hpottinger> oh, man
[20:09] <tdonohue> I meant, the page *you* created...not "all the stuff hpottinger is gonna do for us"
[20:10] <tdonohue> Ok, added a link to the demo notes to that wiki page under "Testathon Tasks" : https://wiki.duraspace.org/display/DSPACE/DSpace+4.0+Tasks
[20:10] <kompewter> [ DSpace 4.0 Tasks - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+4.0+Tasks
[20:10] * kstamatis_ (2ebe3eeb@gateway/web/freenode/ip.46.190.62.235) has joined #duraspace
[20:11] <tdonohue> The one other thing is that we need to be sure to remind everyone next week when Testathon officially begins (and send them links to RC1, etc)
[20:11] <mhwood> So, how is 4.0 feeling right now? Is there anything we really really need to address before tagging RC1?
[20:11] <mhwood> I was planning to send the reminder. These seem to go just to -tech, right?
[20:12] <tdonohue> mhwood: you can probably just respond-all to the announcement you sent and add a friendly reminder. I'd actually recommend "spamming" all major lists (-devel, -tech, -general) as we'll get different testers on each
[20:12] <mhwood> OK.
[20:12] * sveteca (~sveteca@37.45.236.249) Quit (Read error: Connection reset by peer)
[20:13] <tdonohue> I think 4.0 is looking very "feature-full" and exciting, personally. There are still quite a few outstanding bugs, but I'm hoping nothing gets too "in the way" of testathon... and outstanding bugs is the norm this early on
[20:14] <hpottinger> somewhat-related aside, I have Vagrant-DSpace working with hiera finally, so I *should* be able to write up a how to for running your own testathon instance in Vagrant-DSpace
[20:14] <tdonohue> The only ticket I kinda wish we would have resolved by now is DS-1709 (mentioned in today's agenda). It requires some UI rework to "fix" as it's rather confusing. There is a PR though, I just haven't been able to help aschweer review it.
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-1709 ] - [DS-1709] Advanced Embargo form does not work with non-anonymous group. Embargoed items are immediately publicly available! - DuraSpace JIRA
[20:15] <tdonohue> (Most of the other bugs I think we can fix before RC2 and be "ok")
[20:15] <mhwood> That does sound rather urgent.
[20:15] <mhwood> Noted.
[20:16] <tdonohue> with DS-1709, aschweer has a great idea to make it easier to understand (see the screenshot she attached). Essentially, it's not a "bug", it works right..but it's a huge usability issue (as it's an extremely confusingly laid out UI)
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-1709 ] - [DS-1709] Advanced Embargo form does not work with non-anonymous group. Embargoed items are immediately publicly available! - DuraSpace JIRA
[20:16] <tdonohue> and aschweer already did a PR for it (untested, XMLUI only so far) at https://github.com/DSpace/DSpace/pull/353
[20:16] <kompewter> [ [DS-1709] Access step UI by aschweer · Pull Request #353 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/353
[20:18] <tdonohue> 1709 is a big thorn in my side as I wish I could enable "advanced embargo", but its not at all clear how to use it (and even I had trouble until aschweer explained it better in the comments of 1709)
[20:19] <tdonohue> so, that's the only one I kinda wish could make RC1...but I'm so swamped under other tasks, I'm having trouble getting time to try out aschweer's UI redesign to see if it's ready to merge.
[20:20] <tdonohue> (if anyone wants to help, let me know...otherwise, I'll make some concerted effort to get this tried out tomorrow morning)
[20:21] <hpottinger> if someone could review/test 353, we could still merge before we pull the lever on RC1
[20:21] <mhwood> Me working in this area would probably slow things down rather than speed them. :-(
[20:22] <tdonohue> ok. well, I think "vagrant-dspace" is now working again (which has slowed me down, as that has been one of my primarily testing environments these days), so I can try and do a quick test to see where it stands before RC1
[20:22] <hpottinger> tdonohue: I have one more change to make to Vagrant-DSpace to fix the hiera stuff
[20:23] <tdonohue> hpottinger: as long as it "works well enough" I can pull in PR#353 and try it. My other dev environment is just a "mess" right now, so vagrant-dspace will be quicker for this sort of PR test
[20:24] * jrgriffiniii (~chatzilla@139.147.64.195) Quit (Ping timeout: 252 seconds)
[20:25] <tdonohue> So, do we sound "good" for RC1 & Testathon? It sounds like our one "gap" might still be some quick draft of Upgrade docs?
[20:26] <mhwood> I think so.
[20:26] <hpottinger> I think things look great for RC1
[20:27] <mhwood> Made a note about the doc.s.
[20:27] * jrgriffiniii (~chatzilla@139.147.64.195) has joined #duraspace
[20:29] <tdonohue> Regarding docs in general, I do wonder if RT needs to either put out a call (to -commit or -dev) for help in documenting new features, or if we need to start leaning more heavily on specific folks. Just don't want docs to wait till the very last minute (final release). It's perfectly fine to not have them all for RC1/Testathon...but we should start concentrating on docs in next few weeks
[20:29] <mhwood> I should start by making a list of what isn't yet documented, I guess.
[20:30] <tdonohue> yea, that's the other step. I'm not sure what all is missing, but I'm pretty sure there are several major features without much docs
[20:30] <tdonohue> (though others have some good starts, like the REST-API, courtesy of PeterDietz)
[20:32] <tdonohue> we really are a small crew today, huh. just three of us.
[20:33] * tdonohue wonders where all our committers are :)
[20:34] <tdonohue> OK, well, should we move along to some of the other topics on the agenda? We've covered RC1/Testathon, Docs stuff, Ds-1709. There's a few other notes here
[20:34] <kstamatis_> I am here too. and I just want to declare that BTE contribution + SubmissionLookup service are also documented :)
[20:34] <hpottinger> I was wondering the same thing at the start of the meeting...
[20:34] <mhwood> Thanks for the code and the documentation!
[20:34] <tdonohue> excellent, kstamatis_ Thanks. I didn't even know that. :)
[20:35] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[20:36] <kstamatis_> BTE docs: https://wiki.duraspace.org/pages/viewpage.action?pageId=34640934
[20:36] <kompewter> [ Importing Items via basic bibliographic formats (Endnote, BibTex, RIS, TSV, CSV) - DSpace 4.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/pages/viewpage.action?pageId=34640934
[20:36] <kstamatis_> SubmissionLookup: https://wiki.duraspace.org/display/DSDOC4x/Submission+User+Interface#SubmissionUserInterface-ConfiguringSubmissionLookupservice
[20:36] <kompewter> [ Submission User Interface - DSpace 4.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC4x/Submission+User+Interface#SubmissionUserInterface-ConfiguringSubmissionLookupservice
[20:36] <mhwood> Agenda items 1.a and 1.c are the same?
[20:36] <mhwood> No, I'm confused.
[20:37] <tdonohue> mhwood: no, agenda 1.a is something different, helix84 added it: https://github.com/DSpace/DSpace/pull/363
[20:37] <kompewter> [ DS-1409 with ItemCountDAOSolr being default, show strengths by default by helix84 · Pull Request #363 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/363
[20:37] <mhwood> That one looks simple enough. Do we want it?
[20:37] <tdonohue> Any objections to PR #363? Do we just merge it, or do we prefer the "strengths"/counts being "off" by default?
[20:37] <PeterDietz> hi all. sorry for the late start. I've deployed DSpace-REST (JERSEY) to our QA/Staging server, and might be deploying to production this week or next. So, I'm putting some weight behind that being "stable enough" for wide spread adoption
[20:38] <mhwood> Good, good.
[20:38] <kstamatis_> Hi PeterDietz, I had the chance to see the Rest API n action and I have some comments
[20:38] <PeterDietz> Since we can't run our production instance on DSpace 4.0, I've backported the commits to 1.8.x, and posted about it to the dspace-rest google group.
[20:39] <tdonohue> Regarding PR #363, I'm a bit unsure whether most folks would like these "strengths" by default or not. Do many of you enable them?
[20:39] <mhwood> I don't know much about this "strengths" stuff, so I can't object. :-/
[20:40] <hpottinger> we do, though I've been asked to take them off the top level communities
[20:40] <mhwood> scholarworks.iupui.edu has strengths turned off.
[20:41] <tdonohue> I never really turn them on, myself. I've had too many folks complain when it shows a low number (e.g. 0 or 5 or whatever)
[20:41] <mhwood> Disabled on all our production instances, it seems.
[20:41] <hpottinger> for communities with lots of cross-linked collections, the strength numbers are "unfair"
[20:41] <PeterDietz> kstamatis_: Can you jump over to #dspace and we can chat there, without interfering with the #duraspace meeting
[20:42] <tdonohue> so, that would imply that PR #363 probably should be rejected, unless a broader sample shows a real reason to enable by default
[20:42] <mhwood> I think it's too late for 4.0, not enough time to gather a consensus.
[20:43] <hpottinger> I'd prefer for strengths display to remain opt-in
[20:44] * bollini (~bollini@host4-65-dynamic.16-87-r.retail.telecomitalia.it) has joined #duraspace
[20:45] <tdonohue> ok, I'll add a comment to the ticket
[20:45] <tdonohue> err. the PR
[20:45] <tdonohue> Another issue to discuss (though it need not be decided before RC1, in my opinion): DS-1481
[20:45] <kompewter> [ https://jira.duraspace.org/browse/DS-1481 ] - [DS-1481] "dc.date.issued" is often incorrectly set (reported from Google) - DuraSpace JIRA
[20:46] <mhwood> bollini, we were discussing https://github.com/DSpace/DSpace/pull/363
[20:46] <kompewter> [ DS-1409 with ItemCountDAOSolr being default, show strengths by default by helix84 · Pull Request #363 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/363
[20:47] <tdonohue> I added a note to 363 from the discussion (so far)
[20:48] <hpottinger> to recap 1481: google says "hey, a bunch of DSpace IRs have a value of dc.date.issued that looks pretty crazy, based on what we can see by parsing the bitstreams, or looking "elsewhere"
[20:48] <mhwood> So we have two camps: "we mostly publish to DSpace" and "we mostly ingest stuff published elsewhere". Serve one, disserve the other.
[20:49] <mhwood> (And perhaps "publish? are we publishing?")
[20:49] <hpottinger> Richard Rodgers has a curation task written to help report on the extent of the issue in a repository, which can be run per collection or community, like any other curation task
[20:49] <tdonohue> yes, with 1481, Google Scholar folks have been sending me emails off & on around the incorrect "dc.date.issued" info they are seeing across DSpace sites. It is seemingly causing headaches on their end, as it makes DSpace content sometimes harder to locate in Google Scholar (at least by date)
[20:50] <tdonohue> part of 1481 is "helped" by disabling the Initial Questions (as it was masking the auto-assignment of dc.date.issued=today), which is already in 4.0
[20:50] <bollini> in our repository we have atmost all already published content. So we have solved that making dc.date.issued required and disabling the initial questions
[20:51] <tdonohue> As hpottinger mentions, Richard Rogers has started working on a curation task to report possible "suspect dates" in an existing repo (where dc.date.issued=dc.date.accessioned). Cannot recall if he has that code public?
[20:51] <mhwood> Maybe we can document that for 4.0 and address the issue more substantially later? Time is short.
[20:51] <bollini> only few special collection have not dc.date.issued or it is not required as we use these collections for grey materials that in some way is published the first time when its archived in dspace
[20:52] <mhwood> Yes, so either assumption can even be right in one part of a single repo. and wrong in another part.
[20:53] <tdonohue> The only thing we are "leaving out" here: What do we do about SWORD / bulk upload content? Currently, if a dc.date.issued is missing, one is assigned to "today". I suspect this may be the worst offender in terms of auto-assigning "dc.date.issued" to something wrong.
[20:54] <hpottinger> https://github.com/richardrodgers/ctask/blob/master/general/src/main/java/org/dspace/ctask/general/RoboIssueDate.java
[20:54] <kompewter> [ ctask/general/src/main/java/org/dspace/ctask/general/RoboIssueDate.java at master · richardrodgers/ctask · GitHub ] - https://github.com/richardrodgers/ctask/blob/master/general/src/main/java/org/dspace/ctask/general/RoboIssueDate.java
[20:54] <mhwood> Ideally this would be pushed down to the business logic, which would look at the collection to see what is expected.
[20:55] <mhwood> UIs should not be making such decisions. At most they should supply inputs to the decisions.
[20:56] <bollini> sword is mainly used by publisher to injest content in the repositories... they should know about dc.date.issued IMHO we should only add a big warning in the documentation saying that dc.date.issued is automatically set to the archive time if not else is providen
[20:56] <tdonohue> right, to be honest, it's not the UIs making the decisions..it's in the DSpace API. ItemInstall.java, IIRC
[20:56] <mhwood> OK, that's where it should be. It just needs more information.
[20:57] <mhwood> For now we can document the issue in the SWORD section, yes.
[20:57] <tdonohue> here's the "offending" code (which always assigns dc.date.issued, no matter the source, if it's missing): https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/InstallItem.java#L160
[20:58] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/content/InstallItem.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/InstallItem.java#L160
[20:58] <hpottinger> I wonder if the value could be set per collection or community policy?
[20:58] <mhwood> And that's arguably correct, if you think of DSpace as a publishing platform. It's arguably INcorrect if you have different notions.
[20:59] <hpottinger> it's a policy assumption we've made
[20:59] <mhwood> I think it should be per-collection, possibly defaulting from a community setting, yes. People in the wild tend to use the same DSpace both ways.
[20:59] <hpottinger> (and policy assumptions make some repository managers shoot laser beams out of their eyes)
[21:00] <mhwood> hpottinger points out the problem: policy belongs to the users, not the developers.
[21:01] <bollini> just to note that we have reach the time of the official meeting
[21:01] <tdonohue> I tend to lean towards this being an "incorrect" policy decision as we are making a big assumption and changing your disseminated metadata for you (and potentially affecting findability in Google Scholar), based on that assumption.
[21:01] <tdonohue> bollini: no, we are in the official mtg. It started an hour ago :)
[21:01] <bollini> what?!? ooh... summer time...
[21:02] <mhwood> Changing next week in the US....
[21:02] <tdonohue> but, I do understand there are two sides to the story behind 1481. I just lean towards: we should not be assuming a value for dc.date.issued
[21:02] <kstamatis_> bollini: i had the same problem. I came for Jira review and it was the official meeting
[21:02] <bollini> sorry, we have changed time last week...
[21:02] <hpottinger> yes, thanks for the heads up, DST ends this weekend, so, check your time reminder devices
[21:03] <tdonohue> yea, to be clear, the meeting time is ALWAYS 20:00UTC. So, when your local time changes, the meeting time is going to change for you.
[21:03] <tdonohue> (and yes, this means for USA, the meeting time is going to change next week)
[21:03] <mhwood> So tdonohue, then we should flop the behavior, document it prominently, and maybe revisit later with an actual policy control of some sort?
[21:03] <hpottinger> as well as "backlog hour"
[21:04] <mhwood> I have an xclock on my desktop set to UTC for things like this meeting.
[21:05] <bollini> ...fastly checking the IRC logs...
[21:05] <tdonohue> mhwood: yea, I tend towards flipping the behavior (as long as we can handle 'dc.date.issued=null' throughout the system, which I think we can). I like that we've removed Initial Questions, as it forces users from the UI to decide what 'dc.date.issued' really should be set to
[21:06] <tdonohue> But, I think we need to do the same for SWORD/bulk ingest...we should leave dc.date.issued unset, unless specified. We could add a special case where you could pass "dc.date.issued=today" in via bulk ingest, and just have that get "translated"
[21:06] <mhwood> Can someone build and test a patch?
[21:06] <mhwood> See, if it happens in ItemIngest then I don't understand why SWORD is a special case.
[21:07] <tdonohue> mhwood: it isn't really. Just clarifying that everything is affected. The change to skip Initial Questions just *requires* that dc.date.issued be manually set (so it never triggers the code in InstallItem anymore...but, SWORD & others still used that code in InstallItem)
[21:08] <mhwood> If we're going to be consistent then we need to disable that assumption in InstallItem.
[21:08] <tdonohue> I agree
[21:08] <hpottinger> mhwood++
[21:09] <tdonohue> So, I think it's just removing this "if()" https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/InstallItem.java#L162
[21:09] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/content/InstallItem.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/InstallItem.java#L162
[21:09] <mhwood> The Little Red Hen says: "who will build this patch?"
[21:10] <tdonohue> The only question I had was whether there's any purpose to letting something (like SWORD or bulk ingest) pass in "today" (literally that string) to *force* DSpace to autoassign a dc.date.issued=dc.date.accessioned
[21:10] <mhwood> That seems reasonable.
[21:10] <hpottinger> just change the test in the if
[21:10] <mhwood> You could even write "today" in the form.
[21:10] <tdonohue> potentially (though that's not supported in the UIs right now...but perhaps it would be via REST eventually)
[21:12] <tdonohue> Ok, so it sounds like...we are changing "if (currentDateIssued.length == 0)" INTO "if (currentDateIssued.equalsIgnoreCase("today"))" on this line: https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/InstallItem.java#L162
[21:12] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/content/InstallItem.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/InstallItem.java#L162
[21:12] <tdonohue> or, maybe not that exactly... currentDateIssued isn't a String, duh
[21:12] <tdonohue> but, that's the idea
[21:12] <mhwood> Sure.
[21:12] <hpottinger> hmm... if it isn't a string...
[21:13] <hpottinger> it won't hold a string
[21:13] <hpottinger> (says Mr. Obvious) :-)
[21:13] <mhwood> Well, there are two parts, and one can be done, the other may be doable.
[21:13] <tdonohue> yep, true, hpottinger. Also true, mhwood
[21:14] * hpottinger thinks tdonohue is close to submitting a PR for 1481
[21:14] <mhwood> We can remove the blanket assumption. I agree that this is better than what we have now even though it shifts the burden from one group of sites to the other.
[21:14] <tdonohue> OK, I'll look into doing this. It's a thorn for me, it seems like a one liner (or slightly more).
[21:14] <mhwood> Thank you.
[21:15] <tdonohue> If anyone has time to chip in on DS-1709 though, I'd still appreciate it. Trying to find time to do both of these before RC1 :)
[21:15] <kompewter> [ https://jira.duraspace.org/browse/DS-1709 ] - [DS-1709] Advanced Embargo form does not work with non-anonymous group. Embargoed items are immediately publicly available! - DuraSpace JIRA
[21:15] <hpottinger> If I can test Richard's curation task, I can add it to our stable of tasks. and I will pitch in with 1709 testing
[21:15] <tdonohue> Ok. We're "overtime" here anyhow.
[21:15] <mhwood> And I need to leave.
[21:16] <bollini> we will try to look to it tomorrow to see how to implement in JSPUI too
[21:16] <mhwood> Thank you. Thank you all.
[21:16] <tdonohue> bollini & hpottinger: thanks. I think 1709 is important
[21:16] <tdonohue> So, with that, I'm not gonna call any more agenda items
[21:16] <bollini> I have some PRs to hightlight
[21:16] <bollini> https://github.com/DSpace/DSpace/pull/360
[21:16] <kompewter> [ DS-1711 DS-1712 DS-1466 Implement consistent definition of Private items by abollini · Pull Request #360 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/360
[21:16] <bollini> imho this is ready to merge
[21:16] <tdonohue> But, I will stick around here if there's more things to highlight
[21:17] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:18] <tdonohue> bollini: I haven't had a chance to test PR#360, but the logic seems right to me. It's at least a ton better to ensure that we are no longer withdrawing "private" items
[21:18] <tdonohue> So, I'm all for merging #360 and testing more during Testathon. I think it looks right, just haven't had a chance to run it myself
[21:19] <bollini> ok
[21:19] <bollini> the other are related to solr
[21:19] <bollini> https://github.com/DSpace/DSpace/pull/368
[21:19] <kompewter> [ Revert autocommit configuration (as is in DSpace 3.x) by lap82 · Pull Request #368 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/368
[21:19] <bollini> https://github.com/DSpace/DSpace/pull/370
[21:19] <kompewter> [ Solr indexer improvement by lap82 · Pull Request #370 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/370
[21:20] <bollini> the first DSPR#368 is more low profile, just restore exactly the behaviour that we have in dspace 3.2
[21:20] <kompewter> [ https://github.com/DSpace/DSpace/pull/368 ] - Revert autocommit configuration (as is in DSpace 3.x) by lap82
[21:21] <hpottinger> so, I just reopened DS-1660, because the original PR didn't really "finish the job" I now have a branch that does, will make a new PR, I'm wondering if I will cause headaches for JIRA if I mention the issue number in another PR?
[21:21] <kompewter> [ https://jira.duraspace.org/browse/DS-1660 ] - [DS-1660] Utilize Hiera for configuration of Vagrant-DSpace - DuraSpace JIRA
[21:22] <tdonohue> hpottinger: no, mention the ticket in as many commits/PRs as you want. JIRA will link them up
[21:23] <hpottinger> yay!
[21:24] <tdonohue> bollini: I'll admit, I'm not a Solr expert these days. It seems like 368 is potentially "safer" to me, but I'm not sure I fully grasp all the advantages in 370
[21:24] <bollini> the second one is more interesting but, I'm looking to it now, need at least some rewording about the configuration option. With the second PR we can benefit of the NRT features available in SOLR 4 and have documents at most instantaneously indexed in SOLR
[21:25] <tdonohue> yea, I also noticed the configuration option in 370 mentions that "comment this line to not perform any commit". Do we really want to have the option to not commit changes to Solr?
[21:25] <tdonohue> https://github.com/DSpace/DSpace/pull/370/files#diff-835d88df2862c3e3d90a212f74177f00R17
[21:26] <kompewter> [ Solr indexer improvement by lap82 · Pull Request #370 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/370/files#diff-835d88df2862c3e3d90a212f74177f00R17
[21:27] <bollini> ok, probably it is a little messy (I haven't had a chance to review it before that the PR has been sent).
[21:27] <bollini> Actually and in dspace 3.2 the index consumer doesn't perform a commit
[21:28] <bollini> this mean that changes become visible only due to the autocommit configuration (in dspace 3.2 and #368) we have autocommit every 10sec
[21:29] <bollini> the pr#370 (or at least the idea behind) is to add a programmatic commit after any index consumer operation so to have change at most immediatly reflected on the search result
[21:30] <bollini> now, we can do that because in solr 4 we have NRT, and the option to perform softcommit that are much more performant than hard commit (the standard commit, the only commit that we can use in dspace 3.2)
[21:30] <tdonohue> I like that idea behind #370. It sounds better to me. Just want to be sure it's stable enough to add. Again, I think I'm not as familiar with Solr here, so I don't know what to recommend
[21:31] <bollini> ok
[21:31] <bollini> probably due to timeline we should go with the safer way
[21:31] <bollini> we restore previous behaviour as in #368
[21:31] <tdonohue> "safer" is better
[21:32] <bollini> and I will send an email suggestion to review (expecially to the @mire guys) the #370
[21:32] <tdonohue> you could always bring up #370 after RC1 to see if anyone really wants to add it in as a "bug fix" later.
[21:32] <bollini> it could be a big benefit in terms of performance and user experience
[21:32] <tdonohue> yea, that sounds good. I wish I knew more about Solr options these days
[21:33] <bollini> I will recommend you to take a look to this blog http://www.opensourceconnections.com/2013/04/25/understanding-solr-soft-commits-and-data-durability/
[21:33] <kompewter> [ Understanding Solr Soft Commits and Data Durability | OpenSource Connections | Solr, Big Data, and NoSQL consultants ] - http://www.opensourceconnections.com/2013/04/25/understanding-solr-soft-commits-and-data-durability/
[21:33] <bollini> I will refer to it also in my email
[21:33] <tdonohue> Thanks for the link
[21:34] <bollini> with solr 4 we have get in "durability" that is a very good thing... if tomcat crash we never loss data (nor statistics, nor pending search changes)
[21:34] <tdonohue> oh wow. yea, I'm skimming it right now.
[21:34] <tdonohue> That is a nice feature in Solr 4
[21:36] <tdonohue> It honestly sounds nice to me. But, it would be good to get others opinions (via email), as this would be a late Solr change to DSpace 4.0
[21:36] <bollini> it is the main reason that allow us to make tuning of the other configuration... as we have durability we don't need to hardcommit every 10sec we can wait more... and improve performance... and user experience using softcommit
[21:36] <bollini> yes, I agree. Better to have other eyes on that
[21:37] <bollini> thanks for the extra time... sorry again for the misunderstanding
[21:38] <tdonohue> no problem at all :)
[21:44] <hpottinger> so, tdonohue, give vagrant-dspace a spin now, and try setting up a local.yaml file in the config folder (just copy and modify common.yaml)
[21:44] <hpottinger> it's pretty sweet
[21:50] <hpottinger> tdonohue: I deleted my duplicate comment on DS-1481, as yours is more complete, we both made similar comments at about the same time
[21:50] <kompewter> [ https://jira.duraspace.org/browse/DS-1481 ] - [DS-1481] "dc.date.issued" is often incorrectly set (reported from Google) - DuraSpace JIRA
[21:51] <tdonohue> ok, cool
[21:51] <tdonohue> (in both cases)
[22:04] * kstamatis_ (2ebe3eeb@gateway/web/freenode/ip.46.190.62.235) Quit (Quit: Page closed)
[22:05] * bollini (~bollini@host4-65-dynamic.16-87-r.retail.telecomitalia.it) has left #duraspace
[22:06] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has left #duraspace
[22:14] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) Quit (Quit: Later, taterz!)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.