Timestamps are in GMT/BST.
[6:45] -sendak.freenode.net- *** Looking up your hostname...
[6:45] -sendak.freenode.net- *** Checking Ident
[6:45] -sendak.freenode.net- *** Found your hostname
[6:46] -sendak.freenode.net- *** No Ident response
[6:46] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:46] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:46] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:54] * Payam (~Nick@46.209.236.18) has joined #duraspace
[6:57] <Payam> Does DSpace allow its admin users to add new resource type(s)? (if yes, please provide screenshot(s))
[9:52] * Payam_ (~Nick@81.17.242.196) has joined #duraspace
[9:55] * Payam (~Nick@46.209.236.18) Quit (Ping timeout: 255 seconds)
[9:55] * Payam_ is now known as Payam
[9:56] * Payam_ (~Nick@46.209.236.18) has joined #duraspace
[9:59] * Payam__ (~Nick@91.214.44.36) has joined #duraspace
[10:00] * Payam (~Nick@81.17.242.196) Quit (Ping timeout: 260 seconds)
[10:00] * Payam__ is now known as Payam
[10:02] * Payam_ (~Nick@46.209.236.18) Quit (Ping timeout: 246 seconds)
[10:13] * Payam_ (~Nick@46.209.236.18) has joined #duraspace
[10:17] * Payam__ (~Nick@91.214.45.121) has joined #duraspace
[10:18] * Payam (~Nick@91.214.44.36) Quit (Ping timeout: 272 seconds)
[10:18] * Payam__ is now known as Payam
[10:19] * Payam__ (~Nick@46.209.236.18) has joined #duraspace
[10:21] * Payam_ (~Nick@46.209.236.18) Quit (Ping timeout: 276 seconds)
[10:23] * Payam (~Nick@91.214.45.121) Quit (Ping timeout: 245 seconds)
[10:23] * Payam__ is now known as Payam
[12:05] * Payam_ (~Nick@79.142.78.193) has joined #duraspace
[12:08] * Payam (~Nick@46.209.236.18) Quit (Ping timeout: 245 seconds)
[12:08] * Payam_ is now known as Payam
[12:14] * Payam_ (~Nick@46.209.236.18) has joined #duraspace
[12:17] * Payam (~Nick@79.142.78.193) Quit (Ping timeout: 246 seconds)
[12:18] * Payam_ is now known as Payam
[12:26] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:31] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has joined #duraspace
[13:06] * Payam (~Nick@46.209.236.18) Quit (Quit: Going offline, see ya! (www.adiirc.com))
[13:12] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[13:53] * towodo (~anonymous@30-16-206.dynamic.csail.mit.edu) has joined #duraspace
[13:57] * kohts (d4e97fba@gateway/web/freenode/ip.212.233.127.186) has joined #duraspace
[14:15] * hpottinger (~hpottinge@161.130.188.139) has joined #duraspace
[14:22] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Remote host closed the connection)
[14:33] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[15:00] <tdonohue> Hi all, welcome. It's time for our weekly DSpace Developers Meeting. Today's rough agenda is at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-09-10
[15:00] <kompewter> [ DevMtg 2014-09-10 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-09-10
[15:01] <tdonohue> As has been the recent "trend", today's meeting is obviously all about the upcoming 5.0 release
[15:02] <tdonohue> And we'll start off with the same general reminders: (1) The 5.0 Feature PR deadline is in <1 month (Oct 6)!! So, get your Feature PRs in as soon as you can!
[15:02] * robint_ (81d7ec36@gateway/web/freenode/ip.129.215.236.54) has joined #duraspace
[15:03] <tdonohue> (2) If you would like to contribute to 5.0 more directly, we could still use another Release Team member or two. No prior experience is necessary, and you don't even need to be a Committer.
[15:03] <tdonohue> Beyond that though...I didn't have anything else "general" to mention regarding 5.0 or the upcoming release schedule
[15:04] <tdonohue> Though, actually, I do wonder if we should have someone (peterdietz or hpottinger perhaps?) post a notice to our mailing lists about the 5.0 Release Schedule? Just to ensure everyone out there is in the loop and especially is aware of the first deadline?
[15:04] <tdonohue> Here's that 5.0 Release Schedule: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.0+Status#DSpaceRelease5.0Status-TimelineandProcessing
[15:04] <hpottinger> I'll do it
[15:04] <kompewter> [ DSpace Release 5.0 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.0+Status#DSpaceRelease5.0Status-TimelineandProcessing
[15:05] <hpottinger> I jsust sent a note to dspace-general hoping to drum up help testing Pull Requests
[15:05] <tdonohue> thanks hpottinger! I'd recommend posting a message to all major lists (dspace-general/tech/devel)
[15:06] <tdonohue> Anyone else have general notes or questions regarding 5.0? (We'll move on to reviewing 5.0 PRs in a second, so wait on that)
[15:06] <hpottinger> unless our RC wants to send the note, I'll ask him
[15:07] <tdonohue> hpottinger: feel free to work it out between you and peterdietz. Whoever wants to do it is fine by me. Just figured we should get that info out more publicly for those who may not be tracking these meetings, etc
[15:08] * peterdietz (~peterdiet@server112.longsightgroup.com) has joined #duraspace
[15:08] <tdonohue> Ok, not hearing any other general notes/questions. We'll move along to 5.0 Feature PRs
[15:09] <tdonohue> From last week, there were three 5.0 Feature PRs which were recommended to be discussed today, so we'll start with those (and we may have time for others at the end)
[15:09] <tdonohue> First up, DS-1990 / DSPR#537 from pbecker
[15:09] <kompewter> [ https://jira.duraspace.org/browse/DS-1990 ] - [DS-1990] Missing a way to handle identifiers like DOIs in case of a deletion event - DuraSpace JIRA
[15:09] <kompewter> [ https://github.com/DSpace/DSpace/pull/537 ] - DS-1990: Events should contain all identifiers, not only handles. by pnbecker
[15:09] <pbecker> Two of them are comming from me and are related to each other: DS-1990 and DS-2061.
[15:09] <kompewter> [ https://jira.duraspace.org/browse/DS-1990 ] - [DS-1990] Missing a way to handle identifiers like DOIs in case of a deletion event - DuraSpace JIRA
[15:09] <kompewter> [ https://jira.duraspace.org/browse/DS-2061 ] - [DS-2061] Linked (Open) Data support for DSpace - DuraSpace JIRA
[15:10] <pbecker> DS1990 is a PR to be able to use all Identifiers in Deletion events not only handles.
[15:10] <pbecker> I need this for DS2061 we will be taking next.
[15:10] <pbecker> s/taking/talking about/
[15:10] <kompewter> pbecker meant to say: I need this for DS2061 we will be talking about next.
[15:10] <pbecker> mhwood was so kind to review DS1990 last week.
[15:12] <pbecker> I just wanted to talk about it today, to here if I should wait for one or two more reviews or if you think that it is ready to be merged.
[15:13] <pbecker> As soon as it is merged I could rebase the PR for DS-2061, make my last commit and it would be ready to go into review.
[15:13] <kompewter> [ https://jira.duraspace.org/browse/DS-2061 ] - [DS-2061] Linked (Open) Data support for DSpace - DuraSpace JIRA
[15:13] <pbecker> and of course I ment hear and not here.... (ups)
[15:13] <tdonohue> pbecker: just giving the code in PR #537 a skim right now... I like that you are now caching identifiers in DSpaceObject rather than re-querying on every event.
[15:13] * peterdietz (~peterdiet@server112.longsightgroup.com) Quit (Quit: peterdietz)
[15:14] * caravan (~caravan@Siriom-Laptop.lnec.pt) has joined #duraspace
[15:14] <pbecker> tdonohue: thanks. Just had to thought about the right point to reset the cache.
[15:14] * peterdietz (~peterdiet@server112.longsightgroup.com) has joined #duraspace
[15:15] <tdonohue> And, I'm noticing this only really changes Event versus UsageEvent. I'm assuming that is just that UsageEvents don't matter as much to your other code?
[15:16] <mhwood> Changes to the model are not usage.
[15:16] <tdonohue> true, good point
[15:17] * KevinVdV (~KevinVdV@d5153D041.access.telenet.be) has joined #duraspace
[15:17] <peterdietz> usage = statistics (i.e. downloads), I think there are also some things like searches and workflow actions too...
[15:17] <pbecker> The PR is to catch a special problem that only occures with deletion events.
[15:17] * kdweeks (~Adium@2001:468:c80:a103:a164:ec43:83a:6468) has joined #duraspace
[15:17] <tdonohue> and, now that I look. UsageEvent just extends Event. So, making identifiers available in Event also bubbles them up to UsageEvent should Usage Stats want the Identifiers as well: https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/usage/UsageEvent.java#L22
[15:18] <kompewter> [ DSpace/UsageEvent.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/usage/UsageEvent.java#L22
[15:18] <pbecker> The problem with events in case of deletion is that the objects will be removed when the event is thrown.
[15:18] <mhwood> The issue: deletion was destroying information which Event listeners needed, and then calling the listeners.
[15:18] <pbecker> For all other events it is possible to use the resource type and id to get the identifiers.
[15:18] <pbecker> In case of deletion this is not possible.
[15:18] <peterdietz> I don't imagine our events its so sophisticated to have a pre-event listener?
[15:19] <pbecker> peterdietz: no, its quite simple. ;-)
[15:19] <tdonohue> So, PR #537 looks/sounds reasonable to me. I haven't tested it, but it seems fine, unless anyone else has objections
[15:20] <mhwood> Then we would have the converse problem here: a listener might succeed in removing information before we find out that the object cannot be destroyed.
[15:20] <mhwood> I would have pulled it already, but wanted to know if tdonohue's concerns were fully addressed.
[15:21] <hpottinger> the button is green, which means it builds and tests pass...
[15:22] <tdonohue> One tiny thing I just noticed. It looks like ONLY DOIIdentifierProvider calls "dso.resetIdentifierCache();". Shouldn't that also be called by HandleIdentifierProvider (if handles are updated) and EZIDIdentifierProvider?
[15:22] <tdonohue> It seems slightly odd that only when DOIs are updated does the cache get reset...but, maybe I'm missing something
[15:23] <pbecker> Perhaps just one last thing about it: Currently we double the handle. It is part of the detail and of the identifier array. I woudln't change it for compatability reasons, but wanted to note it here.
[15:23] <pbecker> The IdentifierServiceImpl resets the cache.
[15:23] <pbecker> In case of the DOIIdentifierProvider this is not sufficent as it uses asynchronous registration.
[15:23] <pbecker> This is not necessary for the EZIDIdentifierProvider.
[15:23] <tdonohue> Oh, thanks for clarifying pbecker. I see it now. Nevermind :)
[15:24] <tdonohue> I think this PR looks fine to me then
[15:24] <pbecker> I even added a javadoc to the IdentifierProvider interface about resetIdentifiers.
[15:25] <pbecker> that sounds great. :-) So I'll merge it later today or tomorrow?
[15:25] <mhwood> Yes, please.
[15:25] <robint_> +1
[15:25] <tdonohue> +1 yep, sounds good
[15:25] <pbecker> (-:
[15:26] <tdonohue> so, moving only to the other pbecker ticket: DS-2061 / DSPR#568
[15:26] <kompewter> [ https://github.com/DSpace/DSpace/pull/568 ] - DS-2061: Linked (Open) Data support for DSpace by pnbecker
[15:26] <kompewter> [ https://jira.duraspace.org/browse/DS-2061 ] - [DS-2061] Linked (Open) Data support for DSpace - DuraSpace JIRA
[15:26] <pbecker> We talked about this once here in the meeting.
[15:26] <pbecker> At the end of the week it is ready for a code review.
[15:27] <pbecker> The only missing thing will be an extended default configuration, but the code will be finished.
[15:27] <tdonohue> pbecker: OK, so it's not quite ready yet? Have you chatted any further with mdiggory from @mire, since I know he was very interested in this, and @mire has done similar stuff before?
[15:27] <pbecker> As soon as the code is done I'll mail mdiggory.
[15:27] <tdonohue> OK, sounds good. Should we wait to review 2061 until next week then?
[15:28] <pbecker> tdonohue: we chatted a little bit beside of the last meeting we were talking about this feature.
[15:28] <pbecker> I wanted to ask how a code review could be done as it is not a small pr.
[15:28] * ianthe (~ianthe@cowu.be) has joined #duraspace
[15:28] <pbecker> the diff in my thesis (were the code come froms) was about 7.000 lines.
[15:29] <tdonohue> pbecker: As it is such a big PR, it's probably good to find at least a few Committers who would be willing to pull down the PR and actually test it on their machine. If mdiggory is willing, I'd love his feedback here, as he is very knowledgable in this area.
[15:29] <pbecker> But it is mostly new code added to a new module named dspace-rdf. I does not touch any code in dspace-api.
[15:29] <pbecker> tdonohue: sounds reasonable.
[15:30] <pbecker> So I'll finish the last things, request the code review in the jira an will mail to dspace-devel and mdiggory.
[15:30] <pbecker> should be done by end of this week. :-)
[15:31] <pbecker> that was all from me about these two PRs. But if anyone else has questions... I could even avoid some time after the meeting.
[15:31] <tdonohue> We'd also want some basic documentation on *how* to work with this new 'dspace-rdf' project. Do we have that up somewhere? As it could help folks who are trying to do a code review to get started
[15:31] <pbecker> https://wiki.duraspace.org/display/~pbecker/Bringing+DSpace+into+the+Semantic+Web
[15:31] <kompewter> [ Bringing DSpace into the Semantic Web - Pascal-Nicolas Becker - DuraSpace Wiki ] - https://wiki.duraspace.org/display/~pbecker/Bringing+DSpace+into+the+Semantic+Web
[15:31] <pbecker> already prepared. ;-)
[15:31] <robint_> Did Kostas and the Greek gang not do a presentation on DSpace and RDF a while back?
[15:31] <tdonohue> Oh, OK. wanted to make sure. Thanks, pbecker
[15:32] <robint_> As did a Finnish guy who was very keen on Linked Data
[15:32] <robint_> Definitely worth making some noise on the mailing lists to see if there are any willing testers
[15:33] <tdonohue> robint_: you might be right. Trying to recall myself. I agree though that i'd be nice to email others directly who we *know* have interest in RDF with DSpace. They'd make great reviewers/testers
[15:33] <mhwood> Were those at OR 2014? You may be able to glean contact information from the conference site.
[15:33] <robint_> It was at OR in Austin I think
[15:34] <robint_> I'll look back at the OR programmes
[15:34] <pbecker> I know from mdiggory and Thomas Johnson. But I think someone was pointing me on Thomas Johnson in regards for a Digital Repsotories Ontology I was thinking of and not specially for DSpace and LD.
[15:35] <pbecker> In all case I write a mail to dspace-devel. So perhaps this even helps to find more testers?
[15:35] <tdonohue> Yes, I definitely agree we should make "noise" on the mailing lists about this. I do recall others working with DSpace + RDF in the past, but I'm blanking on the names
[15:36] <tdonohue> pbecker: you may also want to email dspace-general...not sure if *all* these folks are on dspace-devel. Even though technically it is a developer discussion, we probably want a broad reach here :)
[15:37] <tdonohue> I'd *hope* that most of the folks we'd mention are on dspace-devel...but I think broadly advertising this work might be an even better way of finding testers
[15:37] <pbecker> tdonohue: okay, I'll make a cross post. ;-)
[15:37] <tdonohue> sounds great!
[15:37] <tdonohue> and thanks pbecker for sharing all your hard work!
[15:38] <pbecker> It's a pleasure for me. Would be great to see this working on many repositories not only here in Berlin!
[15:38] <hpottinger> +1 all three lists, especially with big feature PRs
[15:39] <hpottinger> we need more testers, MORE TESTERS I say! :-)
[15:39] <tdonohue> So, since it sounds like we are wrapping up with this ticket.... we'll move along now to the last one on my list for today (but it's a big one!): DS-1582 / DSPR#629
[15:39] <kompewter> [ https://github.com/DSpace/DSpace/pull/629 ] - Support Metadata On All DSpaceObjects by KevinVdV
[15:39] <kompewter> [ https://jira.duraspace.org/browse/DS-1582 ] - [DS-1582] All DSpaceObjects should have metadata support - DuraSpace JIRA
[15:39] <tdonohue> From KevinVdV, obviously
[15:40] <robint_> Got to run unfortunately, cheers all.
[15:40] <tdonohue> I know we had discussed this briefly last week. Has anyone had a chance to give it a test run?
[15:40] <mhwood> Sorry to say I have not.
[15:40] <tdonohue> I haven't had the chance yet either...but I'm hoping to get to it later this week.
[15:41] <tdonohue> We may ALSO wish to ask for additional testers on mailing lists for this feature too, since it's such a big and likely popular one.
[15:41] * robint_ (81d7ec36@gateway/web/freenode/ip.129.215.236.54) Quit (Quit: Page closed)
[15:41] <pbecker> I was focused on my PR. But I wanted to prepare dspace-rdf to make advantage of DS-1582 soon.
[15:42] <kompewter> [ https://jira.duraspace.org/browse/DS-1582 ] - [DS-1582] All DSpaceObjects should have metadata support - DuraSpace JIRA
[15:42] <KevinVdV> & we @ at @mire are also working on a feature that makes use of the metadata for all support.
[15:43] <tdonohue> KevinVdV -- can you share any more info about that "in progress" feature?
[15:43] <KevinVdV> Well it is about author profiles
[15:43] <KevinVdV> Contributed by the world bank: https://openknowledge.worldbank.org/author-page?author=Abras%2C+Ana+Luisa
[15:43] <kompewter> [ OKR: Abras, Ana ] - https://openknowledge.worldbank.org/author-page?author=Abras%2C+Ana+Luisa
[15:43] <KevinVdV> This is an example of such an author profile
[15:44] <hpottinger> OK, so, I'm going to send a note out about the 5.0 Release schedule, I can also incorporate a "call to testers" in that note, and mention specific PRs
[15:44] <tdonohue> The main reason I asked is that sometimes it's even easier to find testers if there's a "flashy feature" which depends on a backend feature (and 1582 is more "backend", which prepares for "flashy features" to come)
[15:44] <pbecker> hpottinger +1
[15:44] <tdonohue> hpottinger +1
[15:44] <mhwood> Very nice new feature.
[15:44] <KevinVdV> I would call it a “very flashy feature"
[15:45] <tdonohue> +1 KevinVdV. That'd be a very nice new feature...which I would definitely consider "flashy" :)
[15:45] <KevinVdV> But still in the process of porting the code
[15:45] <tdonohue> Any timeline on porting of that code yet? Or is it still pretty early?
[15:46] <hpottinger> need any help? :-)
[15:46] <KevinVdV> I’m afraid it is a bit early, by the end of next week I hope to have something
[15:46] <peterdietz> KevinVdV / @mire +1, that's really cool. I wonder if it conflicts with DSPACE-CRIS at all
[15:46] <tdonohue> sounds good, KevinVdV
[15:46] <KevinVdV> The help will mostly be the testing of everything
[15:47] <KevinVdV> It will be an XMLUI only feature & I believe the DSpace-CRIS is a JSPUI feature ?
[15:47] <hpottinger> OK, Oct. 6 is the PR deadline :-)
[15:48] <tdonohue> Yes, DSpace-CRIS is JSPUI only...it's almost a "fork" of DSpace itself, as it's not possible (Yet at least) to install dspace-CRIS on an existing DSpace.
[15:48] <pbecker> KevinVdV: do you thing it will take a lot of time to port it to the JSPUI? Is it related to your great ORCID contribution?
[15:48] <tdonohue> But, I do agree that DSpace-CRIS and these "Author Profiles" sound somewhat similar in nature.
[15:48] <KevinVdV> & the “author profiles” feature uses 2 custom datatables & metadata for all
[15:49] <KevinVdV> But more information will follow once I get everything ported
[15:50] <hpottinger> KevinVdV, would you consider porting docs first? Similar to how the ORCID work came in?
[15:50] <hpottinger> it's helpful to have a placard to point people to
[15:50] <tdonohue> KevinVdV, sounds good. I suspect there will be a lot of interest here. It also would be good to get a sense of what it might take to port it to JSPUI, as hopefully we'd have some folks who could try to do so quickly before 5.0
[15:51] <KevinVdV> I’ll also try to get some docs up soon.
[15:51] <tdonohue> hpottinger +1 I agree, the earlier we can "get the word out" the better, especially if we want testers and others to possibly help port to JSPUI
[15:51] <KevinVdV> But afraid I need to go now (more information on this feature will follow soon ;))
[15:51] <tdonohue> Thanks KevinVdV!
[15:51] <KevinVdV> Until next week !
[15:52] * KevinVdV (~KevinVdV@d5153D041.access.telenet.be) Quit (Quit: KevinVdV)
[15:52] <tdonohue> Back to DS-1582 (Metadata for All). I'll try and pull it down for a quick test myself before next week's meeting. I'd appreciate it if others could do the same... I don't think there is much of a UI on it yet, but mostly just want to make sure that nothing "breaks" and that migration of existing data seems to work fine
[15:52] <kompewter> [ https://jira.duraspace.org/browse/DS-1582 ] - [DS-1582] All DSpaceObjects should have metadata support - DuraSpace JIRA
[15:54] <hpottinger> a smaller, internal "bug fix" that probably ought to just be merged is DS-2125/DSPR#626, if anyone is in the testing mood
[15:54] <kompewter> [ https://jira.duraspace.org/browse/DS-2125 ] - [DS-2125] NPE if Context.abort() or Context.complete() called twice - DuraSpace JIRA
[15:54] <kompewter> [ https://github.com/DSpace/DSpace/pull/626 ] - DS-2125 Fix possible NPEs in Context object commit/complete/abort by tdonohue
[15:54] <tdonohue> Any other topics folks have to bring up regarding 5.0?
[15:55] <tdonohue> Oh, yes..PLEASE if folks will review PR #626, I'd appreciate it. I'm waiting on a few +1's just cause this is such a central area of the code. But, I did write new Unit Tests for the Context object, and all of them succeed.
[15:55] <hpottinger> you have my +1
[15:56] <tdonohue> And it looks like I already got one +1 from hpottinger. Thanks!
[15:57] <mhwood> There is not a lot of change to review -- the bulk of it is the tests (also worthy of study).
[15:57] <tdonohue> yep, the bulk is new unit tests
[15:58] <tdonohue> The actual code changes themselves were just to avoid NPEs being thrown in the Context object...and I wrote some Unit Tests which initially caused those NPEs to be thrown, but now succeed. I also went ahead and wrote some general Unit Tests, just cause the Context object had none
[16:00] <pbecker> Perhaps one other thing: DS-2127 is necessary to keep the DOI code working.
[16:00] <kompewter> [ https://jira.duraspace.org/browse/DS-2127 ] - [DS-2127] Upgrade commons-codec to version 1.9 - DuraSpace JIRA
[16:00] <pbecker> It's a really simple PR.
[16:00] <pbecker> DSPR#627.
[16:00] <kompewter> [ https://github.com/DSpace/DSpace/pull/627 ] - DS-2127: Upgrade commons-codec to version 1.9. by pnbecker
[16:00] <tdonohue> pbecker: what is it waiting on then? it is a very simple PR
[16:00] <pbecker> It may still have high impact... ;-)
[16:01] <pbecker> tdonohue: so I just click the merge button?
[16:01] <hpottinger> in this case, I think merge then test is fine, but, you know, I often think that :-)
[16:01] * pbecker always against asking himself when to just merge an when to wait for a review.
[16:02] <pbecker> hpottinger: sounds good in this case.
[16:02] <mhwood> Yes, I think we should have this early.
[16:02] <tdonohue> pbecker: feel free to ask. In this case, it seems reasonable to merge this. I don't think anything is going to massively break from a version upgrade. And we will have plenty of time to clean up minor breakages should they appear
[16:03] * kohts (d4e97fba@gateway/web/freenode/ip.212.233.127.186) Quit ()
[16:03] <pbecker> fine. :-)
[16:03] <hpottinger> sounds like +3 a least...
[16:03] <hpottinger> at least, that is
[16:03] <pbecker> merged.
[16:03] <mhwood> Thanks!
[16:05] <tdonohue> We're now into "overtime". I didn't have anything else to discuss today though. I would appreciate more reviews on my PR# 627, as it *really is* a bug we should fix, and I personally don't see anything controversial here. Beyond that though, I don't have any further updates/notes for today.
[16:05] <hpottinger> now, how do we convince tdonohue to do the same with DSPR#626?
[16:05] <kompewter> [ https://github.com/DSpace/DSpace/pull/626 ] - DS-2125 Fix possible NPEs in Context object commit/complete/abort by tdonohue
[16:05] <tdonohue> err...I meant #626
[16:06] <tdonohue> hpottinger: I made it clear in that PR...just waiting for one more +1. Normally, I would have just merged PR#626, but since it generated a lot of discussion, and there was a request for more logging (which I provided in the latest commit), I'm waiting for two +1's
[16:06] <mhwood> Reviewing now.
[16:07] <hpottinger> I'm just needling you, tdonohue, don't pay any attention to me, I'm crazy
[16:07] <tdonohue> haha :)
[16:08] <tdonohue> OK, in any case, as we are now past 1 hour, I'm going to close up the meeting for today. No more official topics. I will be around for a while though, so if anything unofficial comes up, feel free to ping me
[16:08] <tdonohue> Oh, and if anyone has additional PRs they'd like to see discussed next week, again, you are welcome to forward them my way, or just add them to next week's agenda.
[16:10] <mhwood> You have your second +1.
[16:11] <tdonohue> Thanks mhwood! I'll go ahead and merge that PR then, and close the ticket
[16:13] <pbecker> merged DSPR#537 as well.
[16:13] <kompewter> [ https://github.com/DSpace/DSpace/pull/537 ] - DS-1990: Events should contain all identifiers, not only handles. by pnbecker
[16:14] <mhwood> Continuing an earlier discussion: I see that https://wiki.duraspace.org/display/DSDOC5x/Authority+Control+of+Metadata+Values is Work In Progress. "How it Works: TODO" That might help to explain difficulty in using it. I wish I knew enough to flesh it out.
[16:14] <kompewter> [ Authority Control of Metadata Values - DSpace 5.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC5x/Authority+Control+of+Metadata+Values
[16:21] <caravan> there is no proper documentation on it , if i get mine working ill send you a "how to" or something
[16:21] <hpottinger> so, also on my list to do today is to create a JIRA issue for improving the upgrade documentation to include a suggestion to delete the old browse indexes when upgrading to 4x or higher, and enabling Discovery... I'm wondering if we'd actually consider adding a script to do the deletion? Dare we ship a script that deletes metadata?
[16:22] <tdonohue> hpottinger: that script wouldn't delete *metadata*. It'd just delete an index (which happens to be in a database table). So, yea, we probably should have such a script
[16:24] <pbecker> hpottinger: the index should be recreatable. Perhaps it is not with DSpace (don't know if the old core is still in place) but in theory. What I want to say: no data will be lost be deleting the old index....
[16:24] <hpottinger> oh, yes, sorry, I have an autopilot in my brain, whenever I find myself typing "data" I change it to "metadata"... but you're right, tdonohue, this is just an index
[16:24] <tdonohue> yep, and pbecker is correct. that index (in the database) is recreatable
[16:25] <hpottinger> I'm thinking it ought to be an addditional upgrade script, you'd have to opt-in to the deletion
[16:34] <mhwood> If it's an actual script, we'll need two: shell and CMD.
[16:35] <hpottinger> it'll be SQL, like all the other "upgrade scripts" :-)
[16:35] <mhwood> Ah.
[16:36] <hpottinger> I'll name it clever like "warning-desctructive-will-delete-indexes.sql"
[16:36] <pbecker> hpottinger: don't you think this is a little bit to much warning?
[16:36] <mhwood> "Interesting, let's see what this does."
[16:37] <tdonohue> just put it in the normal "upgrade" script :) It can go in the 3.x->4.x SQL upgrade
[16:37] <pbecker> it's like "I'm a red button. Hit me! Hit me!"
[16:37] <pbecker> tdonohue +1
[16:37] <tdonohue> If they want to *disable* Discovery, then we should just include the instructions to recreate those build indexes (which happens just by running index-db script)
[16:37] <mhwood> Doesn't it have to be optional, until we pull out the old code?
[16:38] <tdonohue> No. Discovery was not "optional" in 4.x. It was enabled by default
[16:38] <hpottinger> this strikes me as quite funny, and I might just have to name it this way, mhwood is right, it needs to be opt-in, unless we are saying "no browse index, ever, for you"
[16:38] <mhwood> What if someone disables it?
[16:39] <hpottinger> well... I suppose I could leave the tables around...
[16:39] <hpottinger> and just empty them
[16:39] <pbecker> If the old code is still in place, it won't be a problem to recreate the index. IIRC we say in the update documenation to recreate search indexes...
[16:39] <tdonohue> Upon upgrading to 4.x...Discovery will be enabled by default. AFTER upgrading to 4.x, you can *choose* to disable Discovery again, in which case you simply run "index-db" to recreate those index tables
[16:39] <pbecker> so we are talking about two tasks
[16:40] <mhwood> Yes, but it's a pretty nasty surprise to have your indexes emptied by an upgrade, if you are not going to use Discovery.
[16:40] <pbecker> deletion of the data inside the tables and dropping of the tables...
[16:40] <tdonohue> why is it "nasty" to empty your indexes. You are told you need to re-index everytime you upgrade anyways
[16:40] <mhwood> Point.
[16:41] <tdonohue> The act of re-indexing actually *removes* those old Index tables already....so you'd be removing & reindexing anyhow
[16:41] <hpottinger> in my attempts to delete a community's worth of content, I just dropped the un-needed tables, but a "nicer" approach would be to empty the tables
[16:41] <tdonohue> IMHO, our upgrade to 4.x SQL script should just automatically delete those index tables. You can easily recreate them by disabling Discovery and running 'index-db'
[16:42] <hpottinger> the tables in question are nameed BI_*, there is also COMMUNITIES2ITEM which hangs around, it's not needed by Discovery so I dropped it
[16:43] <tdonohue> The "BI_*" tables are automanaged/created by that "index-db" script. But, hmmmm...not sure about "Communities2Item"
[16:45] <hpottinger> having trouble picking an "affects versions" for this new ticket, it does affect 4x, but I'm not sure I want to own up to it
[16:45] <tdonohue> it affects 4.x, likely also 3.x (as you could enable Discovery there as well)
[16:46] <tdonohue> although, not sure if it effects 3.x actually... I don't recall if Discovery did Browse indexes back then
[16:49] <hpottinger> dropping all the 3x versions from "affects versions" for this bug, then, no sense needlessly worrying folks
[16:53] * hpottinger (~hpottinge@161.130.188.139) Quit (Ping timeout: 264 seconds)
[16:55] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has joined #duraspace
[16:56] <hpottinger> darn plug fell out of the notebook
[16:56] <hpottinger> so, there are a couple of related bugs: DS-1619, and DS-1920
[16:56] <kompewter> [ https://jira.duraspace.org/browse/DS-1619 ] - [DS-1619] Unable to remove items after enabling SOLRBrowseDAOs - DuraSpace JIRA
[16:56] <kompewter> [ https://jira.duraspace.org/browse/DS-1920 ] - [DS-1920] Deleting an item fails because of old browse tables - DuraSpace JIRA
[16:58] <hpottinger> I'm still making this issue, though, as it specifically calls out the problem and outlines a solution
[16:58] <hpottinger> Or, is the "right thing to do" to use an older issue?
[16:59] <tdonohue> hpottinger: you were right, this should be a separate ticket, as it calls out the issue better. Just link up that new ticket with all those old, related ones
[16:59] <tdonohue> and once it is "fixed", hopefully we can close most if not all of those old ones as well
[17:00] <hpottinger> DS-2145
[17:00] <kompewter> [ https://jira.duraspace.org/browse/DS-2145 ] - [DS-2145] old browse index tables should be removed if you enable Discovery - DuraSpace JIRA
[17:06] * pbecker has to leave
[17:06] <pbecker> thanks for helping me with the two PRs, glad that they are merged.
[17:07] <caravan> thanks for the assist as well , cya tomorow ?
[17:07] <pbecker> enjoy you evening (or day)!
[17:07] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[17:07] * peterdietz (~peterdiet@server112.longsightgroup.com) Quit (Quit: peterdietz)
[17:10] <hpottinger> http://wiki.lib.sun.ac.za/index.php/SUNScholar/Browse_Indexes/3.2#WARNING
[17:10] <kompewter> [ SUNScholar/Browse Indexes/3.X - Libopedia ] - http://wiki.lib.sun.ac.za/index.php/SUNScholar/Browse_Indexes/3.2#WARNING
[17:10] <hpottinger> "known issues" make me grumbly
[17:20] * caravan (~caravan@Siriom-Laptop.lnec.pt) Quit (Ping timeout: 268 seconds)
[18:05] * towodo (~anonymous@30-16-206.dynamic.csail.mit.edu) Quit (Ping timeout: 276 seconds)
[18:45] * pa__ (05ef2c78@gateway/web/freenode/ip.5.239.44.120) has joined #duraspace
[18:48] <pa__> Does DSpace allow its admin users to add new resource type(s)? (if yes, please provide screenshot(s))
[19:07] * pa__ (05ef2c78@gateway/web/freenode/ip.5.239.44.120) Quit (Ping timeout: 246 seconds)
[19:58] * mdiggory (~anonymous@cpe-76-176-128-229.san.res.rr.com) has joined #duraspace
[20:01] * peterdietz (~peterdiet@server112.longsightgroup.com) has joined #duraspace
[20:01] * mdiggory (~anonymous@cpe-76-176-128-229.san.res.rr.com) Quit (Client Quit)
[20:48] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has left #duraspace
[20:55] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[22:18] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has left #duraspace
[22:36] * peterdietz (~peterdiet@server112.longsightgroup.com) Quit (Quit: peterdietz)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.