Timestamps are in GMT/BST.
[6:30] -hubbard.freenode.net- *** Looking up your hostname...
[6:30] -hubbard.freenode.net- *** Checking Ident
[6:30] -hubbard.freenode.net- *** Found your hostname
[6:30] -hubbard.freenode.net- *** No Ident response
[6:30] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:30] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:30] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[13:53] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has joined #duraspace
[16:47] * helix84 (~ctenar@195.178.95.132) Quit (Read error: Operation timed out)
[16:47] * helix84 (~ctenar@195.178.95.132) has joined #duraspace
[19:12] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[19:34] * kshepherd2 (~kim@wireless-nat-1.auckland.ac.nz) has joined #duraspace
[19:56] * kshepherd2 (~kim@wireless-nat-1.auckland.ac.nz) Quit (Ping timeout: 252 seconds)
[20:00] <tdonohue> Hi all, it's time for our weekly DSpace Developers Meeting: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-02-19
[20:01] <kompewter> [ DevMtg 2014-02-19 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-02-19
[20:01] <hpottinger> roll call?
[20:02] <tdonohue> yes, looks like we might want to do so, hpottinger. Wondering if it's just the two of us, or if anyone else is attending today
[20:02] * hpottinger high fives tdonohue!
[20:03] <tdonohue> If it is just the two of us, we could continue reviewing JIRA tickets (esp those marked for 4.1)
[20:03] * PeterDietz (~peterdiet@dhcp-164-107-232-121.osuwireless.ohio-state.edu) has joined #duraspace
[20:03] <hpottinger> sounds like a plan, if only you were in Missouri I'd suggest adjourning to a pub
[20:04] <tdonohue> Oh, there's PeterDietz...maybe we have 3 now :)
[20:04] <hpottinger> PeterDietz: good webinar, congrats!
[20:05] <PeterDietz> hi
[20:05] <tdonohue> I also heard the webinar was good (though I missed out in attending). Great job, PeterDietz!
[20:06] <tdonohue> So, to bring you in the loop, it looks like attendance is low today... as far as we know, it's just the 3 of us here so far.
[20:06] * hpottinger considers throwing things at the lurkers.
[20:06] <tdonohue> So, I was thinking we could minimally just do some JIRA ticket reviews, and perhaps touch base (as much as we can) on 4.1
[20:07] <hpottinger> wait, there are 3 of us, quorum!
[20:07] <tdonohue> First and foremost though (for anyone listening or reading logs)... DuraSpace did apply for Google Summer of Code this year. The accepted applicants are supposed to be posted on Monday.
[20:08] <hpottinger> been spreading the word to students I think might be interested
[20:08] <tdonohue> Also, I wanted to let everyone know that I'm going to be *out* next week. So, I'll miss the DSpace Dev meeting next Weds (Feb 26)
[20:09] <tdonohue> I'll still be on email off & on...but won't be around in IRC next week
[20:09] <tdonohue> thanks for spreading the word, hpottinger. I'm hopeful we'll get accepted into GSoC this year!
[20:10] <tdonohue> In any case, we'll need someone to lead the DSpace Dev Mtg next week (Feb 26). I suspect the main topic is really just 4.1...getting it finalized and out the door in the next few weeks.
[20:10] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:12] * kshepherd2 (~kim@wireless-nat-1.auckland.ac.nz) has joined #duraspace
[20:12] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[20:12] <hpottinger> hey, look, committers!
[20:12] <tdonohue> wow, and everyone pops in at once. Hello aschweer, kshepherd2 and mhwood. You just doubled our current attendance :)
[20:13] <mhwood> Heh, I just got back from a meeting in another city.
[20:13] <aschweer> hi folks, sorry, coffee had higher priority than being on time :)
[20:13] <tdonohue> I was just going through Discussion Topic #1 in the agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-02-19
[20:13] <kompewter> [ DevMtg 2014-02-19 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-02-19
[20:14] <tdonohue> The main point there was that I'm going to be out next week (Mon-Thurs) and off IRC. So, looking for a volunteer (or two) to lead next week's meeting.
[20:14] <PeterDietz> I'm moving, I value coffee more than timeliness too
[20:16] <tdonohue> Otherwise, you all can "self-organize" next week, which is also OK. I suspect the main topic next week will be 4.1 Release (getting it out the door), which is also our next topic today.
[20:16] <hpottinger> I'm in the process of confirming DS-1795 with Vagrant-DSpace
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-1795 ] - [DS-1795] When run command dspace "dspace stat-initial" - DuraSpace JIRA
[20:17] <tdonohue> Regarding 4.1, it looks like we are closing in on a release. We still have 9 open tickets: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+fixVersion+%3D+%224.1%22+AND+resolution+%3D+Unresolved+ORDER+BY+due+ASC%2C+priority+DESC%2C+created+ASC&mode=hide
[20:17] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+fixVersion+%3D+%224.1%22+AND+resolution+%3D+Unresolved+ORDER+BY+due+ASC%2C+priority+DESC%2C+created+ASC&mode=hide
[20:18] <tdonohue> There's a few tickets in those 9 that could likely be rescheduled for a 4.2. There's also a few though (like 1795) that probably need fixing
[20:19] <tdonohue> and there's also a few marked "code review needed" which just need a quick test & merge
[20:20] <tdonohue> Is it worth our time digging into these remaining tickets (now as a larger group of committers) and trying to get a quick resolution/decision?
[20:21] <mhwood> Maybe at least 1795 and 1781
[20:21] <tdonohue> ok, DS-1795 first
[20:21] <kompewter> [ https://jira.duraspace.org/browse/DS-1795 ] - [DS-1795] When run command dspace "dspace stat-initial" - DuraSpace JIRA
[20:21] <tdonohue> look at the latest comment on 1795... kshepherd noted our issue here (in the last hour's discussion in #dspace)
[20:22] <tdonohue> we have some queries that broke as they are not limiting metadata fields by "schema"...and we now have some duplicate fields in "dc" and "dcterms" schemas
[20:22] <mhwood> Interesting. We'll want to remember where those are, as the metadata evolution takes place.
[20:23] <mhwood> Because we likely will be revisiting each and every one of them.
[20:24] <mhwood> Clearly, for now, we need to add "AND metadata_schema_id = 'dc'".
[20:25] <tdonohue> yep, very true. It seems like we need to fix these queries to specify schema='dc'. It shouldn't be a difficult fix, just needs someone to build a PR & test it out
[20:25] <hpottinger> oh, Vagrant is taking its sweet time, but, I agree with kshepherd's analysis, the SQL looks like it wouldn't work as-is
[20:26] <mhwood> Fixing: easy. Testing: not so sure.
[20:27] <hpottinger> tdonohue: would you be able to add a comment to 1795 outlining what needs to change, and I'll label the ticket as "low hanging fruit"
[20:27] <mhwood> Simply adding another restriction on the result set *shouldn't* break anything. Easy enough to test whether it fixes this problem.
[20:27] <tdonohue> Does anyone have time (this week or next) to tackle this one? (unfortunately I've got a lot on my plate this week and am out most of next week)
[20:28] <mhwood> I can spend a little time on it, if no one is hankerin' to take it on.
[20:28] <tdonohue> hpottinger: I already added a comment to 1795 which links to the offending queries
[20:28] <hpottinger> I'm going to make an effort to label "easy" tickets as "low_hanging_fruit" so we have a way to find the "easy stuff" if anyone is at a loss for something to do. :-)
[20:29] <mhwood> Other than "stat-initial works now" would anyone care to suggest how this should be tested?
[20:29] <tdonohue> FWIW, I can reproduce this 1795 error on an empty fresh_install of master
[20:29] <hpottinger> say if you had a new developer and you needed to give them a crash course in dspace, point them at the "low_hanging_fruit" list
[20:29] <mhwood> hpottinger: sounds good, thanks.
[20:30] <tdonohue> mhwood: stat-initial doesn't work now...at least on "master" and I suspect also on the "dspace-4.x" branch.
[20:30] <mhwood> OK, nobody else wants it. I'll take a look at it, back to wherever dcterms.type was merged.
[20:30] <aschweer> do the dcterms fields have any values at this point? dri2xhtml-alt/Mirage don't always specify the schema, so item lists / pages might show duplicate values once the dcterms fields are populated
[20:31] * kshepherd2 (~kim@wireless-nat-1.auckland.ac.nz) Quit (Ping timeout: 252 seconds)
[20:31] <tdonohue> I believe 1795 will only be reproducible from a *fresh_install* of 4.0. You won't see it happen in an upgrade...cause those registry files only get called on a "fresh_install"
[20:31] <mhwood> I always start with a fresh install when working a bug.
[20:32] <tdonohue> aschweer: no, dcterms have no values yet. All that changed in 4.0 is that the new registry file was added to DSpace. 'dcterms' isn't fully integrated yet
[20:32] <aschweer> ok good, I thought that's where things were at but wasn't sure :) I guess this is a problem for later then
[20:33] <mhwood> Likely the XSL would be depending on Java code somewhere to add the right stuff to the DRI.
[20:33] <tdonohue> aschweer: but that is good to note. It's *highly possible* these queries are not the only ones that fail to specify a schema..... they are just the first we've found thus far
[20:33] <hpottinger> oh, yes... we might want to cast a big net and see what we find
[20:34] * mhwood wonders what the RE will look like.
[20:34] <tdonohue> So, thanks to mhwood for volunteering to investigate 1795...hopefully there's not gotchas in there...it seems like it should be straightforward
[20:35] <tdonohue> The other 4.1 ticket mentioned to review is DS-1781
[20:35] <kompewter> [ https://jira.duraspace.org/browse/DS-1781 ] - [DS-1781] LDAP never uses the specified email_field - DuraSpace JIRA
[20:35] <mhwood> Actually that might wait unless someone is well along with it now.
[20:36] <tdonohue> 1781 looks like it still needs more analysis...and a volunteer to do that analysis
[20:36] <hpottinger> mhwood: github has a fancy search engine, I just dumped the entire sql sequence into the search box on github for dspace/dspace
[20:37] <tdonohue> it seems reasonable to reschedule 1781 for 4.2 though. Still might be nice to track down a volunteer who knows the LDAP stuff well enough to investigate a solution as well :)
[20:37] <hpottinger> let's see if this URL pastes OK: https://github.com/DSpace/DSpace/search?q=SELECT+metadata_field_id+FROM+metadatafieldregistry+WHERE+element+%3D+%27type%27+AND+qualifier+IS+NULL&ref=cmdform
[20:37] <kompewter> [ Search Results · GitHub ] - https://github.com/DSpace/DSpace/search?q=SELECT+metadata_field_id+FROM+metadatafieldregistry+WHERE+element+%3D+%27type%27+AND+qualifier+IS+NULL&ref=cmdform
[20:38] <helix84> hello. catching up.
[20:38] <hpottinger> speaking of people who use ldap :-)
[20:38] <mhwood> That's a lower bound on what we have to look for, but there could be other ways of expressing it.
[20:39] <mhwood> Yes, that's who I would think of first.
[20:39] <hpottinger> helix84: DS-1781?
[20:39] <kompewter> [ https://jira.duraspace.org/browse/DS-1781 ] - [DS-1781] LDAP never uses the specified email_field - DuraSpace JIRA
[20:40] <helix84> I already tested it and talked about it. It doesn't work for me and to work correctly the module it needs larger rework.
[20:40] <helix84> The problem here is I have only 2 or 3 environments where I can test it. There are others that are broken.
[20:41] <mhwood> Probably not suitable for 4.1 then. Defer?
[20:41] <tdonohue> sounds like 1781 needs rescheduling then if it's a much larger issue at hand
[20:42] <helix84> Probably. Let's push it to 4.2. Honestly, I don't see an easy way to make progress on this unless we set up some tests first.
[20:42] <helix84> But I don't know how to do that.
[20:44] <tdonohue> I'm not sure either. It sounds like this needs some closer analysis in general
[20:44] <helix84> Speaking of missing schema specification - yes, there are a lot of such places around the codebase.
[20:45] <mhwood> Any we can think of and jot down in one place would be good to capture. There is going to be more work in this area.
[20:45] <hpottinger> mhwood++ let's capture this and put it on the 5.0 todo list
[20:45] <mhwood> Good place!
[20:45] <helix84> tdonohue: as you can see these days on the list, as I made changes to the module in 3.0, it broke for some people. But I don't see how their environment is different. I can't reproduce their issue. The problem here is I make an improvement in my env and it breaks another env.
[20:47] <hpottinger> I've got maven timing out on Vagrant-DSpace while trying to build Solr
[20:47] <tdonohue> helix84: yep I understand. I wish I had more LDAP knowledge myself to work from. It seems like there's tons of ways to configure LDAP
[20:48] <helix84> remember how we talked about adopting some auth framework? was it Spring's? how about that?
[20:48] <tdonohue> I just closed DS-1899 - it was committed..one less "4.1" ticket
[20:48] <kompewter> [ https://jira.duraspace.org/browse/DS-1899 ] - [DS-1899] Spellchecking is not enabled by default on the whole site - DuraSpace JIRA
[20:48] <mhwood> YAY!
[20:49] <hpottinger> helix84: auth work awaits those who are interested, are *you*?
[20:49] <tdonohue> helix84: yea, that's one option... It's a big endeavor to replace our entire auth framework, but I'd love it if we could do so. It'd be so much easier to use a third party auth framework
[20:49] <helix84> I didn't really test 1899 (broken test env). I'm not sure that it's fixed.
[20:50] <mhwood> YAY**-1?
[20:50] <helix84> the point is we wouldn't be inventing out own wheels
[20:50] <tdonohue> I'm trusting 1899 as bollini committed it. I suspect he just forgot to close it. If we find it is not fixed, we can reopen
[20:50] <helix84> hpottinger: interested - as in testing LDAP and Password methods - not as in developing.
[20:51] <mhwood> Great, we have a tester.
[20:51] <hpottinger> possible authz/n frameworks: Apache Shiro, JAAS, Spring Security
[20:51] <helix84> tdonohue: the problem there is that I made the connection between the problem and the fix - and I'm not sure about that it's the correct fix...
[20:51] <hpottinger> I'm leaning towards Shiro, and you've been added to my notes as a potential collaborator
[20:52] <helix84> hpottinger: no problem, I'm on many blacklists already :)
[20:52] <aschweer> one of my repos uses LDAP but I don't understand much about it. we override the e-mail field coming in from LDAP by specifying a netid_email_domain. Does that mean I might have a useful test env?
[20:53] <hpottinger> well, my notes do happen to be white text on a black background, but that's just because I'm a coder, no other meaning need to be inferred from the color scheme
[20:53] <helix84> aschweer: It's different from those I have, so yes, it's useful
[20:53] <aschweer> helix84: cool, feel free to ping me when you need a tester
[20:54] <hpottinger> it's possible we could set up a test LDAP service with Vagrant-DSpace
[20:54] <helix84> aschweer: please add me on Skype (helix84). I see multiple "you" there :)
[20:54] <hpottinger> and it's a good idea to do so, for testing AuthN/Z replacements
[20:55] <tdonohue> Regarding an Auth frameworks, it'd be nice to get a wiki page up somewhere to compare options/thoughts. Ideally we find something that can support our current auth options.
[20:55] <tdonohue> Since we are still early in the year, there's tons of time to try and get a new Auth framework into 5.0 -- we just need to get the ball rolling, etc.
[20:56] <hpottinger> tdonohue: ideally, yes, that work will be done, in reality, we'll probably be writing some code for the new frameworks
[20:56] <mhwood> But we may not have to fix or adapt it later.
[20:57] <tdonohue> hpottinger: right, I understand. Still would be nice to get some sort of notes/comparision of Shiro vs. JAAS vs. Spring Security up on a wiki page...that way we can point the other Committers/Developers at it to get their feedback before we jump too far
[20:57] * kshepherd2 (~kim@wireless-nat-1.auckland.ac.nz) has joined #duraspace
[20:57] <hpottinger> it's a good idea, I can move my notes to the wiki
[20:57] <tdonohue> Just want to avoid jumping into using one framework only to find out later that several other Committers have used it before and found it problematic, etc
[20:58] <tdonohue> hpottinger: that'd be great! I don't think we are looking for a broad consensus necessarily (there will always be disagreements) but we want to "do our homework" and listen to those disagreements (if any)
[20:59] <hpottinger> I tend to favor software with established communities, and it looks like Apache is building a good one for Shiro
[21:00] <tdonohue> hpottinger +1 (Shiro honestly sounds reasonable to me, but I don't have any experiences here to speak from with it)
[21:00] <tdonohue> Ok, looks like we are at 1 hour here, and we've slightly gone on a tangent (but still a good one)
[21:01] <hpottinger> so, I'm open to suggestions on where to put this new project page
[21:01] <hpottinger> kshepherd: where did you end up putting the streaming page?
[21:01] <tdonohue> Regarding 4.1...we had mentioned Feb 28 (end of next week) as a possible date. Seems like it might be doable still, just need to get these last few tickets resolved
[21:01] <tdonohue> hpottinger: yea, I was gonna say put it alongside kshepherd's streaming page
[21:02] <aschweer> sorry, I have to leave. bye all
[21:02] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[21:03] <hpottinger> found it: https://wiki.duraspace.org/pages/viewpage.action?pageId=45548591
[21:03] <kompewter> [ Audio/Video Streaming (RTMP, HLS, DASH) Support - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/pages/viewpage.action?pageId=45548591
[21:04] <tdonohue> regarding our 4.1 tickets...it seems like (to me) the highest priority to get closed for 4.1 are: DS-1536 (nearly done), DS-1779 (kshepherd just claimed), DS-1795 (mhwood just claimed), DS-1352 (needs PR review), DS-1912 (needs PR review). The others likely could be rescheduled for a 4.2
[21:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1536 ] - [DS-1536] having a DOT in handle prefix causes identifier.uri to be cut off when being created - DuraSpace JIRA
[21:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1779 ] - [DS-1779] Pagination link error in JSPUI discovery search - DuraSpace JIRA
[21:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1795 ] - [DS-1795] When run command dspace "dspace stat-initial" - DuraSpace JIRA
[21:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1352 ] - [DS-1352] Itemimport replace issue - DuraSpace JIRA
[21:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1912 ] - [DS-1912] Discovery facets do not always use the authority identifier - DuraSpace JIRA
[21:05] * kshepherd2 (~kim@wireless-nat-1.auckland.ac.nz) Quit (Ping timeout: 240 seconds)
[21:06] <helix84> hpottinger: I've been out of the loop on 1536. Where do we stand?
[21:06] <tdonohue> I think 1536 is "done" except for any docs around a SQL query fix?
[21:06] <helix84> I'm going to take another look at 1352
[21:06] <hpottinger> 1536, fair question, I could say the same for helix84 :-)
[21:07] <helix84> tdonohue: yes, but I'm not sure what was done and what is left to be done
[21:07] <tdonohue> re-looking at 1352 -- this looks to be a rather significant reworking of the functionality. Is this truly a bug fix, or an "improvement" (in which case we might want to think about a 5.0 release)?
[21:07] <tdonohue> 1352's PR: https://github.com/DSpace/DSpace/pull/473
[21:07] <kompewter> [ [DS-1352] - Itemimport replace issue by rramos · Pull Request #473 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/473
[21:09] <helix84> tdonohue: I think you could say either. As far as I tested it I didn't encounter any problem (except that it didn't fix the problem the way I expected, but then it was explained).
[21:10] <helix84> are there any commiters who know how to write test cases? because I'd like to learn it. This and the auth changes are all great examples of where tests would be great before we make changes to the code.
[21:11] <tdonohue> I think what "worries" me about 1352 is the addition of some new methods to Collection and Item *just for* this bug fix. At a glance it looks OK, but makes me wonder if it needs a Testathon
[21:13] <hpottinger> I hate to make it wait a year, but, tdonohue is correct, this needs more thorough testing, I think
[21:13] <mhwood> Is it legitimate to expect item_id to persist across a replace? Item_id feels like internals to me.
[21:14] <mhwood> I wonder if the proper fix for this problem is "don't do that".
[21:14] <tdonohue> helix84: Regarding "test cases" what do you mean? There's JUnit unit test (plenty of tutorials out there, and our code at dspace-api/src/test/). But, we don't have a good framework for handling all types of tests (e.g. functional tests, UI tests)
[21:14] <helix84> mhwood++: for a proper fix, we should use something else, like in your proposal (e.g. GUID)
[21:15] <hpottinger> mhwood's point is worth considering, is the problem that stats are using an ephemeral internal ID?
[21:15] <tdonohue> I agree with mhwood: item_id is internals. Even AIPs do not persist item_id...they only persist handles
[21:15] <mhwood> At the least, perhaps the proper thing to do is to look up the ID again.
[21:15] <helix84> mhwood: but then statistics and everything else will need to migrate to the new IDs
[21:16] <helix84> mhwood: not a problem, but lot of work
[21:16] <mhwood> helix84: so if we did it wrong, then the fix is to do it right.
[21:16] <hpottinger> punt to 5.0, I think we need more engineering here
[21:16] <helix84> mhwood: we might use this as a short-term fix
[21:16] <mhwood> Yeah, 5.0
[21:16] <tdonohue> And it is worth noting that AIPs *do allow you to replace items while also keeping relationships in tact* (Though in that scenario it's because AIPs store those relationships as well)
[21:17] <tdonohue> So, this use case could be solved by AIPs rather than ItemImport
[21:17] <mhwood> wontfix: wehaveabetterway
[21:18] <mhwood> Separately, any tools that use object IDs probably should be rethought until they don't.
[21:18] <mhwood> Use object IDs as user arguments, that is.
[21:18] <helix84> mhwood: anyway, what will happen to existing SAF packages when we introduce GUID? will they be importable?
[21:18] <tdonohue> I don't know yet if we outright close 1352 or not..but I can at least mention AIPs as a better way to do replacements while retaining relationships
[21:18] <mhwood> Presumably objects MUST have DSpace IDs, and will have one imposed if not provided.
[21:19] <tdonohue> at the very least though, it sounds like 1352 should be rescheduled for 5.0...needs more thought
[21:19] <mhwood> Yes, reschedule.
[21:20] <tdonohue> ok, cool. I'll add a comment and reschedule 1352
[21:20] <tdonohue> So, the only other ticket with a PR needing review is DS-1912...and the PR looks small
[21:20] <kompewter> [ https://jira.duraspace.org/browse/DS-1912 ] - [DS-1912] Discovery facets do not always use the authority identifier - DuraSpace JIRA
[21:20] <helix84> mhwood: so existing package will get new item_id and GUID during import and for newly exported SAFs we would include the existing GUID, right?
[21:21] <mhwood> I don't recall what a SAF is? DSpace ID has NO MEANING outside of a single instance of DSpace, and should not be exported or imported. It can and should be backed up and restored.
[21:22] <helix84> mhwood: that wasn't the idea here, either. it was only to keep the existing item_id when replacing an item (specified by handle) within an instance.
[21:22] <mhwood> 1912: I have no idea what the code is doing here. The fix is not obviously wrong, to me.
[21:22] <helix84> mhwood: so, to rephrase, after introducing GUID, we will be adding GUID to SAF
[21:23] <helix84> mhwood: SAF is the package format exported by the "export" command
[21:23] <mhwood> Ah, Simple Archive Format.
[21:25] <hpottinger> 1912: it looks like it's swapping out display value for an authority key
[21:26] <hpottinger> this is a small change, and it's Kevin's area of expertise, I'm inclined to trust him
[21:26] <tdonohue> hpottinger +1 that's what I was leaning towards too, with 1912
[21:27] <mhwood> I think so too.
[21:27] <hpottinger> that's 3 for merge, sounds like, to me
[21:28] <mhwood> helix84: we need to think about what the DSpace ID means to the instance. Maybe it should *never* escape to an external representation. I don't know.
[21:28] <helix84> mhwood: I agree. That's the whole reason for introducing GUID.
[21:29] <helix84> mhwood: in connection for our reluctance to be dependent on handles as the sole external identifier
[21:29] <mhwood> So the GUID (or whatever) has meaning only for an object *in an instance*.
[21:29] <hpottinger> well, hearing no screams of "wait!" I'm going to go into "push the button, Max!" mode on 1912
[21:30] <helix84> mhwood: oh, then I disagree. The same GUID should mean the same thing globally.
[21:32] <hpottinger> DSPR#474 merged, closed DS-1912 as fixed
[21:32] <kompewter> [ https://github.com/DSpace/DSpace/pull/474 ] - [DS-1912] Discovery facets do not always use the authority identifier by KevinVdV
[21:32] <kompewter> [ https://jira.duraspace.org/browse/DS-1912 ] - [DS-1912] Discovery facets do not always use the authority identifier - DuraSpace JIRA
[21:32] <mhwood> I mean, the object exists inside an instance. The DSpace ID has meaning there. It has no meaning in any derivative.
[21:34] <mhwood> I only suggested GUID because it's simple to generate and needs no coordination between instances.
[21:34] <helix84> mhwood: I agree that item_id, bitstream_id etc have meaning only withing an instance. The way I see the effort to introduce GUID is to gain a global identifier (across instances) different from handle.
[21:34] * kshepherd2 (~kim@wireless-nat-1.auckland.ac.nz) has joined #duraspace
[21:34] <hpottinger> blundered into a prior discussion on AuthZ here: https://wiki.duraspace.org/display/DSPACE/AuthorisationSystem
[21:34] <kompewter> [ AuthorisationSystem - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/AuthorisationSystem
[21:35] <mhwood> helix84: there are plenty of those already. Take your pick. What I was trying to do was to give us something that can never be pinned down in anyone else's records.
[21:36] <mhwood> Every time we invent something with external meaning, someone tries to remember it for later and then we have problems.
[21:37] <mhwood> We need something that is defined to be usable only by your single instance of DSpace, with the explicit expectation that if you store it somewhere else we can break it at any time.
[21:38] <mhwood> If you export objects for backup, and restore them, you get new DSpace IDs.
[21:38] <helix84> mhwood: I don't understand your reasoning. Why do we need that? We already have that in DB primary keys (item_id et al). What we need is something to indentify a particular object (say, version of an item) so that we can move it around instances/backups.
[21:38] <mhwood> The DB primary keys are controlled by the DBMS, *not DSpace*.
[21:39] <helix84> mhwood: why do we need to control it?
[21:39] <mhwood> Because otherwise it can change out from under us.
[21:39] <mhwood> I wish I had kept a list, but over and over we've had problems with identifiers pinned by others.
[21:40] <mhwood> I think my final motivation was something to do with REST.
[21:40] <mhwood> If you want to identify a transportable object, give it a Handle or a DOI or....
[21:40] <helix84> mhwood: so, in this instance of item_id used by statistics, we need something to connect the item in stats and the item in archive, but export/import changed it meanwhile. Is this why we need it?
[21:41] <mhwood> I've been away from this issue for a while. I need to reload it. Which may mean I haven't finished thinking it through.
[21:42] <tdonohue> yep, stats shouldn't be connected by item_id, as it's "fragile" connection. If you ever restore that Item from an AIP backup, the item_id may change which would then lose your existing stats.
[21:43] <helix84> mhwood: when you do, please consider GUID as an identifier for a particular version of an item. I'm curious to hear what that would break.
[21:44] * PeterDietz (~peterdiet@dhcp-164-107-232-121.osuwireless.ohio-state.edu) Quit (Remote host closed the connection)
[21:46] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[21:47] <mhwood> Thinking about this a bit, I believe that the reason for the internal ID to be mutable was solely to make it useless for people to save a copy elsewhere. But I need to review my notes and such.
[21:50] <helix84> mhwood: I don't think we would intentionally design it that way. I think it's only a consequence of the effort to prevent duplicate IDs of the same object type within an instance (IOW, primary key)
[21:51] <tdonohue> commented on DS-1352 and marked for 5.0
[21:51] <kompewter> [ https://jira.duraspace.org/browse/DS-1352 ] - [DS-1352] Itemimport replace issue - DuraSpace JIRA
[21:52] <tdonohue> I just realized I never officially "closed" the meeting here. Sorry about that. I don't plan to call any more topics, but I'll still be hanging around for a bit
[21:53] <helix84> I have to go, too. Mark, we'll talk later.
[21:53] <helix84> Good night, all.
[21:54] <mhwood> Agreed.
[21:54] <mhwood> Must also depart in a few minutes.
[21:58] * hpottinger throws down the gauntlet
[21:58] <hpottinger> https://wiki.duraspace.org/display/DSPACE/Replace+Authentication+and+Authorization+code+in+DSpace+with+a+3rd-party+framework
[21:58] <kompewter> [ Replace Authentication and Authorization code in DSpace with a 3rd-party framework - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Replace+Authentication+and+Authorization+code+in+DSpace+with+a+3rd-party+framework
[21:59] <tdonohue> awesome, hpottinger
[22:00] <hpottinger> gosh, if anyone has some spare time, this page needs work: https://wiki.duraspace.org/display/DSPACE/Development+Areas
[22:00] <kompewter> [ Development Areas - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Development+Areas
[22:01] <mhwood> Do we have a 5.0 status page to link all these worthy projects?
[22:02] <hpottinger> https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.0+Notes?src=search
[22:02] <kompewter> [ DSpace Release 5.0 Notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.0+Notes?src=search
[22:03] <mhwood> Great. Bye for now.
[22:03] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:22] <helix84> hpottinger: is this the same Solr building problem as you're getting? https://travis-ci.org/DSpace/DSpace/builds/19217641
[22:22] <kompewter> [ Travis CI - Free Hosted Continuous Integration Platform for the Open Source Community ] - https://travis-ci.org/DSpace/DSpace/builds/19217641
[22:23] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) Quit (Quit: Later, taterz!)
[22:24] * kshepherd2 (~kim@wireless-nat-1.auckland.ac.nz) Quit (Ping timeout: 246 seconds)
[22:32] * kshepherd2 (~kim@wireless-nat-1.auckland.ac.nz) has joined #duraspace
[22:58] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has left #duraspace
[23:19] * kshepherd2 (~kim@wireless-nat-1.auckland.ac.nz) Quit (Ping timeout: 240 seconds)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.