Timestamps are in GMT/BST.
[1:38] * dyelar (~dyelar@24.225.102.225) has joined #duraspace
[1:38] * dyelar (~dyelar@24.225.102.225) Quit (Client Quit)
[2:31] * awoods (~awoods@c-98-245-50-182.hsd1.co.comcast.net) Quit (Read error: Connection reset by peer)
[6:58] -weber.freenode.net- *** Looking up your hostname...
[6:58] -weber.freenode.net- *** Checking Ident
[6:58] -weber.freenode.net- *** Found your hostname
[6:58] -weber.freenode.net- *** No Ident response
[6:58] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:58] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:58] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:32] * peterdietz (uid52203@gateway/web/irccloud.com/x-rnyqacndrbcaqhuv) Quit (Quit: Connection closed for inactivity)
[10:19] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[10:39] * cwilper (~cwilper@54.213.30.97) has joined #duraspace
[13:23] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[13:24] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:30] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[14:25] * peterdietz (uid52203@gateway/web/irccloud.com/x-apktjsruyrjqocql) has joined #duraspace
[14:46] * awoods (~awoods@c-98-245-50-182.hsd1.co.comcast.net) has joined #duraspace
[15:52] * misilot (~misilot@p-body.lib.fit.edu) Quit (Quit: Leaving)
[16:09] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[16:15] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) Quit (Ping timeout: 264 seconds)
[16:16] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[16:52] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[17:07] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[17:07] * misilot (~misilot@p-body.lib.fit.edu) has left #duraspace
[17:25] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[17:26] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[17:30] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[17:37] * misilot (~misilot@p-body.lib.fit.edu) Quit (Read error: Connection reset by peer)
[17:50] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[19:55] <tdonohue> Our DSpace DevMtg will be starting here in about 5 mins. https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-03-02
[19:55] <kompewter> [ DevMtg 2016-03-02 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-03-02
[19:58] * misilot (~misilot@p-body.lib.fit.edu) Quit (Ping timeout: 276 seconds)
[20:01] * hpottinger (~hpottinge@mu-162038.dhcp.missouri.edu) has joined #duraspace
[20:01] <tdonohue> Hello all, welcome to our DSpace DevMtg https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-03-02
[20:01] <kompewter> [ DevMtg 2016-03-02 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-03-02
[20:01] <tdonohue> As it's been quiet in IRC today, a friendly ping for Committers (helix84, hpottinger, mhwood, peterdietz, terry-b3)
[20:02] <peterdietz> pong
[20:02] <mhwood> pong
[20:02] <terry-b3> here
[20:03] <tdonohue> So, in our agenda, I left a link to the "new UI" summary document. I really don't have anything new to add, other than to keep and eye on that doc & add feedback. The next meeting is tomorrow (Thurs) and invites have already been sent out to Committers & UI Working Group members
[20:03] <tdonohue> I'll pause here in case there are any questions on the new UI discussions though. Any questions?
[20:04] <peterdietz> I missed the last meeting, but anyone got mad skillz in SpringBoot + gradle, and refactoring an entire DSpace to fit into a one-webapp app?
[20:05] <tdonohue> peterdietz: we haven't asked that question yet, but I doubt it'd be that hard. In the last meeting though I presented a way to integrate the REST API directly into a Spring Boot UI (and share the same business logic across both)
[20:06] <tdonohue> peterdietz: my prototype has an update to show off that ability of combining REST + UI: https://github.com/tdonohue/DSpace-Spring-Boot#update---built-in-rest-api-for-item-view-only
[20:06] <kompewter> [ GitHub - tdonohue/DSpace-Spring-Boot: A DSpace 6.x Spring Boot UI prototype, using Thymeleaf and Bootstrap ] - https://github.com/tdonohue/DSpace-Spring-Boot#update---built-in-rest-api-for-item-view-only
[20:06] <hpottinger> oh, I see I missed a ping, so... erm... bonk
[20:07] <peterdietz> sweet. yeah. for whatever its worth. I like that direction
[20:07] <tdonohue> In any case though, the decision is still between two options... a Java Server Side UI (Spring Boot based), and a Javascript Server/Client side UI (where public pages would be precompiled on Server Side)
[20:07] <tdonohue> We likely will be gathering more feedback on these two options in the future, as there's a definitely split of opinions on which is "better". And we may not achieve a consensus without broader feedback
[20:08] <tdonohue> The summary of the two options is being built at https://docs.google.com/document/d/1bvJrRWEO2ZLTCLqNiaJ_KXGZKHNfXDjnqHWt_ZYGek4/edit#heading=h.36efgd4pt2n
[20:08] <kompewter> [ DSpace UI Working Group - Summary - Google Docs ] - https://docs.google.com/document/d/1bvJrRWEO2ZLTCLqNiaJ_KXGZKHNfXDjnqHWt_ZYGek4/edit#heading=h.36efgd4pt2n
[20:08] <tdonohue> In any case, I'd encourage you all to get up to speed and offer your feedback/notes.
[20:09] <tdonohue> In the essence of time though, I'm going to move along to 6.0 topics for today... but please do read over the UI discussions & provide feedback
[20:10] <tdonohue> Regarding 6.0, I kinda get the feeling that our movement has "slowed" significantly. Part of it may be my own fault (as my time is quite "split" between UI discussions & 6.0). But, I want to try to find a way to jumpstart us again to try and get a push towards a 6.0 RC1
[20:12] <mhwood> We have one feature left that clearly is going to be ready when it is ready. Work through improvements, tasks, bugs some more?
[20:12] <mhwood> I've seen a steady drizzle of tickets being closed.
[20:13] <tdonohue> sorry, distracted by a phone call momentarily. I was also wondering if we revisit improvements, or if it might be worth going at this from a different point of view, and tackling "blockers" to release
[20:14] <tdonohue> Let's go take a look at these blockers (several of which *are* actually tagged in GitHub as improvements): https://jira.duraspace.org/browse/DS-2578?jql=project%20%3D%20DS%20AND%20status%20in%20%28Received%2C%20%22More%20Details%20Needed%22%2C%20%22Volunteer%20Needed%22%2C%20%22Code%20Review%20Needed%22%2C%20Accepted%29%20AND%20priority%20%3D%20Blocker
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-2578 ] - [DS-2578] Old communities2item browse table blocks ability to delete non-empty Collections - DuraSpace JIRA
[20:14] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-2578?jql=project%20%3D%20DS%20AND%20status%20in%20%28Received%2C%20%22More%20Details%20Needed%22%2C%20%22Volunteer%20Needed%22%2C%20%22Code%20Review%20Needed%22%2C%20Accepted%29%20AND%20priority%20%3D%20Blocker
[20:14] <tdonohue> I'm going to start at the top... DS-3086
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-3086 ] - [DS-3086] OAI Harvester is broken (NPEs around several classes) - DuraSpace JIRA
[20:15] <mhwood> Assigned to helix84
[20:15] <tdonohue> looks like helix84 has claimed this. The PR (DSPR#1326) looks good to me, and I can add my +1 here
[20:15] <kompewter> [ https://github.com/DSpace/DSpace/pull/1326 ] - DS-3086 OAI Harvester is broken (NPEs around several classes) by DylanMeeus
[20:16] <tdonohue> moving along, DS-3062
[20:16] <mhwood> Seems to be in progress, but moving along smartly.
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-3062 ] - [DS-3062] Configurable (XML)Workflow cannot be enabled - DuraSpace JIRA
[20:17] <tdonohue> KevinVdV has a PR here DSPR#1313 that needs another +1 to move along
[20:17] <kompewter> [ https://github.com/DSpace/DSpace/pull/1313 ] - [DS-3062] Fixing issues that prevented the xmlworkflow from being enabled by KevinVdV
[20:18] <tdonohue> if someone could take a look at 1313 or give it a quick test, it'd be appreciated
[20:18] * aschweer (~andrea@schweer.its.waikato.ac.nz) has joined #duraspace
[20:18] <tdonohue> (Otherwise, I'll give it another quick test and likely merge anyways, as soon as I can get to it)
[20:19] <tdonohue> moving along, DS-3004 / DSPR#1322
[20:19] <kompewter> [ https://jira.duraspace.org/browse/DS-3004 ] - [DS-3004] extremely slow searching when logged in as admin - DuraSpace JIRA
[20:19] <kompewter> [ https://github.com/DSpace/DSpace/pull/1322 ] - Feature/DS-3004 isAdmin performance problems by tomdesair
[20:20] <tdonohue> This actually reverts some "Metadata4All" changes and puts the Group "name" back in the "group" table, so that it can be easily indexed, etc
[20:21] <mhwood> I didn't like that but it seems necessary.
[20:21] <hpottinger> I've been trying to stand up an instance on our staging server so I can test 1322
[20:21] <tdonohue> Anyone willing to give this a run though?
[20:21] <mhwood> The analysis is quite good.
[20:21] <tdonohue> mhwood: yes, I didn't have any other good options, and it seems like they did a thorough analysis of other possible solutions
[20:21] <hpottinger> been distracted by other things, though...
[20:21] <tdonohue> hpottinger any ideas when / if you'd get to this?
[20:22] <hpottinger> tdonohue: maybe a day?
[20:23] <tdonohue> ok, just trying to get a timeline here. I'll assign this PR to you then, if you think you'll get to it soon
[20:23] <hpottinger> works for me
[20:23] <mhwood> I read through it and found nothing worrisome.
[20:23] <tdonohue> done. thanks hpottinger
[20:24] <tdonohue> next up, DS-2981 (needs volunteer & PR)
[20:24] <kompewter> [ https://jira.duraspace.org/browse/DS-2981 ] - [DS-2981] Create indexes for UUID fields for Oracle migration script - DuraSpace JIRA
[20:25] <terry-b3> I presume DSpace 6 would be unusable with Oracle without this change
[20:25] <tdonohue> Anyone interested in helping create some indexes for Oracle?
[20:25] <hpottinger> oh... heh... 2981 might impact when I can get to 1322
[20:25] <tdonohue> It shouldn't be *hard* if you have an Oracle setup...just need to "mimic" DS-2844 fixes (which were for Postgres)
[20:25] <kompewter> [ https://jira.duraspace.org/browse/DS-2844 ] - [DS-2844] DSpace 6 performance after migrating a large database (250,000 items) - DuraSpace JIRA
[20:27] <tdonohue> hpottinger: was that a volunteer for 2981? Should we assign it to you? It's just a matter of taking DSPR#1140 and doing the same thing for the corresponding Oracle migrations
[20:27] <kompewter> [ https://github.com/DSpace/DSpace/pull/1140 ] - [DS-2844] Create index for all UUID fields and metadatavalue by terrywbrady
[20:28] <tdonohue> ok, well, this is needed. I guess we'll move along for now. I added a comment to 2981 linking up the PR 1140
[20:29] <tdonohue> DS-2940
[20:29] <kompewter> [ https://jira.duraspace.org/browse/DS-2940 ] - [DS-2940] Metadata problems with the VersionedHandleIdentifierProvider - DuraSpace JIRA
[20:29] <hpottinger> sorry, yeah, scribbling notes
[20:29] <hpottinger> assign 2981 to me
[20:29] <tdonohue> hpottinger: done and thanks
[20:30] <hpottinger> and that'll be the last thing I volunteer for today, I promise
[20:30] * hpottinger takes two huge steps back
[20:31] <tdonohue> huh, pbecker isn't here today, and the PR for 2940 is marked as "needs discussion" (DSPR#881)
[20:31] <kompewter> [ https://github.com/DSpace/DSpace/pull/881 ] - DS-1348: Removes "canonical" handle for versioned Items. by pnbecker
[20:32] <mhwood> The person who added the label is not here either, alas.
[20:32] <tdonohue> I added a comment to 2940 to ask about the status. We'll move along
[20:32] <tdonohue> DS-2914
[20:32] <kompewter> [ https://jira.duraspace.org/browse/DS-2914 ] - [DS-2914] Community filiator script broken on master - DuraSpace JIRA
[20:32] <tdonohue> DSPR#1188
[20:32] <kompewter> [ https://github.com/DSpace/DSpace/pull/1188 ] - [DS-2914] Community filiator script fix by KevinVdV
[20:33] <tdonohue> Oh, this was one I noticed Travis complaining about yesterday. I think it needs a rebase...but the code itself is tiny/simple
[20:33] <mhwood> Travis seems happy today.
[20:33] <tdonohue> oh, and so it does :)
[20:34] <tdonohue> Ok, well, in that case, this seems like an obvious win to me. Any objections to merging?
[20:34] <mhwood> No objection. Looks sensible.
[20:34] <tdonohue> ok, I'm merging then
[20:35] <tdonohue> done
[20:35] <tdonohue> next up, DS-2898
[20:35] <kompewter> [ https://jira.duraspace.org/browse/DS-2898 ] - [DS-2898] REST API Should Support all DSpace Authentication Methods - DuraSpace JIRA
[20:35] <tdonohue> where does this now sit, terry-b3?
[20:36] <terry-b3> I have updated the status a couple times to indicate that I am stuck on this.
[20:36] <terry-b3> I have offered to do a web meeting to show what I see.
[20:37] <terry-b3> I have not heard anything else from Kevin.
[20:37] <mhwood> I started to test password, read old documentation, got confused, wandered off to other work. I will try it again.
[20:37] <terry-b3> I suspect he is skeptical of how I have tested the issue.
[20:38] <terry-b3> I think we need someone to reproduce the issue.
[20:38] <terry-b3> If the PR helps with the other authn methods, perhaps we merge it and then fix Shib
[20:38] <tdonohue> Ok. I wish I had time to concentrate more on this right now. For the time being though, it does sound like we need more testers. As suggested in comments, we also could merge this and log outstanding Shibb-specific issues as separate tickets (assuming it works for other AuthN)
[20:39] <tdonohue> terry-b3: in your testing, are you using the JSESSIONID (as recommended by KevinVdV), or are you still using the outdated "rest-dspace-token" header?
[20:39] <mhwood> That we could. It's better than before.
[20:39] <terry-b3> Yes. In my latest comment I indicated my attempts to use it.
[20:40] <tdonohue> ok, I see
[20:40] <terry-b3> The problem is that my shibb auth fails without adding an apache rule to force shibb auth.
[20:40] <tdonohue> Ok, in any case, if *other* AuthN methods work, perhaps we do merge this, and then open tickets specific to Shibb
[20:41] <tdonohue> (and we can still try to solve all the Shibb tickets prior to 6.0, but it may help us get movement forward here)
[20:41] <terry-b3> Hopefully we can identify folks to work on the Shibb piece.
[20:41] * hpottinger waves from the back of the room
[20:41] <mhwood> Merging would cause *everybody* who uses REST to test the new code. :-)
[20:42] <tdonohue> With the Shibb piece, we could try pointing it at http://testshib.org as well. (I just haven't had a chance to try it out)
[20:42] <kompewter> [ TestShib/Home ] - http://testshib.org
[20:42] <terry-b3> There was some other discussion / concern about which header to use (for consistency). I presume we would address that as a Shibb issue.
[20:43] <tdonohue> terry-b3: I don't know that I'm up to date on that discussion, so we may need to call it out, if it should affect our decision to merge now or wait
[20:44] <terry-b3> I am trying to find it. I thought I remembered helix84 raising a concern
[20:45] <tdonohue> ok, if you find it, perhaps add a comment to that ticket? I'm not seeing helix84's name on any comments on that ticket yet
[20:45] <terry-b3> Perhaps it was in an irc conversation
[20:46] <terry-b3> I can't find it either
[20:46] <terry-b3> I don't want to create an unnecessary hold up on something that is stuck
[20:46] <tdonohue> I'm going to move along here in the essence of time...But, hopefully others can help test parts of 2898 soon, and that can provide us with sufficient feedback here
[20:47] <tdonohue> Next up, DS-2855
[20:47] <kompewter> [ https://jira.duraspace.org/browse/DS-2855 ] - [DS-2855] SolrLoggerServiceImpl hangs during startup - DuraSpace JIRA
[20:47] <tdonohue> This was actually "fixed" a long time back (by a merged PR)...and I'm not sure why we still have it opened
[20:48] <tdonohue> Are we waiting on followup code to do a "ping()" against Solr?
[20:48] <mhwood> I think we're waiting for someone to explain why we would want to.
[20:49] <tdonohue> True. I think I'm leaning towards just closing this as "fixed". I'm not sure there's anything else to "fix" here, and if so, we can create a new ticket
[20:49] <mhwood> If it causes a problem that we haven't seen yet, we can fix that later.
[20:50] <tdonohue> +1
[20:51] <tdonohue> closed & added a comment to ask for a new ticket if we want to do a "ping()"
[20:51] <tdonohue> next up, DS-2846
[20:51] <kompewter> [ https://jira.duraspace.org/browse/DS-2846 ] - [DS-2846] DSpace 6 performance issue running index-discovery -b - DuraSpace JIRA
[20:52] <tdonohue> Looks like terry-b3 just added comments to this that it seems fixed already
[20:52] <tdonohue> Although there also is a PR#1131 which claims to "optimize" further
[20:53] <terry-b3> I kicked off a re-index to confirm that this solved the issue. (I probably tested this before, but I did not document it)
[20:54] <tdonohue> So, terry-b3: just to clarify... 2846 is already fixed on master?
[20:54] <tdonohue> (Just want to be certain that DSPR#1131 is unnecessary)
[20:54] <kompewter> [ https://github.com/DSpace/DSpace/pull/1131 ] - [DS-2846] Optimize memory usage when using iterators by KevinVdV
[20:54] <terry-b3> I missed that question. I cannot yet verify 1131
[20:54] <mhwood> 1131 seems to be a related but separate issue?
[20:55] <terry-b3> You can assign it to me to test. Sorry I overlooked the question.
[20:55] <tdonohue> ok, will assign the PR to you, thanks terry-b3
[20:56] <tdonohue> Ok, moving along DS-2687
[20:56] <kompewter> [ https://jira.duraspace.org/browse/DS-2687 ] - [DS-2687] When deleting a collection role, the administrator group (id 1) was deleted - DuraSpace JIRA
[20:57] <tdonohue> This one has been "fixed" on master...but the flaws noted in FlowContainerUtils need resolution
[20:58] * hpottinger (~hpottinge@mu-162038.dhcp.missouri.edu) Quit (Read error: Connection reset by peer)
[20:58] <tdonohue> I'm not sure it's actually a "blocker" anymore? It seems like this is more a backport question...whether we work to backport a better fix to 5.x
[20:59] * hpottinger (~hpottinge@mu-162038.dhcp.missouri.edu) has joined #duraspace
[20:59] <mhwood> Well, the specific complaint (I destroyed Administrator!) is prevented, but we have a wider issue that perhaps should be a separate ticket.
[20:59] <tdonohue> It could also be that we need to just find someone to retest 2687 on master to see what happens now
[21:00] <mhwood> You can still destroy non-builtin groups this way, until FlowContainerUtils is reworked.
[21:00] <tdonohue> True
[21:00] <mhwood> So it's not a blocker, but still serious.
[21:00] <tdonohue> You just couldn't destroy Administrator or Anonymous groups
[21:00] * aschweer (~andrea@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[21:01] <mhwood> So long as you have an admin. account, you can repair the damage without delving into database tables.
[21:01] <tdonohue> Any volunteers to dig into 2687 further?
[21:02] <hpottinger> I "fixed" this on our repository by simply removing the code that deletes groups as part of a role delete
[21:04] <hpottinger> accidental group deletion based on a common admin action, and relying on admins to pick up the pieces... is a little scary
[21:04] <tdonohue> Ok, well, perhaps we leave this open for now. Maybe I'll get to it at some point. At least now, it's *not* a blocker (on master)
[21:04] <hpottinger> I know I said I wouldn't volunteer for anything else, but I'll see if 2687 still exists on master, if it is, I'd say it's a blocker
[21:05] <tdonohue> hpottinger: it shouldn't still exist on master...or at least you cannot auto-delete the Administrator and Anonymous groups...but other custom groups might still be auto-deleted
[21:06] <tdonohue> Still, thanks for being willing to test it, hpottinger
[21:06] <tdonohue> two more tickets here.. I'm going to push through these
[21:06] <hpottinger> tdonohue: deletion of any non-system-created group is not OK
[21:06] <tdonohue> DS-2615
[21:06] <kompewter> [ https://jira.duraspace.org/browse/DS-2615 ] - [DS-2615] Additions module does not work on Glassfish + Linux - DuraSpace JIRA
[21:07] <tdonohue> hpottinger: not saying it is...it's still a *bug* yes, but it's a difficult one to achieve, and may not be a blocker
[21:07] <tdonohue> 2615 is a blocker cause it means we cannot run DSpace on Tomcat 8... it's actually better described at DS-2437
[21:07] <kompewter> [ https://jira.duraspace.org/browse/DS-2437 ] - [DS-2437] Stop relying on alphabetical loading of jars in WEB-INF/lib - DuraSpace JIRA
[21:08] <tdonohue> (in fact, I might make 2437 the "blocker" here)
[21:09] <mhwood> Well, you can't run DSpace on Tomcat 8 *if* you use overlays. Which is bad enough.
[21:09] <tdonohue> mhwood: right, that's probably the better way of putting it. Still though, we won't have full Tomcat 8 support
[21:09] <hpottinger> what are the rules on "blocker" status? I have pretty strong feelings about 2687 based on the amount of work I'm *still* having to do to undo the damage for our repository
[21:12] <tdonohue> hpottinger: then fix 2687 :) It just needs a volunteer, and it probably wouldn't be too hard to fix. To be honest, I agree, it's still significant. "Blocker" status though is a massive failure in DSpace (i.e. DSpace just doesn't work)...whereas, I kinda think 2687 falls more under "Critical" or "Major". It's still something to fix for 6.0, but it shouldn't *block* us releasing RC1
[21:12] <terry-b3> We have lived with the issue for such a long time that I do not consider it a blocker.
[21:13] <tdonohue> with 2437, this is something I keep hoping to find time to look into.
[21:13] <tdonohue> I think it's a blocker as we kinda have to support Tomcat 8 fully (we cannot keep people on Tomcat 7 forever)
[21:14] <tdonohue> but, I'll try to find time myself for 2437
[21:14] <tdonohue> one last one for today... DS-2490
[21:14] <kompewter> [ https://jira.duraspace.org/browse/DS-2490 ] - [DS-2490] Add DOI support to Item Level Versioning - DuraSpace JIRA
[21:14] <terry-b3> Sorry, I was commenting on an old issue.
[21:15] <tdonohue> 2490 has a DSPR#879
[21:15] <kompewter> [ https://github.com/DSpace/DSpace/pull/879 ] - DS-2490: adds org.dspace.identifier.VersionedDOIIdentifierProvider by pnbecker
[21:15] <mhwood> Interesting: a Blocker Improvement. :-)
[21:15] <tdonohue> Looks like this one needs a rebase
[21:16] <tdonohue> I'm not sure it's actually a "blocker" here...but pbecker says he assigned it as such cause it's just fully broken on master
[21:17] <mhwood> It seems this should be two issues with two PRs: fix Services damage, and add versioning support.
[21:17] <tdonohue> I pinged pbecker here in the PR
[21:17] <hpottinger> :-) sorry, distracted, re fixing 2687, I've fixed it locally by just removing the code that deletes groups from the code that deletes roles, I can always do the same for future releases if my work load continues the way it has
[21:17] <tdonohue> +1 mhwood. I agree..it's only *part* of this that is a blocker (the fixing damage)
[21:18] <mhwood> hpottinger: that just breaks it in a less destructive fashion. :-)
[21:18] <hpottinger> I can live with orphan groups
[21:18] <tdonohue> hpottinger: why not just fix the bug that is 2687 in DSpace? I'm not saying we *shouldn't* fix it. I just was noting that it's no longer seemingly "blocker" status...but it's still a significant issue that I'd like someone to fix :)
[21:19] <mhwood> We need a flag (field, metadata, whatever) on Groups to indicate "DSpace created this group." Then things get easier.
[21:19] <hpottinger> my plate is pretty full, some of it is taken up with fixing the damage caused by the deletion of a group used in many access policies
[21:19] <tdonohue> It seems like the *correct* logic should be: If the group is a Collection/Community group, first remove all it's members...then delete the (now empty) Collection/Community group. If the group is NOT a Collection/Community group, do nothing.
[21:20] <hpottinger> without a flag, it could be inferred by group name
[21:20] <mhwood> The tricky part is "if this is a Collection/Community group". AIP already had some fun with that, IIRC.
[21:21] <hpottinger> so... I'll assign 2687 to me and I'll fix it
[21:22] <tdonohue> thanks hpottinger. I added my notes on the correct logic as a comment on DS-2687
[21:22] <kompewter> [ https://jira.duraspace.org/browse/DS-2687 ] - [DS-2687] When deleting a collection role, the administrator group (id 1) was deleted - DuraSpace JIRA
[21:23] <tdonohue> Ok, that's our full list of Blockers. Thanks for sticking this out today
[21:24] <tdonohue> Sorry for going so far over time. I think we just need to continue chipping away at these major issues & improvements. Again, I'd encourage everyone to ping me offline to do code reviews (as needed). I'll also try and test & chip in as much as I can (time permitting) and encourage you all to do the same.
[21:25] <mhwood> Quick question before everybody scatters: should rest/status return <authenticated>false</authenticated> if I get a JSESSIONID from rest/login and supply it in the status call?
[21:25] <tdonohue> I do feel glad that most of these "blockers" seem to have a good plan in place (some need more testing though). We also need to keep pushing at improvements, code tasks and other bugs. There's no *lack* of things to test, so if you find yourselves with extra time, please chip in
[21:26] <tdonohue> mhwood: good question, I don't know off the top of my head...maybe terry-b3 or peterdietz know?
[21:27] <mhwood> I do actually get the status document. The HTTP status code is 200.
[21:28] <mhwood> Hmm. I also get that result if I *don't* send the cookie.
[21:28] <mhwood> Maybe /status is the wrong way to test authentication.
[21:31] <tdonohue> Ok, well, if it isn't obvious, I'd say the official meeting is "closed". I gotta step away for a bit, but will be back shortly...we can always move this over to #dspace as needed
[21:33] * hpottinger (~hpottinge@mu-162038.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[21:44] <mhwood> Point of ettiquette: I've been editing the initial comment on someone else's PR (because Markdown hashed it). Should I add a comment to that effect, or would that just be noise?
[21:48] <mhwood> Re: REST question: I must've done something wrong. I tried again and it worked as expected.
[21:50] <terry-b3> mhwood, I have run into issues where status returns authenticated but the user name is blank
[21:57] * roeland_atmire (~roeland_a@d54C02199.access.telenet.be) has joined #duraspace
[22:02] <mhwood> BTW I've been testing DSpace 6 with Tomcat 8 (but not using overlays). Works well....
[22:03] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:18] * roeland_atmire (~roeland_a@d54C02199.access.telenet.be) Quit (Quit: roeland_atmire)
[23:00] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[23:02] * roeland_atmire (~roeland_a@d54C02199.access.telenet.be) has joined #duraspace
[23:49] * roeland_atmire (~roeland_a@d54C02199.access.telenet.be) Quit (Quit: roeland_atmire)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.