Timestamps are in GMT/BST.
[0:20] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Remote host closed the connection)
[2:20] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[2:26] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 240 seconds)
[2:37] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 276 seconds)
[2:49] * kshepherd (~kim@wireless-nat-21.auckland.ac.nz) has joined #duraspace
[3:18] * kshepherd (~kim@wireless-nat-21.auckland.ac.nz) Quit (Ping timeout: 260 seconds)
[3:33] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[4:51] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 240 seconds)
[6:22] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[6:28] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 264 seconds)
[6:34] -sinisalo.freenode.net- *** Looking up your hostname...
[6:34] -sinisalo.freenode.net- *** Checking Ident
[6:34] -sinisalo.freenode.net- *** Found your hostname
[6:34] -sinisalo.freenode.net- *** No Ident response
[6:34] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:34] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:34] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:35] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[8:29] * tmmguimaraes (~tmg@193.137.88.100) has joined #duraspace
[11:49] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[12:00] -verne.freenode.net- *** Looking up your hostname...
[12:00] -verne.freenode.net- *** Checking Ident
[12:00] -verne.freenode.net- *** Found your hostname
[12:00] -verne.freenode.net- *** No Ident response
[12:00] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[12:00] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[12:00] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:44] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:53] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) has joined #duraspace
[14:20] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[14:57] * hpottinger (~hpottinge@mu-161168.dhcp.missouri.edu) has joined #duraspace
[15:41] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Remote host closed the connection)
[16:05] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[16:54] * tmmguimaraes (~tmg@193.137.88.100) Quit (Quit: Leaving)
[17:42] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[17:46] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 244 seconds)
[18:13] * th5 (~th5@unaffiliated/th5) has joined #duraspace
[18:57] * roeland_atmire (~roeland_a@d54C02199.access.telenet.be) has joined #duraspace
[19:21] * tmmguimaraes (~tmgg@89-181-187-69.net.novis.pt) has joined #duraspace
[19:43] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[19:48] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 244 seconds)
[20:01] <tdonohue> Hi all, it's time for the DSpace DevMtg. Here's today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-05-25
[20:01] <kompewter> [ DevMtg 2016-05-25 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-05-25
[20:02] <tdonohue> So, 6.0 is obviously the highest priority to keep pushing on today. But, before I get to that, I did want to touch briefly on our OR16 face-to-face Developers / DCAT meeting
[20:03] <tdonohue> We have some *suggested topics* for that meeting listed here: https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-06-13+-+OR16+Meeting#DevMtg2016-06-13-OR16Meeting-SuggestedTopics
[20:03] <kompewter> [ DevMtg 2016-06-13 - OR16 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-06-13+-+OR16+Meeting#DevMtg2016-06-13-OR16Meeting-SuggestedTopics
[20:03] * mjmarttila_ (8da10da4@gateway/web/freenode/ip.141.161.13.164) has joined #duraspace
[20:04] <tdonohue> I'm working on the schedule for the meeting, and I wanted to see if there's anything (either on that list or off that list) that *you* feel would be a high priority to talk about at OR16?
[20:04] <tdonohue> The two topics I think are *definite* (in my mind) are DSpace-CRIS (as Cineca will be there and is willing to talk about it)... and the New UI (although there also will be a formal presentation on this later in the week as well)
[20:04] <tdonohue> Other topics?
[20:05] <roeland_atmire> I see usage statistics on the list
[20:06] <tdonohue> Or is there anything in particular you'd like to hear about DSpace-CRIS or the New UI project? I'm really trying to ensure we can make this a worthwhile discussion and touch on everything of high interest
[20:06] * KevinVdV (~KevinVdV@d54C5104D.access.telenet.be) has joined #duraspace
[20:07] <tdonohue> roeland_atmire: yes, currently though it's just a list of idea... I'm trying to tease out which of these have broad interest, and which may not
[20:07] <tdonohue> list of *ideas*
[20:07] <roeland_atmire> Usage statistics have my interest
[20:07] <roeland_atmire> but I may be the only one
[20:07] <hpottinger> would be lovely to hear an answer to "why Angular 2?" so we can be ready to explain to others?
[20:07] <mhwood> List<Idea> makes perfect sense. :-)
[20:07] <terry-b3> Is there any outstanding discussion from the Elsevier enhancement that needs discussion?
[20:08] <roeland_atmire> +1 on why angular 2
[20:08] <tdonohue> hpottinger: that can be covered. I was anticipating that question/discussion. Thanks though for mentioning it
[20:09] <tdonohue> terry-b3: good question. There are proposed features their to discuss. Not sure if they all require a face-to-face, but it could be touched upon as well
[20:10] <tdonohue> My plan here is to try and find the top 3 to 4 topics. Those ones are definitely going to be discussed (and two of them are New UI and DSpace CRIS). After that, we'll have a list of "possible other topics" if we end up with extra time
[20:10] <hpottinger> re: key signing, I like the idea, enough that I made the .ps file of my key fingerprint to hand out, have printed it and just need to cut it to ribbons
[20:10] <terry-b3> I proposed the community expertise, service api, and metadata authority topics, so I am interested in those 3 topics
[20:11] <hpottinger> +1 Hibernate: now what?
[20:11] <tdonohue> So, if you have more ideas to add into the mix, please pass them along (or add +1 comments to that Wiki page). I'll begin drafting up this meeting agenda likely later this week or early next. But there will still be some time to finalize or make minor tweaks
[20:12] <mhwood> We probably *should* have a more general discussion of the Elsevier contribution: how well has it gone so far, and what can we learn from the experience? (And we do need to finish up taking it in.)
[20:13] <mhwood> Dunno if the meeting is the place for that.
[20:13] <tdonohue> good point mhwood. Might be a matter of what the final attendee list looks like though. Not sure that's a discussion to have in a large public venue. But, if it's mostly Committers / DCAT, it'd be a good one
[20:15] <hpottinger> Maybe just an overview of the process "how code gets into DSpace"
[20:15] <tdonohue> Ok, in any case, this gives me something to go on. I'll start doing some agenda writing in the coming days, and we can see how this starts to work out. I will keep all topics up there though, in case we end up with extra time at the end, etc
[20:16] <tdonohue> hpottinger: good idea...again depends on audience though. May have to see who shows up (once I get a list of folks registered)
[20:16] <hpottinger> right... I know it seems like a really basic thing to discuss... but it also seems like we lose track of the idea from time to time
[20:17] <tdonohue> Ok, so, let's move along to DSpace 6 topics (Add OR16 ideas to wiki page please, if you have more). We've still got a lot to get done on DSpace 6, but I'm thankful we have a lot of you submitting, testing PRs, etc.
[20:19] <tdonohue> So, with regards to 6.0...in the nearterm, I'd really like to see us get fixes pushed out to demo.dspace.org so that we can get more centralized followup testing (from all us and others). I know I keep hitting the same known issues on demo these days
[20:19] <hpottinger> do we need an RC2?
[20:20] <KevinVdV> I think we should really fix: https://github.com/DSpace/DSpace/pull/1382 before RC2, it fixes a lot of issues (I think 4 or 5 JIRA’s are linked to this one)
[20:20] <kompewter> [ [DS-3179] Collection admin, edit item no authorization to remove file by KevinVdV · Pull Request #1382 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1382
[20:20] <tdonohue> We do, yes. But, I'm wondering if we push fixes out to demo.dspace.org *before* and RC2. While we could release an RC2, we have a good number of known issues still outstanding.
[20:21] <tdonohue> *before* an RC2 (i meant)
[20:22] <tdonohue> I agree, we probably need to track down which tickets are a *must* before RC2 (in my mind, any significant bugs or further changes to DB migrations would be included in RC2)
[20:22] <tdonohue> so, since KevinVdV mentioned it, looks like DSPR#1382 is at +1
[20:22] <kompewter> [ https://github.com/DSpace/DSpace/pull/1382 ] - [DS-3179] Collection admin, edit item no authorization to remove file by KevinVdV
[20:24] <tdonohue> The changes in 1382 seem reasonable to me. hpottinger, looks like you tested it?
[20:26] <tdonohue> KevinVdV also noted (in PR comments) it'd be good to have multiple testers, since this changes the logic of deleting bitstreams (and we want to be very careful about that)
[20:26] <tdonohue> Volunteers to help here?
[20:26] <KevinVdV> Yeah, we should also have testers delete (sub) communities & collections as a community admin
[20:27] <tdonohue> KevinVdV: could you add a list of recommended tests to the PR's description?
[20:27] <tdonohue> (that way we can ensure volunteers know what to test)
[20:27] <KevinVdV> Will update the PR with a checkbox with tests
[20:27] <tdonohue> thanks!
[20:29] <tdonohue> Ok, so hearing a bunch of silence here. No one else interested in helping test this one out? Sounds like we need a test of Community Admin rights to delete Communities, Collections, Items, Bitstreams
[20:29] <roeland_atmire> I’ll take it
[20:29] <tdonohue> thanks roeland_atmire!
[20:30] <tdonohue> If others can chip in, please also do so. I've noted this on my list as well as one to try to get to
[20:31] <tdonohue> Are there other PRs / Tickets we want to highlight as highest priority (especially for an RC2 release)?
[20:32] <KevinVdV> https://github.com/DSpace/DSpace/pull/1326 (we still need to fix a small issue here first)
[20:32] <terry-b3> Could we discuss https://github.com/DSpace/DSpace/pull/1399
[20:32] <kompewter> [ DS-3086 OAI Harvester is broken by DylanMeeus · Pull Request #1326 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1326
[20:32] <kompewter> [ DS-3209 AIP Import: Extend accepted handles for supports() by mjmarttila · Pull Request #1399 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1399
[20:32] <tdonohue> let's start at DSPR#1326 (we'll get back to the other terry-b3)
[20:32] <kompewter> [ https://github.com/DSpace/DSpace/pull/1326 ] - DS-3086 OAI Harvester is broken by DylanMeeus
[20:32] <terry-b3> sounds good
[20:33] <KevinVdV> I’m aware that there is a code bug, but a code review by the community is also wanted here. It introduces some new methos to improve performance in bulk tasks.
[20:34] <KevinVdV> (Don’t be afraid of the 120 files changed, the change was needed to give every entity a getID() method)
[20:34] * tmmguimaraes (~tmgg@89-181-187-69.net.novis.pt) Quit (Quit: Leaving)
[20:34] <tdonohue> KevinVdV: are there some docs/notes here to describe it a bit more?
[20:35] <tdonohue> Oh wait, I found this from Tom: https://jira.duraspace.org/browse/DS-3086?focusedCommentId=49448&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-49448
[20:35] <kompewter> [ [DS-3086] OAI Harvester is broken (NPEs around several classes) - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3086?focusedCommentId=49448&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-49448
[20:35] <kompewter> [ https://jira.duraspace.org/browse/DS-3086 ] - [DS-3086] OAI Harvester is broken (NPEs around several classes) - DuraSpace JIRA
[20:36] <KevinVdV> Indeed, general idea + guidelines & numbers should all be in there
[20:38] <terry-b3> I'll be happy to test this if we feel that this is ready for testing.
[20:38] <hpottinger> I can re-test using the updated PR and see if the NPE is still there
[20:38] <KevinVdV> Will try to get that NPE out of the way this week
[20:38] <tdonohue> I think testing is good. I agree with KevinVdV that it also needs a general code review. It *sounds* interesting to me though, and I can understand how it might also benefit other batch operations
[20:39] <tdonohue> This seems like it also has to be in an RC2
[20:40] <tdonohue> thanks terry-b3 and hpotttinger. Testing would be great. Thanks KevinVdV on working to get the NPE fixed quickly
[20:41] <tdonohue> I'll promise to give this one a code review. It's a lot to get through right now, but Tom's description in the ticket comment sounds good to me. Just want to dig into the code as well
[20:43] <tdonohue> I just created a new "high priority" label in GitHub to flag these PRs
[20:44] <tdonohue> (we can rename the label later as needed...just wanted to give these some sort of higher priority to test/review)
[20:44] <tdonohue> ok. So, moving on...
[20:45] <tdonohue> back to DSPR#1399 (as requested by terry-b3)
[20:45] <kompewter> [ https://github.com/DSpace/DSpace/pull/1399 ] - DS-3209 AIP Import: Extend accepted handles for supports() by mjmarttila
[20:45] <terry-b3> We build our test systems from AIP exports.
[20:46] <terry-b3> Our test systems create handles with a suffix (making them distinguishable from items created in prod).
[20:46] <terry-b3> We did this at the advice of the hdl.handle.net folks.
[20:46] <terry-b3> The changes pnbecker proposed would make it difficult to continue this practice (without a local code override).
[20:47] <terry-b3> If our practice is out of the norm, we can resolve this locally, but the proposed change seemed very restrictive.
[20:47] <mjmarttila_> Just for reference, the line in question that would cause the difficulties: https://github.com/tuub/DSpace/commit/9961a876274af8f13017c3d10eafe0d8475e7377#diff-b636ee11c35a6c52616e6d770b097857R353
[20:47] <kompewter> [ Addition to DSPR#1399: check for supported handle. · tuub/DSpace@9961a87 · GitHub ] - https://github.com/tuub/DSpace/commit/9961a876274af8f13017c3d10eafe0d8475e7377#diff-b636ee11c35a6c52616e6d770b097857R353
[20:48] <tdonohue> sorry there's a lot of discussion in these comments. Am I understanding though that you just want DSpace to be able to generate handles with *dots* in them?
[20:49] <terry-b3> We want to be able to ingest a prod handle into a test server. The test server generates its own handle prefix.
[20:49] <terry-b3> Perhaps this could be resolved by having 2 properties (one for import, and one for assignment).
[20:50] <roeland_atmire> so you want handles like 123456789/1810/123
[20:50] <roeland_atmire> ?
[20:50] <terry-b3> No. We want to import 12345/111 but assign 12345.1/222
[20:51] <terry-b3> This has worked for us on DSpace 4 and Dspace 5.
[20:51] <mhwood> If you export an AIP from instance A (prefix 1) and import it to instance B (with prefix 2) the imported objects keep their 1/* Handles. This is a problem?
[20:51] <terry-b3> That is what we want. The proposed code forces the import values and assigned values to use the same prefix
[20:52] <KevinVdV> I need to run, until next time !
[20:52] * KevinVdV (~KevinVdV@d54C5104D.access.telenet.be) Quit (Quit: KevinVdV)
[20:54] <tdonohue> Ok, so I'll admit, this code change is a bit dense (out of context). I think I agree though that the old way probably is the right way
[20:54] <tdonohue> I'm having trouble following the code though
[20:55] <mhwood> It seems to me that we should not be checking for specific prefixes on ingest. supports() returning true should only mean "this provider is positive that it understands the given identifier format", no?
[20:56] <mhwood> I.e. if it can be understood as a Handle (*any* Handle) then Handle providers should return true.
[20:57] <mjmarttila_> The previous DSpace4x/5x retrieveHandleOutOfUrl() method did not have a handle validation
[20:57] <mjmarttila_> This is a new suggested addition in pnbecker's code
[20:57] <tdonohue> mhwood: yes, that makes sense to me too. The one "gotcha" is that ingest sometimes has to *assign* a handle (if it's a new submission and a handle doesn't exist). Handle assignment unfortunately can only be with *one* prefix.
[20:58] <mhwood> If it has to assign a Handle then it should use the configured prefix. But that's nothing to do with IdentifierProvider.supports().
[20:58] <tdonohue> I wish pbecker was here today...cause perhaps we'd get a better explanation why he needs this code
[20:58] <mhwood> I agree.
[20:58] <terry-b3> Should we paste this discussion into the PR?
[20:58] <mjmarttila_> If it helps, the following was his explanation in the PR: I added the line in question to ensure, that we a) have a handle and b) that we have a handle we are responsible for. When I saw the message I became afraid that the VersionedHandleIdentifierProvider would accept URLs like http://dx.doi.org/10.14279/depositonce-5015 as handle. While DOI build up on handle, the VersionedHandleIdentifierProvider shouldn't deal with DOIs
[20:58] <kompewter> [ Repositorien und das Semantic Web - DepositOnce ] - http://dx.doi.org/10.14279/depositonce-5015
[20:59] <mhwood> I don't think that supports() is supposed to care whether we are responsible for the handle.
[20:59] <mjmarttila_> I think (b) was his main concern
[21:00] <mhwood> *HandleIdentifierProvider.supports() should reject http://dx.doi.org/*, doi:* and the like. They are technically Handles but they have their own provider.
[21:02] <mhwood> I suppose that "10.14279/*" should be rejected as well.
[21:03] <tdonohue> Handles prefixes should support dots. Some people use handle prefixes with dots in production. I'm reminded we had an issue about this a while back... here it is DS-1536
[21:03] <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:03] <tdonohue> So, I think we shouldn't be doing this prefix validation. We really cannot do much more than ensure we are assigning *just one* prefix
[21:04] <mjmarttila_> I apologize for dashing on our ticket, but I need to leave. Thanks very much to everybody for helping clarify the ticket
[21:04] <tdonohue> There also are DSpace instances that harvest from other sites (via OAI-PMH)...in which case one DSpace might actually have items of many different handle prefixes... Texas Digital Library has this I believe
[21:05] * mjmarttila_ (8da10da4@gateway/web/freenode/ip.141.161.13.164) Quit (Quit: Page closed)
[21:05] <mhwood> DOI is a special case, though: it's a subset of Handle space. Handle providers should check "is this a DOI" and reject it if so.
[21:05] <mhwood> But only allowing the configured Handle prefix is the wrong way to test for this.
[21:06] <tdonohue> mhwood: true. Could you add comments to the PR as well? I'll also note the examples I mentioned
[21:06] <mhwood> OK, and then I also must go.
[21:06] <terry-b3> Thanks for the discussion time on this.
[21:06] <tdonohue> Ok, thanks all! Sorry we've gone long. But it was good to get talking about some things that needed more discussion / higher priority
[21:08] <tdonohue> So, let's keep pushing things forward for 6.0. If you find another PR that *must* be in RC2, please flag it as "high priority". I'll make an effort to concentrate my efforts there (since I feel like I've had less time recently to offer)
[21:08] <tdonohue> And please continue to keep testing / reviewing these PRs. Would be really good to get RC2 out next week if we can, and hopefully move quickly to an 6.0 shortly after
[21:09] <tdonohue> with that, I'm going to close things up for today. thanks again
[21:10] * roeland_atmire (~roeland_a@d54C02199.access.telenet.be) Quit (Quit: roeland_atmire)
[21:15] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:32] * th5 (~th5@unaffiliated/th5) Quit ()
[21:44] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[21:49] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 250 seconds)
[21:59] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) has left #duraspace
[22:01] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[22:11] * hpottinger (~hpottinge@mu-161168.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[22:35] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) Quit (Quit: Leaving.)
[22:38] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[23:45] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[23:51] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 276 seconds)
[23:59] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.