Timestamps are in GMT/BST.
[0:24] * Dylan_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 244 seconds)
[2:20] * Dylan_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[2:26] * Dylan_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 272 seconds)
[3:12] * misilot_ (~misilot@p-body.lib.fit.edu) has joined #duraspace
[3:15] * misilot (~misilot@p-body.lib.fit.edu) Quit (Ping timeout: 240 seconds)
[4:21] * Dylan_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[4:26] * Dylan_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 276 seconds)
[5:07] * cwilper (~cwilper@54.213.30.97) has joined #duraspace
[6:22] * Dylan_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[6:27] * Dylan_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 250 seconds)
[6:31] * misilot_ (~misilot@p-body.lib.fit.edu) Quit (Read error: Connection reset by peer)
[6:31] * misilot_ (~misilot@p-body.lib.fit.edu) has joined #duraspace
[6:48] -hitchcock.freenode.net- *** Looking up your hostname...
[6:48] -hitchcock.freenode.net- *** Checking Ident
[6:48] -hitchcock.freenode.net- *** Found your hostname
[6:48] -hitchcock.freenode.net- *** No Ident response
[6:48] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:48] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:48] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:11] * Dylan_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[8:27] * tmmguimaraes (~tmg@193.137.88.100) has joined #duraspace
[9:42] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[9:51] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: bbl)
[10:06] * helix84 (~ctenar@unaffiliated/helix84) Quit (Read error: Connection reset by peer)
[10:43] * Dylan_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Read error: Connection reset by peer)
[10:43] * Dylan_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[11:30] * pbecker (~pbecker@130.149.177.214) has joined #duraspace
[11:59] * misilot_ is now known as misilo
[11:59] * misilo is now known as misilot
[12:13] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:06] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) has joined #duraspace
[13:58] * Dylan_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Remote host closed the connection)
[14:19] * dyelar (~dyelar@129.237.45.105) has joined #duraspace
[14:21] * helix84 (~ctenar@unaffiliated/helix84) has joined #duraspace
[14:23] * pbecker (~pbecker@130.149.177.214) Quit (Quit: Leaving)
[14:31] * tmg (~tmg@193.137.88.100) has joined #duraspace
[14:34] * tmmguimaraes (~tmg@193.137.88.100) Quit (Ping timeout: 258 seconds)
[14:41] * tmg (~tmg@193.137.88.100) Quit (Quit: Leaving)
[14:41] * tmmguimaraes (~tmg@193.137.88.100) has joined #duraspace
[14:53] * roelandatmire (~roeland@85.234.195.109.static.edpnet.net) has joined #duraspace
[15:01] <tdonohue> Hello all, it's time for our DSpace Developers Meeting: https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-06-01
[15:01] <kompewter> [ DevMtg 2016-06-01 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-06-01
[15:02] <terry-b3> Hello
[15:02] <tdonohue> So, obviously the main topics for today are 6.0 and OR16 (coming very soon).
[15:03] <tdonohue> Most of the meeting will be spent on 6.0, but I did want to mention that I *just* posted a tentative agenda for our OR16 face-to-face DCAT/Devel meeting: https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-06-13+-+OR16+Meeting
[15:03] <kompewter> [ DevMtg 2016-06-13 - OR16 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-06-13+-+OR16+Meeting
[15:04] <tdonohue> Feedback is welcome, but as it was just posted, I'll ask you to send me feedback after this meeting.
[15:04] <mhwood> Thanks.
[15:05] <tdonohue> Moving along to 6.0 topics. Obviously our goal has been to try to get 6.0 out the door prior to OR16. I'm not sure that's achievable (since that'd mean 6.0 by June 10), but I would like to make sure we get a 6.0 RC2 released *prior to* OR16
[15:05] <mhwood> Good idea.
[15:06] <tdonohue> That way we can show progress, and helix84 has an RC2 to talk about in his presentation on 6.0
[15:07] <mhwood> The rate of bug reporting suggests that we cannot soon do a supported release unless we sort the bugs into "must do now" and "6.1 is soon enough." I don't like it, but I think that's reality.
[15:07] * mjmarttila_ (8da10da4@gateway/web/freenode/ip.141.161.13.164) has joined #duraspace
[15:08] <tdonohue> I agree, mhwood...which is why I suspect the better direction is RC2 now, and get a schedule for "when to expect" 6.0
[15:08] <mhwood> I think that's right.
[15:09] <tdonohue> I'm going to admit that I'm probably going to be less helpful in the timespan up to OR16, as I'm busily preparing talks (and had some pre-planned time off). So, I'm hoping others can help step things up and keep pushing 6.0 to an RC2 release. I'm still around for consultation, but I may not have time to dig into code
[15:09] <mhwood> We will need to work out how to recognize that we can cut an RC2.
[15:10] <tdonohue> In my opinion, for an RC2, we really just *need* to have the high priority PRs ready. Right now, there's just one (but it's a big one): https://github.com/DSpace/DSpace/pull/1382
[15:10] <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
[15:10] <tdonohue> *high priority PRs *merged** (not ready)
[15:10] <mhwood> Indeed.
[15:11] <tdonohue> Beyond that, an RC2 is fine to still have outstanding "known" issues. I just want a "stable" Release Candidate that we can get posted up to demo.dspace.org, and that we can show off at OR16 (and ask for more testers, etc)
[15:12] <terry-b3> Scanning the PR, I am curious what the use case is for having a bitstream in multiple bundles
[15:13] <tdonohue> So, ideally, by June 9 (one week from tomorrow), we have 1382 completed/tested/merged, we are cutting RC2, and then updating demo.dspace.org to RC2.
[15:14] <tdonohue> terry-b3: I think this is another scenario where the API / data model has always supported having bitstreams in multiple bundles... but it really isn't used in the UIs
[15:14] <tdonohue> terry-b3: so, in refactoring the old 5.x codebase, KevinVdV kept that bit of code in place, as it existed previously
[15:15] <terry-b3> thanks for the explanation.
[15:15] <tdonohue> So, regarding 1382... I just got an email from KevinVdV saying he'd miss this meeting, but he had some updates.
[15:16] <tdonohue> From KevinVdV: "
[15:16] <tdonohue> It's going to be hard for me to find time to fix this in the coming week, anybody else is free to take a stab at it."
[15:16] <tdonohue> "The problem that causes this issue is that the link between a parent & child is removed to soon (before actual deleting of children)."
[15:17] <tdonohue> "Take for example the deleting of an item: (1) Delete the link between item & collection (2) Delete bitstream (3) Authorization check is made to see if current user CAN delete bitstream"
[15:17] <tdonohue> "The authorization check on delete of bitstream will fail because an item doesn't have any more collections. So the trick is to FIRST delete the children & THEN remove links to the parents."
[15:17] <tdonohue> "I tried to this in my PR, but I missed something apparently, hopefully this intelligence will help others in resolving it."
[15:17] <tdonohue> [That's the end of his message / summary]
[15:18] <tdonohue> Is there anyone else who has time to try and take a stab at fixing up 1382 this week?
[15:18] <terry-b3> There was another PR we discussed last week that made use of an ON DELETE in the database. Is there a need to make that a recommended approach?
[15:19] <mhwood> IIRC hpottinger might have a word of caution about cascading deletes.
[15:20] <tdonohue> terry-b3: that's an interesting thought. You might be right that maybe we could lean more heavily on ON DELETE... by just concentrating on *deleting* the child object (and then ON DELETE cleans up all other connections with that child object)
[15:20] <tdonohue> mhwood: the PR was merged though...I think hpottinger just cautioned we should be sure the ON DELETE is well tested/working
[15:20] <mhwood> What is essential is that there is a transaction around this packet of deletes.
[15:22] * tdonohue is trying to find the other PR which used "on delete cascade"
[15:23] <tdonohue> Oh, wait...it was DS-3086 / DSPR#1326
[15:23] <kompewter> [ https://github.com/DSpace/DSpace/pull/1326 ] - DS-3086 OAI Harvester is broken by DylanMeeus
[15:23] <kompewter> [ https://jira.duraspace.org/browse/DS-3086 ] - [DS-3086] OAI Harvester is broken (NPEs around several classes) - DuraSpace JIRA
[15:24] <tdonohue> which used ON DELETE CASCADE to cleanup metadata values & resource policies when an Item is removed
[15:25] <tdonohue> So, it might be worth considering if a similar solution could solve DSPR#1382... which is about deleting files, etc
[15:25] <kompewter> [ https://github.com/DSpace/DSpace/pull/1382 ] - [DS-3179] Collection admin, edit item no authorization to remove file by KevinVdV
[15:26] <terry-b3> It is useful that the ON DELETE is declared in a config file rather than just packed into some inline SQL in code
[15:27] <tdonohue> terry-b3: no, the ON DELETE isn't in a config file...it's in a SQL file that is run by Flyway to setup the database. After that, the database handles the cleanup "ON DELETE"
[15:27] <terry-b3> I was considering the Flyway to be config-ish
[15:27] <mhwood> But it is DDL, not DML. I think that was the point.
[15:28] <tdonohue> true
[15:29] <tdonohue> So, what do we think about 1382? It seems like KevinVdV has identified the core problem. It's really about finding a way to either solve it via (a) code , OR (b) ON DELETE CASCADE
[15:29] <tdonohue> Is there anyone interested in creating a new PR for 1382?
[15:29] <mhwood> It's important that every time we redefine the relationships to a type having ON DELETE CASCADE, we reconsider that cascade. Which is why it is good to have it on the definition, where we ought to be looking anyway.
[15:30] <tdonohue> mhwood: true. I misunderstood what terry-b3 was noting regarding that. You are both correct
[15:32] <tdonohue> So, no one seems to be jumping at the opportunity to help out with 1382 :)
[15:33] * mhwood is trying to figure out a thorough test plan.
[15:33] <mhwood> I will see what I can do with it.
[15:33] <tdonohue> mhwood: KevinVdV has some things he recommended testing in the description of DSPR#1382. There's a checklist of delete options to perform as a Community/Collection Admin.
[15:33] <kompewter> [ https://github.com/DSpace/DSpace/pull/1382 ] - [DS-3179] Collection admin, edit item no authorization to remove file by KevinVdV
[15:34] <mhwood> That helps.
[15:34] <mhwood> I've made a note to "fix & test".
[15:34] <tdonohue> mhwood: much appreciated. It seems like the core issue is that deletions really are not working right for Community/Collection Admins, as it seems like the Resource Policy is removed *prior* to being checked for DELETE permissions
[15:35] <mhwood> Yes, that is what it sounds like to me.
[15:35] * pbecker (~anonymous@55d43b21.access.ecotel.net) has joined #duraspace
[15:35] <pbecker> hi
[15:36] <tdonohue> mhwood: thanks again. Please don't hesitate to bounce ideas around in IRC this week if you come up with other options for 1382
[15:36] <mhwood> OK.
[15:36] <mhwood> Hi pbecker.
[15:36] <tdonohue> hi pbecker. We were just strategizing around 1382 (last high priority PR before RC2)
[15:37] * roelandatmire (~roeland@85.234.195.109.static.edpnet.net) has left #duraspace
[15:37] <tdonohue> mhwood: I'll also paste KevinVdV's notes into the comments of 1382 for you
[15:37] <mhwood> Thank you.
[15:37] * pbecker (~anonymous@55d43b21.access.ecotel.net) Quit (Read error: Connection reset by peer)
[15:38] * pbecker (~anonymous@55d43b21.access.ecotel.net) has joined #duraspace
[15:38] <pbecker> hello again. ;-)
[15:38] * pbecker goes quickly through the log
[15:40] <terry-b3> On a side note, we are hoping to configure our DSpace 6 test server to do some performance testing with a large DB instance
[15:40] <terry-b3> I hope to do some of that testing before traveling to OR. If there are any hidden performance bugs, I would like to identify them.
[15:41] <tdonohue> Added notes to DSPR#1382 based on this discussion (and from KevinVdV's email). Also assigned to mhwood
[15:41] <kompewter> [ https://github.com/DSpace/DSpace/pull/1382 ] - [DS-3179] Collection admin, edit item no authorization to remove file by KevinVdV
[15:41] <pbecker> regarding 1382: DSpace uses bitstreams in multiple bundles for Item Level Versioning.
[15:42] <pbecker> We don’t want to use duplicated space for the same files in several versions.
[15:42] <tdonohue> pbecker: aha. Good to know :)
[15:42] <tdonohue> I had forgotten about that
[15:42] <pbecker> I’ll add that to the PR
[15:42] <tdonohue> pbecker: I don't think that's a big point. The true problem with the PR is that Resource Policies are being deleted too early
[15:43] <terry-b3> Do you end up with multiple bundles with the same name (such as ORIGINAL)?
[15:43] <tdonohue> the fact that we use bitstreams in multiple bundles doesn't actually seem to be a factor in this problem
[15:43] <pbecker> it is not the first time that this questions pop up. ;-)
[15:43] <pbecker> terry-b3: you have multiple items, everyone with a bundle ORIGINAL that may contain the same bitstream(s).
[15:44] <pbecker> the bundle name is equal, the bundles aren’t (e.g. different UUIDs)
[15:44] <terry-b3> Thanks for the explanation. I was not aware of that since we are not using item versions
[15:45] <tdonohue> Ok, so back to 6.0. I think it'd be good to draft out a "goal" for what we accomplish before OR16, and who is willing to help with each step
[15:46] <tdonohue> As mentioned, I think our new goal is to have a 6.0 RC2 out by end of next week (ideally on Thurs, June 9). That's dependent on 1382 (which mhwood is looking at, and we should help him test / give feedback)
[15:46] <pbecker> I can cut RC2, but I would appriciate help. Especially I would be glad if someone else could update demo.
[15:46] <tdonohue> Once 6.0 RC2 is released, we also need demo.dspace.org to be updated (as noted by pbecker)
[15:47] <tdonohue> Ideally, we have both 6.0 RC2 and demo site updated *before* OR16 (which starts Mon, June 13)
[15:48] <tdonohue> thanks pbecker for volunteering to cut RC2. I can be around to add support via IRC. But, I'll be concentrating heavily on OR16 presentations over the next week (obviously)
[15:49] <tdonohue> Anyone else willing to help get demo updated to RC2? I'm hoping that should be an easy process, since it's already running RC1, and should just need the latest code + a rebuild/redeploy
[15:51] <tdonohue> Ok, well, maybe I can find an hour to take that on at the end of next week. Or we'll look for a volunteer at next week's meeting
[15:52] <tdonohue> Are there other topics / PRs that we wish to discuss in today's meeting? We have a few minutes left, but I have to run at the top of the hour to a DSpace Steering Meeting
[15:52] <mhwood> Depending on 1382 (and other work) I might have time to help out with demo.
[15:52] <tdonohue> thanks mhwood. Appreciated
[15:52] <pbecker> Can anyone of you please give me a +1 on DSPR#1428? It changes one line and it would be great to get merged today (as it is a little addendum to DSPR#1326).
[15:52] <kompewter> [ https://github.com/DSpace/DSpace/pull/1428 ] - DS-3167: empty list of metadataformats in JSPUI by pnbecker
[15:52] <kompewter> [ https://github.com/DSpace/DSpace/pull/1326 ] - DS-3086 OAI Harvester is broken by DylanMeeus
[15:53] <pbecker> mhwood: regarding 1382, I described what I tested in the corresponding jira issue (DS-3179)
[15:53] <kompewter> [ https://jira.duraspace.org/browse/DS-3179 ] - [DS-3179] Collection admin, edit item no authorization to remove file - JSPUI Test Plan Ref COL3 - DuraSpace JIRA
[15:53] <tdonohue> pbecker: that PR doesn't look right to me. Shouldn't it be "oai.harvester.metadataformats.*"?
[15:54] <pbecker> yes, but that is added in the lines around.
[15:54] <pbecker> I don’t know why it is done this way, I just scanned and took what was left from #1385
[15:54] <tdonohue> Oh, I see. This uses an old method in ConfigurationManager which appends the "oai."
[15:55] <tdonohue> yea, it's correct. I'll +1 it
[15:55] <pbecker> thanks
[15:55] <pbecker> I haven’t tested it (didn’t had the time) but it was sooooo obvious to me and was part of another pr (1385) before.
[15:56] <tdonohue> pbecker: the config name you corrected is definitely wrong. And the new one *looks* correct
[15:56] <pbecker> thanks for aproving. can we merge this then?
[15:56] <tdonohue> yes, I'd say it's obvious
[15:56] * pbecker was thinking about merging this as obvious without reviews.
[15:56] <mhwood> Old code is clearly wrong. Obvious fix.
[15:57] <pbecker> thanks, I’ll press the buton.
[15:57] <pbecker> s/buton/button
[15:57] <kompewter> pbecker meant to say: thanks, I’ll press the button.
[15:58] <pbecker> merged.
[15:58] * pbecker (~anonymous@55d43b21.access.ecotel.net) has left #duraspace
[15:58] * pbecker (~anonymous@55d43b21.access.ecotel.net) has joined #duraspace
[15:58] <tdonohue> Ok, I'm going to need to leave (for Steering Meeting). So, I'm going to close up this meeting now. However, I'd encourage folks to hang around to discuss other PRs / tickets as needed (whether here or in #dspace). I'll be around later today as needed
[15:58] * Dylan_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[15:59] <tdonohue> Next week we'll touch base on status towards RC2. mhwood, thanks again for volunteering to help out more... and let us know if you need feedback / testing help for DSPR#1382 work
[15:59] <kompewter> [ https://github.com/DSpace/DSpace/pull/1382 ] - [DS-3179] Collection admin, edit item no authorization to remove file by KevinVdV
[15:59] <tdonohue> thanks all, bye
[15:59] <pbecker> bye
[15:59] <kompewter> bye!
[16:01] * dyelar (~dyelar@129.237.45.105) Quit (Quit: Leaving.)
[16:03] * mjmarttila_ (8da10da4@gateway/web/freenode/ip.141.161.13.164) Quit (Quit: Page closed)
[16:04] * Dylan_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 276 seconds)
[16:04] * pbecker (~anonymous@55d43b21.access.ecotel.net) Quit (Quit: pbecker)
[17:27] * tmmguimaraes (~tmg@193.137.88.100) Quit (Read error: Connection reset by peer)
[18:00] * Dylan_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[18:04] * Dylan_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 244 seconds)
[18:24] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[20:01] * Dylan_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[20:06] * Dylan_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 260 seconds)
[20:47] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) Quit (Quit: Leaving.)
[20:49] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[21:06] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:59] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) has left #duraspace
[23:59] * Dylan_ (~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.