Timestamps are in GMT/BST.
[1:39] * lyncodev (027d6e11@gateway/web/cgi-irc/kiwiirc.com/ip.2.125.110.17) Quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
[2:09] * lyncodev (027d6e11@gateway/web/cgi-irc/kiwiirc.com/ip.2.125.110.17) has joined #duraspace
[2:10] * lyncodev (027d6e11@gateway/web/cgi-irc/kiwiirc.com/ip.2.125.110.17) Quit (Client Quit)
[3:09] * lyncodev (027d6e11@gateway/web/cgi-irc/kiwiirc.com/ip.2.125.110.17) has joined #duraspace
[3:10] * lyncodev (027d6e11@gateway/web/cgi-irc/kiwiirc.com/ip.2.125.110.17) Quit (Client Quit)
[4:10] * lyncodev (027d6e11@gateway/web/cgi-irc/kiwiirc.com/ip.2.125.110.17) has joined #duraspace
[4:11] * lyncodev (027d6e11@gateway/web/cgi-irc/kiwiirc.com/ip.2.125.110.17) Quit (Client Quit)
[5:10] * lyncodev (027d6e11@gateway/web/cgi-irc/kiwiirc.com/ip.2.125.110.17) has joined #duraspace
[5:12] * lyncodev (027d6e11@gateway/web/cgi-irc/kiwiirc.com/ip.2.125.110.17) Quit (Client Quit)
[6:11] * lyncodev (027d6e11@gateway/web/cgi-irc/kiwiirc.com/ip.2.125.110.17) has joined #duraspace
[6:12] * lyncodev (027d6e11@gateway/web/cgi-irc/kiwiirc.com/ip.2.125.110.17) Quit (Client Quit)
[6:53] * kshepherd (~kim@ec2-184-73-177-234.compute-1.amazonaws.com) Quit (Remote host closed the connection)
[6:54] -holmes.freenode.net- *** Looking up your hostname...
[6:54] -holmes.freenode.net- *** Checking Ident
[6:54] -holmes.freenode.net- *** Found your hostname
[6:54] -holmes.freenode.net- *** No Ident response
[6:54] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:54] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:54] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:31] * Eike|2 (~kvirc@srv-clst-301-data4.zhaw.ch) has joined #duraspace
[8:42] * Eike|2 (~kvirc@srv-clst-301-data4.zhaw.ch) has left #duraspace
[9:11] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Ping timeout: 276 seconds)
[9:26] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) has joined #duraspace
[9:27] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) Quit (Client Quit)
[9:30] * kostasp (5e44f33c@gateway/web/freenode/ip.94.68.243.60) has joined #duraspace
[9:46] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) has joined #duraspace
[10:39] * kostasp (5e44f33c@gateway/web/freenode/ip.94.68.243.60) Quit (Ping timeout: 246 seconds)
[11:00] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) Quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
[11:05] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[11:39] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) has joined #duraspace
[11:49] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) has left #duraspace
[11:49] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) has joined #duraspace
[14:08] * robint (81d7fa56@gateway/web/freenode/ip.129.215.250.86) has joined #duraspace
[14:08] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has joined #duraspace
[14:45] * KevinVdV_ (~kevin@85.234.195.109.static.edpnet.net) has joined #duraspace
[14:46] * hpottinger (~hpottinge@mu-162188.dhcp.missouri.edu) has joined #duraspace
[15:00] <hpottinger> hey, looky there, it's 15UTC
[15:00] <tdonohue> Hi all, it's 15:00UTC, which means it's time for our weekly DSpace Dev Mtg. Agenda for today at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-01-28
[15:00] <kompewter> [ DevMtg 2015-01-28 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-01-28
[15:01] <tdonohue> First and foremost, I figured it might be good to chat about 5.1 (or any recent bugs/issues found in 5.0). Seems like we've stumbled on a few issues that might need some fixing in the nearish future
[15:02] <hpottinger> 5.1++
[15:02] <tdonohue> One just discovered yesterday, for example: DS-2427 which "breaks" DSpace 5 (possibly earlier versions) if you have two DSpace DBs in different schemas in Oracle
[15:02] <kompewter> [ https://jira.duraspace.org/browse/DS-2427 ] - [DS-2427] DSpace API does not always filter results by the DB schema of current connection - DuraSpace JIRA
[15:03] * srobbins (~Adium@mobile-130-126-255-147.near.illinois.edu) has joined #duraspace
[15:04] <tdonohue> I also notice some other bugs/issues have come in recently which need some more attention, and possibly would be worth including in a 5.1 release
[15:05] <tdonohue> a few others include, LDAP auto-registration issues (DS-2421 -- needs someone to help out), Mirage 2 build issues (DS-2428)
[15:05] <kompewter> [ https://jira.duraspace.org/browse/DS-2421 ] - [DS-2421] LDAPAuthentication Plugin only supports auto-registration for Hierarchical LDAP settings - DuraSpace JIRA
[15:05] <kompewter> [ https://jira.duraspace.org/browse/DS-2428 ] - [DS-2428] Mirage 2 build problem - timeout error - DuraSpace JIRA
[15:06] <hpottinger> tdonohue: maybe we should do a quick roll-call? I'm wondering who might be at their keyboards right now?
[15:06] <tdonohue> pinging helix84, KevinVdV_, lyncodev, robint....just curious which Committers are in the mtg ;)
[15:07] <tdonohue> also pbecker :)
[15:07] <KevinVdV_> Present !
[15:07] <robint> Hi tdonohue, just finishing something, back in 5 mins
[15:08] <tdonohue> So, for those present, any other issues you are aware of that we should aim for a 5.1 release?
[15:09] <tdonohue> Also, anyone around (Committer or non-Committer) who is willing to help investigate or find a fix for DS-2421 (reading the code, it looks like a bug to me, but I don't have an LDAP to test against)
[15:09] <kompewter> [ https://jira.duraspace.org/browse/DS-2421 ] - [DS-2421] LDAPAuthentication Plugin only supports auto-registration for Hierarchical LDAP settings - DuraSpace JIRA
[15:10] <KevinVdV_> Is there a list somewhere from all issues with 5.0 ? Might make things easier
[15:10] <hpottinger> DS-22201
[15:10] <kompewter> [ https://jira.duraspace.org/browse/DS-22201 ] - Issue Navigator - DuraSpace JIRA
[15:10] <hpottinger> whoops, DS-2201
[15:10] <kompewter> [ https://jira.duraspace.org/browse/DS-2201 ] - [DS-2201] Unable to complete installation of DSpace with non-empty variable "db.schema" configuration file "build.properties" - DuraSpace JIRA
[15:11] <hpottinger> how is it that we still have a blocker?
[15:11] <hpottinger> DS-2131
[15:11] <kompewter> [ https://jira.duraspace.org/browse/DS-2131 ] - [DS-2131] SWORDv2 ingestion fails with NullPointerException - DuraSpace JIRA
[15:12] <tdonohue> KevinVdV_ the list of open issues with "5.0" as an "affected version" is actually a bit long (as includes some longstanding issues / things in discussion)
[15:13] <tdonohue> But, here's the 50 open bug tickets tagged "affecting 5.0": https://jira.duraspace.org/issues/?jql=project%20%3D%20DS%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20%3D%205.0%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
[15:13] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/issues/?jql=project%20%3D%20DS%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20%3D%205.0%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
[15:14] <tdonohue> 2131 does sound like something to quickly resolve...thanks hpottinger
[15:15] <tdonohue> I've updated 2131 as "critical" and marked fix for 5.1
[15:15] <hpottinger> I tagged it as low hanging fruit, too
[15:17] <tdonohue> Here's everything currently flagged as "fix for 5.1": https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+fixVersion+%3D+5.1+AND+resolution+%3D+Unresolved+ORDER+BY+due+ASC%2C+priority+DESC%2C+created+ASC&mode=hide
[15:17] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+fixVersion+%3D+5.1+AND+resolution+%3D+Unresolved+ORDER+BY+due+ASC%2C+priority+DESC%2C+created+ASC&mode=hide
[15:17] <KevinVdV_> I think I got a fix for 2131
[15:17] <KevinVdV_> Hold on
[15:18] <tdonohue> KevinVdV_ : feel free to claim it & submit a PR then, please
[15:18] <hpottinger> PRs much appreciated, thanks ;-)
[15:19] <tdonohue> So, I guess the big question here is twofold:
[15:19] <tdonohue> (1) Are there any bugs you are aware of that we should get an *immediate* fix to (i.e. means we should release a 5.1 ASAP)?
[15:20] <hpottinger> DS-2427
[15:20] <kompewter> [ https://jira.duraspace.org/browse/DS-2427 ] - [DS-2427] DSpace API does not always filter results by the DB schema of current connection - DuraSpace JIRA
[15:20] <tdonohue> (2) Also, it'd be really helpful for folks to help by claiming / volunteering for anything marked "fix for 5.1". There's a lot there, and we'll need more volunteers to get most of these into 5.1
[15:21] * srobbins (~Adium@mobile-130-126-255-147.near.illinois.edu) Quit (Quit: Leaving.)
[15:21] * srobbins (~Adium@mobile-130-126-255-147.near.illinois.edu) has joined #duraspace
[15:21] <tdonohue> 2427 does seem like a major bug...and it should be an easy fix (but will require a lot of help testing it, as it's a fix in the *DatabaseManager*, and that shouldn't be taken lightly)
[15:21] <hpottinger> DS-22011, DS-2427, DS-2218 all kind of fit together
[15:22] <kompewter> [ https://jira.duraspace.org/browse/DS-22011 ] - Issue Navigator - DuraSpace JIRA
[15:22] <kompewter> [ https://jira.duraspace.org/browse/DS-2427 ] - [DS-2427] DSpace API does not always filter results by the DB schema of current connection - DuraSpace JIRA
[15:22] <kompewter> [ https://jira.duraspace.org/browse/DS-2218 ] - [DS-2218] Unable to use command "update-handle-prefix" - DuraSpace JIRA
[15:23] <tdonohue> I can probably claim 2427 & create a PR (but will need help testing it).... 2201 has a PR (which should just be merged)... 2218 also has a PR (which needs testing)
[15:24] <hpottinger> count me in for testing
[15:24] <tdonohue> hpottinger: well, you can already test 2218, if you have time. I'll get a 2427 PR done (hopefully today)
[15:24] <tdonohue> hpottinger: and technically, yesterday you tested 2201's PR. You should probably just merge it, as you verified the problem/fix
[15:25] <hpottinger> on it
[15:25] <tdonohue> thanks!
[15:25] <tdonohue> any other bugs folks want to highlight as "must fix" soon?
[15:26] <tdonohue> I'll again mention DS-2421, just cause now ~3 different people have hit the same exact problem on dspace-tech and IRC in the last 1-2 weeks. There's a definite issue here, but it needs a volunteer who has an LDAP handy
[15:26] <kompewter> [ https://jira.duraspace.org/browse/DS-2421 ] - [DS-2421] LDAPAuthentication Plugin only supports auto-registration for Hierarchical LDAP settings - DuraSpace JIRA
[15:27] <hpottinger> should we revert DSPR#721?
[15:27] <kompewter> [ https://github.com/DSpace/DSpace/pull/721 ] - [DS-2201] added config advice to warn oracle users against using schema by hardyoyo
[15:28] <tdonohue> hpottinger: we may want to *correct* that comment about Oracle, yes. Probably should have some explanation about how "db.schema" *can* be used with Oracle
[15:28] <tdonohue> hpottinger: so, maybe a new PR to fix the language
[15:28] <hpottinger> I can, or maybe we can fit it into your PR for DS-2427?
[15:28] <kompewter> [ https://jira.duraspace.org/browse/DS-2427 ] - [DS-2427] DSpace API does not always filter results by the DB schema of current connection - DuraSpace JIRA
[15:29] <tdonohue> I can fit it into 2427, that's fine
[15:29] <hpottinger> I'll help with the wording, if necessary
[15:29] * tdonohue notes its really quiet here today...seems as most folks are quite distracted or busy :)
[15:30] <lyncodev> Just watching really, at work.
[15:31] <tdonohue> Oh hi, lyncodev... if there's anything you feel would be ready to fix in the JSPUI for 5.1, let us know. I recall recently you had volunteered for a few JSPUI bugs (which were sitting around unclaimed)
[15:31] <lyncodev> Yes, 2 to be precise
[15:32] <tdonohue> I couldn't remember how many...but I knew it was more than one ;)
[15:32] <lyncodev> I am facing some technical challenges to deploy dspace locally in the last weeks
[15:33] <hpottinger> DSPR#712 merged, I will cherry-pick and push 3d61404 to the 5_x branch
[15:33] <kompewter> [ https://github.com/DSpace/DSpace/pull/712 ] - DS-2201: Unable to complete installation of DSpace with non-empty variable "db.schema" configuration file "build.properties" by ctu-developers
[15:33] <lyncodev> Hope to get that fixed quickly and give some feedback
[15:33] <tdonohue> In any case, regarding 5.1, I'd encourage us all to start getting bugs fixed & reviewing PRs to push to "dspace-5_x" branch. Personally, it does seem like we may want to push out a 5.1 in the next few weeks or so, especially to fix the schema issues related to Oracle
[15:33] <tdonohue> lyncodev: sounds good
[15:34] <tdonohue> Since we are a small group here, it seems like there's likely not much more to discuss around 5.0 or 5.1. But, I'll pause for a moment in case anyone has any last things to mention with it
[15:34] <hpottinger> well, just so people know, the issue with 2427 does have a configuration workaround
[15:35] <tdonohue> hpottinger: yea, I'd be pushing for an *immediate* 5.1, if 2427 didn't have a workaround. Luckily it does
[15:35] <hpottinger> and you *can* always just not have more than one schema :-)
[15:36] <hpottinger> so, we have a general idea of "soon" do we have enough info to pick a date?
[15:36] <tdonohue> Ok, not hearing anything else specific to DSpace 5 right now...but, please, if anyone (Committer or non-Committer) wants to claim one of these tickets (or any bug ticket really) and send us a PR, we'll try to get it into 5.1! Thanks!
[15:37] <hpottinger> yes, it's bug fix season, go fix some bugs
[15:37] <tdonohue> hpottinger: it might be best to get 2427 fixed first. I *think* it's easy, but will take time to test. Right now I'd just say, a 5.1 might be good to release by mid-to-late February
[15:37] <tdonohue> (i.e. 2-4 weeks from now)
[15:38] <hpottinger> let's aim for late Feb, I'll be out in the middle of Feb
[15:38] <tdonohue> Sounds reasonable, honestly. Just want to be sure we keep chugging away at these bugs and getting them fixed on dspace-5_x
[15:39] <tdonohue> Ok, moving along now from 5 discussions...we've got about 20mins left....so, might as well move along to the other bigger topic I had put on the agenda: "Brainstorming around DSpace's UI for the future"
[15:39] <tdonohue> First, a small amount of background (which is also in the agenda)
[15:40] <tdonohue> 1. I've mentioned this before, but we have a new DSpace Steering Group established just last year
[15:41] <tdonohue> 2. While they are still getting their "feet wet" as a Steering Group, they've immediately pointed to the fact that supporting 2 "out-of-the-box" UIs is a bit hard, and we're basically "splitting" our limited developer resources
[15:41] <KevinVdV_> ==> needs to run first PR for 5.1 from is in !
[15:42] * KevinVdV_ (~kevin@85.234.195.109.static.edpnet.net) Quit (Quit: KevinVdV_)
[15:42] <tdonohue> 3. While *nothing* is set in stone here (this literally is just a brainstorm), the Steering Group has been wondering what we'd like to see out of a DSpace UI going forward, and they've been recommending we really may want to just support *ONE* UI by default
[15:42] <hpottinger> tdonohue: that will involve a fight :-\
[15:42] * peterdietz (uid52203@gateway/web/irccloud.com/x-bapuvxgdcnjfoxon) has joined #duraspace
[15:43] <peterdietz> hi all. (distracted on a group phone call) But I'll try to follow along
[15:43] <tdonohue> 4. As both our existing UIs are now dated (even though they've seen some redesign recently to use Bootstrap)... JSPUI is 13+years old, XMLUI is 7+ years old... this is not JUST a question of "JSPUI vs XMLUI, which is better?" It's also the possibility to say "maybe we should investigate other options?
[15:44] <tdonohue> 5. The timeline for this is really also not set in stone...we're not talking anything immediate here..so, please don't get scared that XMLUI or JSPUI is "going away now!". The reality is that this will all be discussed in much more detail with the community before *anything* gets decided upon
[15:44] <tdonohue> With all that said...I've started a brainstorming page at: https://wiki.duraspace.org/display/DSPACE/Brainstorms+on+a+Future+UI
[15:44] <kompewter> [ Brainstorms on a Future UI - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Brainstorms+on+a+Future+UI
[15:45] <tdonohue> This page is completely public...*anyone* is welcome to add their own ideas, thoughts, wishes, etc. It is all about "laying it all on the table" and starting to look at our options. Then, we'll eventually start narrowing things down and deciding what to do from there
[15:46] <tdonohue> In the next 15 mins, you are also welcome to bring up any ideas/brainstorms that you may have right now. I'll try to be "quiet" now and listen
[15:46] <tdonohue> (Or if you have questions, pose those too, really)
[15:47] <hpottinger> in case you're just skimming along or catching up on the log of the meeting, note that the page that tdonohue just linked contains a few blocks for voting
[15:48] <tdonohue> yes, and in the giant table of "possible options to analyze" there's an area for "Personal Opinions" on each of the options
[15:49] <peterdietz> There's a lot of parity between XMLUI and JSPUI (jspui has seen a lot of catch up in the past year). Both have their faults in terms of not encouraging rapid development. I think JSPUI is easier to get started with, but has DIY programming vs using modern development patterns. XMLUI's sitemap stuff + xslt gives it a higher learning curve.
[15:49] <tdonohue> yep, I'd agree with that peterdietz
[15:50] <peterdietz> The WebMVC / Freemarker project (still alpha/beta right) did provide a nice direction, for clean code, that would be easier to maintain and support. But hasn't seen adoption
[15:50] <peterdietz> Then, the next idea is for 3rd party UI's, which opens the floodgates
[15:51] <hpottinger> I've heard of some experimental work replacing Cocoon with Spring WebMVC (hope I got the name right there)
[15:51] <tdonohue> So, here's a specific question to ask everyone (while you are thinking): Do you feel we should move to only distributing ONE UI with DSpace (but with the possibility that others could still maintain separate third-party UIs)? Or do you feel we should continue distributing TWO UIs with DSpace (as we have done since DSpace 1.5 days)?
[15:52] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) Quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
[15:52] <hpottinger> I like the idea of a single UI, and I'd also like to speak up for the notion of a UI coming along with the box
[15:53] <tdonohue> FYI the "WebMVC" project that peterdietz mentions is "alpha/beta" and now 4 years old (a bit outdated). It was a Google Summer of Code project, and its code is still in GitHub but has been unmaintained: https://github.com/DSpace/webmvc (But, that being said, it could be revived if we felt it useful)
[15:53] <kompewter> [ DSpace/webmvc ยท GitHub ] - https://github.com/DSpace/webmvc
[15:53] <peterdietz> I would say the ultimate goal is for your UI to be passing/pleasing for your low-budget school. Just wanting to add their own branding. Potentially also wanting to be able to spend a semester adding their own unique feature. So from their perspective, make sure it just works, and they can slightly extend.
[15:54] <tdonohue> hpottinger: in my opinion, DSpace would *always* include an UI out-of-the-box. That's part of what makes DSpace an "out-of-the-box" solution
[15:54] <hpottinger> +1, I just want to be sure that we're not talking about just shipping a black box
[15:55] <tdonohue> no, the Steering Group has been very key on the fact that DSpace is *the* out-of-the-box repository solution. It must be easy to install and get up and running, and that implies no "black box"
[15:55] <hpottinger> peterdietz I think hits on a key point, maybe we need to outline the goals of this single UI
[15:56] <tdonohue> So, on that page, I had started to outline some of the "needs" out of a single UI... see the "What makes a good UI (framework)?". But, yes, we could add even more generic "use cases" (like "easy to theme for a low-budget school", etc)
[15:57] <hpottinger> I think it's very important to have the software toolset/framework to solidify this notion of "this is what a repository *is*"
[15:57] <tdonohue> Are there other "use cases" / goals you see out of a Single UI? I heard the "easy to brand/theme" use case. Others?
[15:57] * srobbins (~Adium@mobile-130-126-255-147.near.illinois.edu) Quit (Quit: Leaving.)
[15:57] <hpottinger> I think "developer friendly" encapsulates the idea of "simple to modify the business logic"
[15:58] <tdonohue> sounds right
[15:58] <hpottinger> but, we might make it more explicit
[15:58] <tdonohue> (FYI, I'm writing these down...will find a way to fit this all into the Brainstorm page, perhaps as a "use cases" section or similar
[15:58] <peterdietz> Larger schools with development resources, and vendors that work on boutique solutions can make-do with the existing UI's, but, there are better solutions/approaches available with today's technology for tackling new needs. Ideally the community-UI, and the developer-friendly-UI are the same stack. It would be a hard sell to have your out-of-the-box
[15:58] <peterdietz> solution, and then the 3rd-party solution. But maybe we're saying the UI could use some renovation
[16:00] <peterdietz> Nobody wants to spend a 2 year project to make a new UI, and then see no adoption. But. I've noticed there are a number of forks in the fire, so to speak, with people building off of REST. Those don't have to be "the DSpace solution", but rather, here's your interface, build what you want.
[16:00] <peterdietz> i.e. Bruno's rails-dspace-rest-gem announced today
[16:00] <tdonohue> peterdietz: yea, ideally the "community-UI" and "developer-friendly-UI" are the same stack. But, I think there are *opportunities* for vendors / larger schools to create a "secondary" UI (which they support and release *separate* from DSpace "default UI").
[16:02] <tdonohue> peterdietz: but the general message of this whole brainstorm is... *both* UIs could use some renovation, and we probably want to move to just shipping with ONE UI. So, where do we go from here? Do we renovate XMLUI? Do we renovate JSPUI? Do we move to something else?
[16:02] <tdonohue> I did just see that "dspace" gem for Ruby on Rails. Pretty neat! https://gitlab.c3sl.ufpr.br/bnzanette/dspace-rest-client
[16:02] <kompewter> [ Bruno Nocera Zanette / dspace-rest-client | GitLab ] - https://gitlab.c3sl.ufpr.br/bnzanette/dspace-rest-client
[16:02] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) has joined #duraspace
[16:03] * tdonohue is noticing we are now at 16UTC, which means we'd unfortunately need to wrap up the meeting/discussion soon
[16:03] <peterdietz> I would say that most active developers on #dspace irc use XMLUI, but there is an active group that also maintains jspui regularly. So, each UI gets regular attention.
[16:04] <tdonohue> peterdietz: so, does that imply you favor continuing to maintain two UIs, even if that means we now need to renovate two UIs? Just curious
[16:05] <peterdietz> I don't see how you could technologically "merge" JSPUI and XMLUI. You could have some group make a decision to "officially" abandon one or the other. But there are a fair number of users/developers/committers using both
[16:05] <robint> Hi all, managed to miss the whole meeting :)
[16:05] <peterdietz> A third option is to have DSpace ship out-of-the-box with some new UI, that is somehow better than jspui/xmlui. It would take resources to build such a thing though.
[16:06] <hpottinger> robint: skim like you mean it, good discussion going on now :-)
[16:06] <robint> hpottinger: just catching up on UI chat
[16:07] <peterdietz> ...But, based on one data point, of Bruno. External groups could build their own UI/integration based on REST. This doesn't weaken or dilute DSpace's value proposition.
[16:07] <tdonohue> to be clear...in my opinion, XMLUI and JSPUI will likely "live on" to some extent, no matter what we decide. Hypothetically speaking, if we decided to "retire" on or the other, what we'd actually do is just split it out into a separate GitHub project (e.g. DSpace/dspace-xmlui or DSpace/dspace-jspui). If developers wanted to continue to maintain either, we'd give them Commit rights there to do so. But, we'd start to "ship" a new
[16:07] * mhwood (~mhwood@adsl-99-1-99-203.dsl.ipltin.sbcglobal.net) has joined #duraspace
[16:07] * srobbins (~Adium@mobile-130-126-255-147.near.illinois.edu) has joined #duraspace
[16:07] <robint> tdonohue: I'm still unclear about how this whole steering group thing is going to work
[16:08] <tdonohue> robint: what are your questions?...I'm glad to answer to the best of my ability ;)
[16:08] <robint> DSpace has largely hrown organically as far as I can see
[16:08] <peterdietz> So, wait-and-see would find out if external groups build something cool. And next year, your low-budget-school says, hey, I like this Brazil-UI better than XML-UI
[16:08] <robint> hrown/grown
[16:08] * tdonohue notes that even know we are "overtime" it looks like a few folks just got here...so, maybe we continue this discussion until folks need to depart
[16:09] <robint> Not sure how a steering group can lead such a disparate and independent group
[16:09] * hpottinger is trying to find a nice way to point out that developers have pretty strong feelings about their choice of UI
[16:09] <robint> ie the committers/developers
[16:10] <tdonohue> robint: good question on the "steering". As an open source project, obviously the larger community can still "decide" to do whatever they want (it is open code). But, what we've done recently is establish two group of "key stakeholders" from our DSpace open source community
[16:11] <tdonohue> robint: one group is "Steering Group" (initially they were appointed, but they will be *elected* in the future). They help provide overall "vision" and they control the $$ donated to DSpace (I also now "report" to them to some extent)
[16:12] * hpottinger is trying to find a way to surmise how the steering group can/will work, and it's coliding with his desire to be funny/charming, and it will all end in tears, so he's gonna stop now.
[16:12] <peterdietz> XMLUI is cool, it has the aspect pipeline. It's pretty unique. I think some alternative UI (whether that be webmvc or Brazil-UI) will likely be less flexible, but more opinionated. Your item-page is built by item-controller and item-view, not an item-pipeline of navigation-controller, statistics-controller, metadata-controller, item-thumbnail-controller, etc
[16:12] <tdonohue> robint: The second group (just established) is the "Leadership Group" (larger than Steering, and Steering is mostly a subset of this larger group). Leadership Group is key stakeholders from throughout the world, and those who have given some amount of $$ to the DSpace open source project
[16:13] <tdonohue> The way we see this working going forward is essentially this...
[16:13] <mhwood> When there is a formal authority structure in place, a steering group can steer by grasping the wheel and twisting, i.e. tell the makers what to make and require them to do so. Here we have an INformal authority structure, and what the steering group can do is give makers a clearer understanding of what would be well received, which is important to makers. On the one hand: control; on the other: influence.
[16:14] <mhwood> peterdietz: I value highly the ability to just stick another stage into the pipeline.
[16:14] <tdonohue> 1. The Steering Group is highly invested in DSpace as a project...they care about it cause they use it and often have developers (or Committers) working for them. But, Steering also includes some smaller instittutions who speak on behalf of that portion of our community
[16:14] <lyncodev> tdonohue: Still wouldn't be important having this committer group providing some guidance to the ones that may "externally" create a new UI?
[16:15] <robint> tdonohue: keep going, I am listening in case you are wondering :)
[16:15] <tdonohue> 2. The Steering Group "leads" by making suggestions on a way forward.. The actual *way forward* is NOT decided by Steering though...they will work with Committers & DCAT mostly to make these decisions. Steering is NOT technical enough to make technical decisions, NOR are they "Repo mgrs" who can make Use case decisions
[16:16] <robint> Ah ok, point 2 is crucial
[16:16] <tdonohue> 3. So, Steering Group makes suggestions..e.g. "We really shouldn't be building two UIs, why are we doing that? What do the Committers think? is there a way around this?"
[16:17] <tdonohue> 4. When it comes down to it... Committers & DCAT are the ones who *make recommendations* to Steering. Steering then says: "Yes, sounds good!" or "No, that seems unreasonable, let's work on that more"
[16:17] <robint> More a 'Gentle Persuasion' group than a 'Do this' group
[16:18] <tdonohue> 5. If something "sounds good" to Steering, the Steering Group would then make that recommendation to the *bigger Leadership Group*: e.g. "Along with DCAT & Committers, we think we should adopt ONE UI, what do you think?"
[16:18] <tdonohue> 6. Leadership group then gets to VOTE (on behalf of the overall community) on that decision. If they reject it, the idea is rejected...the Community has "spoken"
[16:20] <tdonohue> 7. If Leadership *approves* of a decision, then with Steering group, they gather *resources* to make this all happen. In the case of a revamped/new UI, those resources would be *developers*. Luckily, since Steering Group members (and Leadership Group members) have some developers, hopefully they will choose to donate one or more of them
[16:20] <tdonohue> ok...I think that's the basics...does that *start* to makes some sense on the new "model" of Steering / Leadership? (I will admit this idea has adapted in recent months as we start to "work out" the kinks...it probably will continue to adapt)
[16:21] <robint> My concern was/is that, taking the UI as an example, we already have an XMLUI interest group and a JSPUI interest, the Steering Group would just become a third interest group
[16:21] <robint> Sounds like my worries are unfounded
[16:22] <mhwood> So far, the Leadership's vote is still informational. However, if e.g. my Dean has a seat on the group, he can come back after a vote and tell my team leader: "I want us to take this on. If you need more resources, I'll find funding. Make it so." So the informal network can *employ* formal networks.
[16:22] <tdonohue> But, essentially the Committers still are the *technology decision group*. No control has been taken away from the Committers...but now, in a way, we have the opportunity to locate more resources to *help* on larger projects (from Steering & Leadership group insitutions)
[16:22] <tdonohue> robint: yea, that's not the case :)
[16:23] <tdonohue> mhwood: yes, correct. Also worth mentioning the Leadership group is a larger group (meant to represent the broad community, but voting on behalf of the community). Currently, I think it's ~15 institutions with "votes", but it may expand to 30 or so from across the world
[16:24] <robint> Apologies for that diversion onto policy matters, feel free to get back to the more interesting UI technologies discussion :)
[16:25] <tdonohue> Oh, and the people who sit on Steering & Leadership are being posted on the DSpace website. Both of these groups are a bit "smaller" right now, as they are getting started. But going forward, both may expand more
[16:25] <tdonohue> Initial Steering Group: http://dspace.org/steering-group
[16:25] <kompewter> [ DSpace Steering Group | DSpace ] - http://dspace.org/steering-group
[16:25] <tdonohue> Initial Leadership Group (still in progress of getting established, more may be added): http://dspace.org/leadership-group
[16:25] <kompewter> [ Leadership Group | DSpace ] - http://dspace.org/leadership-group
[16:25] <peterdietz> I'm likening two UI's as a problem to a city having two highways as a problem. Sure, take one out, people could use the other parallel highway. The "ideal" situation might be an underground metro, (new UI built on newer technology / webmvc / rest+rails). So, if your wanting to change things, then you'll have to make a decision, then make some investments
[16:26] * srobbins (~Adium@mobile-130-126-255-147.near.illinois.edu) Quit (Quit: Leaving.)
[16:26] <mhwood> What if you think of it like a city with two telephone companies. Which don't interconnect. (That actually happened, I'm told.)
[16:27] <mhwood> I don't want a *third* telephone on my desk.
[16:27] <hpottinger> unless that third telephone is *really* awesome
[16:27] <lyncodev> :D
[16:27] <tdonohue> peterdietz: to clarify a bit..I'm not suggesting two UIs is a problem. I'm just suggestion *shipping* two UIs, managed by a *single Committers group* is a problem. In other words, two UIs should have two separate Committers groups (tailored towards each UI).
[16:28] <mhwood> tdonohue++
[16:29] <peterdietz> Yeah, that's maybe a more accurate analogy. I guess we're waiting on decisions / solutions / further weighing in
[16:29] <tdonohue> So, going forward, there may still be *multiple* UIs available to select from...and that's fine. But, I feel that DSpace should *ship* with just one UI.
[16:29] <hpottinger> this brainstorms page is fun, it's full of distractions :-)
[16:30] <hpottinger> ooh, Spring Boot, shiny :-)
[16:30] <mhwood> I think a useful position might be: DSpace has a lot of stuff in it that we all more or less agree on. UIs is an area in which people tend to disagree (and boy, do we in the DSpace community disagree there!) So let's factor the UIs out, ship one and spend effort on making it easy for those with different needs to have another.
[16:31] <hpottinger> mhwood++
[16:31] <tdonohue> So, as an example, hypothetically speaking suppose we decide to revamp JSPUI & only ship with JSPUI. Maybe we do this in time for DSpace 7. The, the DSpace 7 release will only have a JSPUI. BUT, some helpful community members (maybe some of which are also Committers) could still say.."Oh, hey, still want the XMLUI? Here's XMLUI version 7.0, just install it on DSpace 7 and it'll work!"
[16:32] <tdonohue> mhwood++ (well said)
[16:33] <mhwood> I dislike the amount of time I see going into maintaining multiple UIs. And I think the intimate relationship between UI and back-end code makes the work harder. Spinning off even one should push us to make it easier to do so by making clearer where we can separate concerns.
[16:34] <mhwood> "Some helpful community members" are probably the ones saying, "hey, waitaminute, WE still want XMLUI, and if we have to maintain it ourselves then so be it."
[16:34] <hpottinger> in theory an alternate packaging should be possible, even if the official distribution only comes with one UI, the alternate UI teams could package up their own distributions
[16:35] <tdonohue> So, to sum up: The Steering Groups role here is to ask the hard question: "Why are we developing two UIs simultaneously? Can we stop doing that, it seems wasteful...we should really just build one.". It's now up to us (Committers & other interested Developers) to start to brainstorm out other options. We have a voice here, and we can help decide the solution. It may not be an easy discussion at all times, but I hope you all will
[16:36] <mhwood> Sometimes I think that having *any* UI in the box is a necessary evil. DSpace should ship with a UI, yes, even if it isn't the one we use here. But Google is the UI most people are using, no? So we should do a good job, but only put big effort into areas where we can do better than Google and they won't care.
[16:36] <tdonohue> hpottinger++ yep, that is an option for alternative UI teams to distribute a separate "DSpace+alternateUI". Or, it might be an opportunity to finally build out a better "plugin model"...here, click this button to install this "alternate, third-party UI" instead.
[16:37] <tdonohue> mhwood++ yep, to add to that...the maintaining of two UIs sometimes takes time away from areas we *could* be doing more (SEO being a great example of something we could do even better)
[16:39] <mhwood> Well, another thing we can do better is to provide *sharper* tools. Google is a great casual search tool. But if you are an *expert* searcher, it can be frustratingly oversimplified. (Or so I imagine.) There are times when I want to compose a search in a way that's inexpressible to Google.
[16:39] * srobbins (~Adium@mobile-130-126-255-147.near.illinois.edu) has joined #duraspace
[16:39] <tdonohue> Other thoughts to share here? (This has been a great discussion, and but I don't want to close it if folks are still pondering big ideas/questions)
[16:40] <robint> tbh these discussions are fun, the tricky bit will be marshalling us towards a conclusion, over to you tdonohue :)
[16:40] <tdonohue> mhwood++ again
[16:40] <tdonohue> robint: yea, I get the hard job, but luckily I have lots of smart folks (all you) who can tell me if "I'm getting it wrong"
[16:40] <mhwood> Sorry to arrive late, and I'm going to have to leave shortly. (I'm actually at home now, getting ready to go to work after lunch.)
[16:41] <robint> Got to head off myself, cheers all
[16:41] <lyncodev> Cheers
[16:41] <tdonohue> Ok, sounds like things are closing up. Based on this discusion, I'm going to enhance some of the descriptions / background info on the Brainstorming page.
[16:41] <lyncodev> Hard times...
[16:41] <mhwood> Thanks for collecting our scattered thoughts.
[16:41] <tdonohue> Still, please add your thoughts/ideas/brainstorms here: https://wiki.duraspace.org/display/DSPACE/Brainstorms+on+a+Future+UI
[16:42] <kompewter> [ Brainstorms on a Future UI - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Brainstorms+on+a+Future+UI
[16:42] * tdonohue officially closes this meeting. Since we ran really long, I'm not going to hold "JIRA Backlog Hour" today. But, I'll be around if anyone has additional thoughts (on either #duraspace or #dspace IRC)
[16:42] <lyncodev> Choosing the UI future will never be consensual I believe
[16:43] <mhwood> GTG. Thanks all.
[16:43] * mhwood (~mhwood@adsl-99-1-99-203.dsl.ipltin.sbcglobal.net) Quit (Quit: Leaving.)
[16:44] <tdonohue> lyncodev: nope, I don't expect this decision to be easy, nor will there ever be 100% agreement. There will definitely be multiple UIs going forward for some time, but it will be up to individual groups to maintain whatever UI they feel is "better" than the one, out-of-the-box UI chosen.
[16:45] * robint (81d7fa56@gateway/web/freenode/ip.129.215.250.86) Quit (Ping timeout: 246 seconds)
[16:45] <lyncodev> tdonohue: Once one UI is choosen, I mean whatever UI, my motivation to work on the front-end will grow.
[16:45] <lyncodev> (personal opinion)
[16:49] <lyncodev> I've started developing SpringUI, it is still under development, but the main thing, as any other UI currently is that, whatever feature I do, if I want it to be useful, it need to be implemented in too many UIs and adding one more, is just contributing to the complexity explosion.
[16:50] <hpottinger> tdonohue: I wonder when will be a good time to discuss the notion of moving away from our own home-grown database abstraction, and possibly move towards something like an ORM?
[16:50] <lyncodev> hpottinger: ORM is not sexy anymore :P
[16:51] <hpottinger> this is a more general concern: will our steering group point us towards more visible change?
[16:52] <hpottinger> I don't actually care that much if it's an ORM, I just think we'd be better off borrowing someone else's database abstraction work
[16:53] <hpottinger> ditto for AuthN and AuthZ, and probably business logic, too
[16:56] <tdonohue> steering group is not "technical" in nature. They won't make code change / architecture change recommendations
[16:57] <tdonohue> (though I guess a few folks are a tad technical...Stuart Lewis & Lieven Droogmans)
[16:57] <tdonohue> But, we *can* make recommendations to Steering group on things that need to happen.
[16:58] <tdonohue> In many ways though, I haven't pushed on those other issues (DB abstraction, AuthN/Z) yet, because they may end up being "sub-tasks" of the larger UI "reworking" (depending on the UI chosen)
[16:59] <tdonohue> For example, if we moved to a new "framework", there are some UI frameworks that come with some AuthZ plugins readily available.
[16:59] <tdonohue> hpottinger: so, keep pushing on those issues...they will happen, but we need to figure out *when* is the right time (and usually that *when* is as soon as there's something that truly requires it)
[17:00] <tdonohue> (we unfortunately cannot tackle everything at once...but little by little, I think we'll get there)
[17:00] <tdonohue> lyncodev: yep, I can understand your point of view on the motivation for enhancing current UIs, etc
[17:01] * hpottinger is tempted to add another JS framework to the pile
[17:02] <tdonohue> hpottinger: add more to the pile, please. The current table is mostly a brain dump of stuff I've heard of... I am SURELY missing options, and I'd like to get as many listed as possible. We can narrow down the scope later on
[17:03] <tdonohue> e.g. grahamtriggs was the one who added Spring Boot, which I hadn't been tracking/following (but does look interesting)
[17:03] <hpottinger> I'm certainly not an expert, but the demo for RiotJS made an impression on me and I started following them
[17:03] <hpottinger> https://muut.com/riotjs/
[17:03] <kompewter> [ Riot 2.0 | A React- like UI library ] - https://muut.com/riotjs/
[17:03] <tdonohue> cool, I'll have to take a look at it
[17:08] * srobbins (~Adium@mobile-130-126-255-147.near.illinois.edu) Quit (Quit: Leaving.)
[17:10] <hpottinger> going to skip adding it for now, brain is full, have things that need my attention
[17:22] <hpottinger> OK, DSPR#712 is merged to DSpace:master and cherry-picked/pushed to the 5_x maintenance branch
[17:22] <kompewter> [ https://github.com/DSpace/DSpace/pull/712 ] - DS-2201: Unable to complete installation of DSpace with non-empty variable "db.schema" configuration file "build.properties" by ctu-developers
[17:28] <lyncodev> Going home, see you later
[17:30] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) Quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
[17:32] <hpottinger> closed DS-2201 and added my own mea culpa
[17:32] <kompewter> [ https://jira.duraspace.org/browse/DS-2201 ] - [DS-2201] Unable to complete installation of DSpace with non-empty variable "db.schema" configuration file "build.properties" - DuraSpace JIRA
[19:51] * hpottinger (~hpottinge@mu-162188.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[20:57] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[22:00] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[22:53] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.