Timestamps are in GMT/BST.
[0:41] * kshepherd2 (~kim@47.72.37.50) has joined #duraspace
[1:23] * kshepherd2 (~kim@47.72.37.50) Quit (Ping timeout: 252 seconds)
[6:36] -card.freenode.net- *** Looking up your hostname...
[6:36] -card.freenode.net- *** Checking Ident
[6:36] -card.freenode.net- *** Found your hostname
[6:36] -card.freenode.net- *** No Ident response
[6:36] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:36] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:36] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[9:25] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[11:32] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[12:23] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has joined #duraspace
[14:18] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has joined #duraspace
[18:35] * PeterDietz (~textual@162-231-20-67.lightspeed.clmboh.sbcglobal.net) has joined #duraspace
[19:01] * PeterDietz (~textual@162-231-20-67.lightspeed.clmboh.sbcglobal.net) Quit (Ping timeout: 240 seconds)
[19:03] * PeterDietz (~textual@server112.longsightgroup.com) has joined #duraspace
[20:02] <tdonohue> Hi all, it's time for our weekly DSpace Developers Meeting. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-05-28
[20:02] <kompewter> [ DevMtg 2014-05-28 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-05-28
[20:02] <tdonohue> As you'll probably note (if you've been paying attention)...the agenda hasn't changed much over the last few weeks. We don't seem to have a lot of "pressing decisions/topics" right now, especially with OR14 looming around the corner
[20:03] <PeterDietz> A small note about me @ OR14 dev meeting. I'll miss the first hour or so, due to travel itinerary. i.e. Ferry from Stockholm to Helsinki doesn't get in until 9:55a
[20:03] <tdonohue> Speaking of OR14...I've added a rough agenda to the OR14 Dev Mtg:https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-06-09+-+OR14+Meeting
[20:03] <tdonohue> PeterDietz: good to know. thanks
[20:03] <kompewter> [ DevMtg 2014-06-09 - OR14 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-06-09+-+OR14+Meeting
[20:04] <PeterDietz> I'm coming straight in from tail end of Apereo (Sakai LMS) conference in Miami FL. So instead of coming home to Columbus after Miami, I fly from Miami to Sweden.
[20:05] <tdonohue> wow..that's quite a bit of travel
[20:05] <tdonohue> The only other Note to add here... We're still looking for DSpace 5.0 Release Team members. I'll be asking around at OR14, but if anyone is interested in chipping in, let me know!
[20:06] <PeterDietz> heh. The full travel is: Columbus, Miami, Stockholm, ferry, Helsinki, Copenhagen, northern denmark, Copenhagen, Miami, Columbus. I don't get home until June 30th or so.
[20:07] <hpottinger> phew
[20:07] <tdonohue> The rest of today's meeting is really "open". But, I did want to note that we've still got 3.3 and 4.2 "looming over us"...it'd be nice to try and find a way to close those out, so we can all concentrate on 5.0
[20:07] <hpottinger> and everyone can of course clear their schedules for volunteering for the 5.0 RT :-)
[20:08] <tdonohue> So, I don't know if we want to spend time looking again at 3.3 or 4.2 releases? Or do we need to call for "more support" (to dspace-commit, and at OR14)? Seems like they are both a bit "stalled" as of yet.
[20:08] <tdonohue> hpottinger: of course!
[20:10] <hpottinger> re: 3.3. and 4.2, there are still "unresolved" tickets that are marked as fixed by those versions, correct?
[20:10] <mhwood> 3.3 has two. One is Review Needed, the other Accepted but unassigned.
[20:10] <tdonohue> Yes. But, arguably we could "reschedule" some (especially those scheduled for 4.2...as there are several tickets which are assigned but "stalled")
[20:11] <tdonohue> 3.3 tickets: https://jira.duraspace.org/browse/DS/fixforversion/11841
[20:11] <kompewter> [ DSpace: 3.3 - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS/fixforversion/11841
[20:11] <tdonohue> 4.2 tickets: https://jira.duraspace.org/browse/DS/fixforversion/11840
[20:11] <kompewter> [ DSpace: 4.2 - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS/fixforversion/11840
[20:13] <tdonohue> mhwood: regarding DS-1961. The code change looks fine. As long as it's been tested & works, I say commit it
[20:13] <kompewter> [ https://jira.duraspace.org/browse/DS-1961 ] - [DS-1961] Use HTTPS with oss.sonatype.org repository - DuraSpace JIRA
[20:13] <mhwood> Yeah, it's been there a week, and nobody has said, "waitaminute, we can't use HTTPS because...."
[20:14] <tdonohue> and the only other 3.3 scheduled ticket is DS-2013. Has a PR, but is untested.
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-2013 ] - [DS-2013] JSPUI with Oracle DB - Browse items with THUMBNAILS unimplemented - DuraSpace JIRA
[20:15] <mhwood> I should probably take that one as well. I keep an Oracle XE instance around for testing things like that.
[20:15] <tdonohue> go for it. That'd be the last barrier before a 3.3 release
[20:16] <mhwood> Got it. Writing a reminder.
[20:16] <tdonohue> And I'd rather just do a 3.3 soon to get it done. Honestly it was mostly necessary for one bug fix (the Handles with periods fix that went into 4.1)...we don't need to backport *every* fix to 3.3
[20:17] * monikam_ (~Monika_Me@monika.Princeton.EDU) has joined #duraspace
[20:17] <tdonohue> (for the record, the "Handles with periods" fix was DS-1536...that was a major bug which is one of the reasons we decided to backport in the first place)
[20:17] <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
[20:18] <mhwood> OK, I'll stop taking 3.3 fixes (after these) and get it out the door.
[20:18] <tdonohue> +1 to that
[20:19] <mhwood> It's on my reminder.
[20:20] <tdonohue> Regarding 4.2...I honestly think we should consider something similar... make a push to either "reschedule" or quickly fix anything outstanding. There's enough annoying bugs fixed in 4.2 to already probably warrant it.
[20:21] <hpottinger> +1
[20:22] <hpottinger> 2013 is also set for 4.2
[20:22] <tdonohue> Yep, it is
[20:23] <tdonohue> as is 1961
[20:23] <mhwood> Noted
[20:23] <hpottinger> and DS-1958
[20:23] <kompewter> [ https://jira.duraspace.org/browse/DS-1958 ] - [DS-1958] Discovery OutOfMemoryError when indexing Large Bitstreams - DuraSpace JIRA
[20:24] <mhwood> 1958 is closed, pulled to all 3.
[20:24] <hpottinger> awesome!
[20:26] <tdonohue> scanning now the 4.2 "unresolved" tickets.... looks like hpottinger has three (DS-1906, DS-1805, DS-1919). mhwood has three (2013, 1961, DS-1943)... many of the others seem "stalled"
[20:26] <kompewter> [ https://jira.duraspace.org/browse/DS-1906 ] - [DS-1906] Shibboleth attributes may need to be reconverted - DuraSpace JIRA
[20:26] <kompewter> [ https://jira.duraspace.org/browse/DS-1805 ] - [DS-1805] Maven filtering broken for SOLR artifact - DuraSpace JIRA
[20:26] <kompewter> [ https://jira.duraspace.org/browse/DS-1919 ] - [DS-1919] Solr Search Empty FilterQuery bug - DuraSpace JIRA
[20:27] <kompewter> [ https://jira.duraspace.org/browse/DS-1943 ] - [DS-1943] Language Selection _ Turkish Option - DuraSpace JIRA
[20:27] <tdonohue> Many of the others also possibly could be rescheduled (we've pinged helix84 on a few, with no response...and also pinged abollini on a few, with no response)
[20:31] <tdonohue> So, that's really all to say that 4.2 could be pushed out relatively quickly (though I'm guessing it might be post-OR14 at this point)... it's "mostly done"
[20:33] <mhwood> Ds-1943 was marked 4.2 only, but it really should be carried forward, so I added 5.0.
[20:34] <tdonohue> So, at this point, not sure there's much more to say about 4.2. Just would be good to close it out after OR14
[20:36] <tdonohue> The rest of this meeting is really just "Open Discussion". I had added a few questions myself which I could pose...but we can discuss whatever. My questions were:
[20:36] <tdonohue> 1) Is there anything we should try and get discussed at OR14, esp. the Dev Mtg? Any topics folks want me to bring up?
[20:37] <tdonohue> 2) Anyone have anything else they want to mention they are working on for 5.0? I'm giving the DSpace Roadmap talk at OR14...so for the only "major" features I'm mentioning as "possible for 5.0" are Mirage 2, ORCID integration, and REST API improvements (perhaps R/W)
[20:37] <PeterDietz> I think that Hardy should make another call for volunteers for the DSpace 5 RT
[20:38] <hpottinger> OK, listen up, I think some of you need to sign up to be on the DSpace 5 RT, so, like, volunteer, OK?
[20:38] <tdonohue> I could make a DSpace 5 Release Team call at the OR14 Dev Mtg....Hardy won't be in Helsinki
[20:38] <mhwood> I want to get back to work on boosting metadata support up to DSpaceObject. I haven't given up on having something for 5.0, understanding that it'll need time for folks to study and test.
[20:39] <PeterDietz> I would be excited to be a volunteer for the DSpace 5 Release Team
[20:39] <hpottinger> +1 metadata for all in 5.0
[20:39] <hpottinger> woah, wait
[20:39] <hpottinger> yay, PeterDietz!
[20:40] <mhwood> Thank you PeterDietz.
[20:40] <tdonohue> PeterDietz: cool, we'll sign you up! I'm assuming Longsight is cool with that?
[20:41] <PeterDietz> yeah, I just chatted with Sam Ottenhoff, Longsight also contributes to the Sakai project, so this is already paved path.
[20:41] <tdonohue> awesome! welcome aboard!
[20:41] <tdonohue> I'll do an additional call for volunteers at the OR14 Dev Mtg, and likely pester a few more folks at OR14. I think we still want to try and have at least 3-4 folks
[20:42] <hpottinger> yes, lots of room at the RT table
[20:43] <PeterDietz> I don't personal/Longsightly have a solid use-case for for DSpace REST (Create, Update, Delete) yet, so I don't have any guarantee's of what I'll be able to add to that in the short term.
[20:45] <mhwood> BTW there is a "tracking" PR for Ds-1582 (metadata for all) -- it's not ready to pull yet, but work to date is visible.
[20:45] <tdonohue> PeterDietz: Ok. I'll be "vague" about REST Updates...I suspect there will be some anyhow...but I'll avoid mentioning Read/Write, etc.
[20:45] <hpottinger> Anyone who wants to see the CUD put back into CRUD should chat with PeterDietz out of band
[20:46] <mhwood> Needs more chewing, eh?
[20:46] <hpottinger> probably
[20:46] <PeterDietz> I am however, very keen to try to make DSpace a much easier system for a repository manager, who doesn't have access to SSH, i.e. they should be able to do much more self-service, without having to call IT.. So, if that effort coincides with REST, then bonus.
[20:47] <hpottinger> can't wait to see what those developments look like, because that's exactly where I think the vision people say we need to go
[20:47] <tdonohue> PeterDietz ++ I think anything that went in that general direction would actually be a huge feature for 5.0 (or beyond), whether or not it has anything to do with REST
[20:48] <mhwood> A starting point would be a clear description of what belongs to a repo manager, what to the sysadmin.
[20:48] <PeterDietz> I also live and breath in a DSpace multi-site world. i.e. managing 30+ distinct configs, Messages.properties, messages.xml, themes, etc. So, figuring out where to fix things there, either in a bash script magic, or actually building some overrides. Similar to how others might need to have distinct Prod, Staging, Dev environments perhaps
[20:49] * hpottinger stage-whispers "continuous delivery"
[20:52] <tdonohue> There were 4 main "unmet" needs which bubbled up to the top of the DSpace Vision Survey results (from March) -- 3 of 4 had to do with (Admin) UI stuff.... (1) Batch Deposit from UI, (2) Enhanced Relationships between objects (e.g. Author objects), (3) Configs in Admin UI, (4) Basic Branding from Admin UI
[20:54] <PeterDietz> hmm. I would have to push back on the branding from the UI
[20:54] <tdonohue> just a point of note...that enhancing the Admin UI is of high interest to pretty much everyone
[20:54] <mhwood> Batch deposit isn't strictly administrative.
[20:54] <tdonohue> mhwood: true..that's general UI
[20:55] <tdonohue> PeterDietz: in my mind, "basic branding from Admin UI" is simply...here's a logo for my header, here's the main colors I want to use...that's it.
[20:56] <mhwood> I predict that the definition of "basic" will expand at an amazing rate....
[20:56] <tdonohue> (but, I do agree, "branding from the UI" can be a bit of a can of worms)
[20:56] <PeterDietz> I would be more interested in having a collection-db-setting that lets you choose which theme gets applied to it, stop there
[20:57] <PeterDietz> Then you can have a mysite theme, and a mysite-gallery theme
[20:57] <mhwood> Yes, the current approach works but is icky IMHO.
[20:58] <PeterDietz> I think the metadata fields which display in simple-item-view could be made configurable per collection (db setting)
[20:59] <mhwood> So if Collection had an administrative metadata field for this...?
[21:03] <hpottinger> I'd settle for configurable via some interface at all, other than manual coding
[21:03] <mhwood> As usual, just when things get interesting I have to go. Thanks, all! 'bye!
[21:03] <PeterDietz> Regarding branding from AdminUI, Mirage2 has been pretty good, to get out a very clean looking site i.e. https://dspace.smith.edu/ and https://arcticcouncil.longsight.com/ That might work, if you accept some basic 3 color scheme + logo, but for each site, we've typically had to add something extra, i.e. 2 dominant colors, the third color is less present
[21:03] <kompewter> [ DSpace Home ] - https://dspace.smith.edu/
[21:03] <kompewter> [ AC Archive Home ] - https://arcticcouncil.longsight.com/
[21:03] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:06] <tdonohue> Yep, Mirage 2 could help with some of that. Admittedly though, "Basic branding" was the lowest rated of those four....so, in order they were (1) Batch Deposit from UI, (2) Enhanced Relationships between objs, (3) Configs in AdminUI, (4) Basic Branding
[21:06] <tdonohue> Really, I was just wanting to show that the Community seems to be wanting to move more things from "backend" scripts/configs (Batch Deposit, Configs, Branding) to UI functionality, where possible
[21:07] <tdonohue> So, that's in a similar direction to what PeterDietz mentioned...wanting to avoid having people need to SSH into servers for simple stuff
[21:07] * tdonohue is noticing we're a bit over time here
[21:08] <hpottinger> it makes sense, let lets you free up a scarce resource (dev time), developers have no place in a content workflow
[21:11] <tdonohue> I planned to bring this up a bit at OR14 too, during the DevMtg. Essentially, the findings of the Survey seem to be stating this trend in general...that we've got some good tools, but the UI functionality is lacking in some areas.. So, going forward we'll want to find ways to enhance some of this in the UI, and bring more functionality up to the level of the UI
[21:12] <tdonohue> In any case, unfortunately I need to step away here shortly. So, it's probably about time to close up the meeting for today... I'll be lurking a bit, but have a few things yet to get done today
[21:13] <tdonohue> FYI...the general, high level survey analysis is up on this page: https://wiki.duraspace.org/display/DSPACE/DSpace+Product+Plan ... I'm creating some more fancy charts in slides that'll be at OR14 too..but the basic stuff is on that wiki page
[21:14] <kompewter> [ DSpace Product Plan - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Product+Plan
[21:34] * monikam_ (~Monika_Me@monika.Princeton.EDU) has left #duraspace
[22:11] * PeterDietz (~textual@server112.longsightgroup.com) Quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[22:12] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has left #duraspace
[22:17] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) Quit (Quit: Later, taterz!)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.