Timestamps are in GMT/BST.
[6:50] -barjavel.freenode.net- *** Looking up your hostname...
[6:50] -barjavel.freenode.net- *** Checking Ident
[6:50] -barjavel.freenode.net- *** Found your hostname
[6:50] -barjavel.freenode.net- *** No Ident response
[6:50] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:50] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:50] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[13:19] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:46] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has joined #duraspace
[15:17] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[16:38] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[19:55] * kstamatis (b03a8014@gateway/web/freenode/ip.176.58.128.20) has joined #duraspace
[19:56] * helix84 (~ctenar@195.178.95.132) has joined #duraspace
[20:01] <tdonohue> Hi all, it's time for our weekly DSpace Developers Meeting. https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-01-22
[20:01] <kompewter> [ DevMtg 2014-01-22 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-01-22
[20:03] <tdonohue> Sorry, the Wiki & stuff is being really slow for me right now....
[20:04] <mhwood> Not just you....
[20:04] <tdonohue> in any case, today I mostly wanted to touch back on DSpace 4.1. There's at least one major (maven build) issue that may warrant a 4.1 release in the near(ish) future: https://jira.duraspace.org/browse/DS-1867
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1867 ] - [DS-1867] Maven build issues from [src]/dspace/ , error finding target/build.properties - DuraSpace JIRA
[20:04] <kompewter> [ [DS-1867] Maven build issues from [src]/dspace/ , error finding target/build.properties - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1867
[20:04] <tdonohue> mhwood: yea, that was also my worry. Things are sloooow (and not sure why). I've got two conversations going on at once
[20:06] <tdonohue> So, in any case, I wanted to revisit 4.1, in light of Ds-1867. Do we want to start to think about scheduling a 4.1? Do we want to wait a while longer?
[20:06] <helix84> there's just one bugfix on master so far
[20:07] <helix84> I'd say the build issue is non-critical - if you follow documentation, you won't encounter it
[20:07] <tdonohue> agreed, but some "bug fixes" are bigger than others. :) Which is the only reason I bring this up. I've realized that 1867 is a rather annoying Maven build bug. It'd be nice to fix it sooner rather than later
[20:08] <helix84> that said, several people alredy did, but by that time we knew what to tell them
[20:08] <tdonohue> "if you follow documentation" is not exactly correct. The Install docs say to build DSpace from "[src]/dspace", which will NOT work
[20:08] <tdonohue> The only way that running Maven from [src]/dspace/ *works* in 4.0 is if you first build from [src]/
[20:09] <mhwood> If we want to wait a bit, can we publish a patch that's easy to apply?
[20:10] <helix84> sorry, all this time I've been thinking we corrected the documentation. It still says cd [dspace-source]/dspace/
[20:10] <tdonohue> well, the 'patch' is essentially the fix in https://github.com/DSpace/DSpace/pull/443. There is an even easier patch we could do, but it doesn't change the fact that if you follow our documentation you will get an immediate error
[20:11] <tdonohue> So, while I agree, it seems like we don't have many fixes in for a 4.1, I am starting to wonder myself if fixing 1867 is enough to warrant a 4.1 release
[20:11] <kstamatis> There is also this issue: https://jira.duraspace.org/browse/DS-1857 for which we are going very soon to fire a PR. Misconfiguration of BTE leads to tomcat shutdown
[20:11] <kompewter> [ [DS-1857] Unhandled exception in BTE batch import when uploading CSV files with misconfiguration options - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1857
[20:11] <kompewter> [ https://jira.duraspace.org/browse/DS-1857 ] - [DS-1857] Unhandled exception in BTE batch import when uploading CSV files with misconfiguration options - DuraSpace JIRA
[20:11] <helix84> kstamatis: yes, that's a serious one
[20:11] <mhwood> OK, those two together cross my "big enough for a bugfix release" threshold.
[20:12] <hpottinger> My brain is trying to tell me there's something else...
[20:12] <tdonohue> so, what's the schedule for fixing 1857? Perhaps we should think about trying to get both of these into 'dspace-4_x' branch soonish, and tentatively schedule a 4.1 for a 1-2 weeks from now?
[20:13] <kstamatis> We have a solution, tomorrow we are going to test it and then fire the PR
[20:13] <tdonohue> kstamatis: sounds great
[20:14] <tdonohue> and, to hpottinger's point. We may want to dig around in the existing PRs (and recent Jira tickets) to see if there's any other "quick fixes" that could be put into a 4.1 release in the nearish future
[20:14] * keithg (46d0a0d9@gateway/web/freenode/ip.70.208.160.217) has joined #duraspace
[20:16] <tdonohue> I had also listed DS-1873 as a small fix to put into a possible 4.1, but it would depend on whether folks agree with this change or not (if not, it could wait till a 4.2 or 5.0 if it needs reworking).
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-1873 ] - [DS-1873] CheckSum Checker Emailer sends emails for 0 issues, doesn't specify any site info - DuraSpace JIRA
[20:16] <mhwood> I would not object to its inclusion.
[20:16] <helix84> I wouldn't call it a bug fix but I agree with it going into 4.1 ;)
[20:17] <tdonohue> yea, I know 1873 is a "gray area" between bug fix & improvement. We're running it in Production for DSpaceDirect already, so I thought I'd offer it up. But, I wanted to get your opinions :)
[20:18] <helix84> we already have this one on master: DS-1832 We still haven't created the 4_x branch.
[20:18] * jefftrimble (~jefftrimb@maag127.maag.ysu.edu) has joined #duraspace
[20:18] <kompewter> [ https://jira.duraspace.org/browse/DS-1832 ] - [DS-1832] Proxy configuration set in system properties if empty - DuraSpace JIRA
[20:19] <tdonohue> huh? we have a 4.x branch : https://github.com/DSpace/DSpace/tree/dspace-4_x
[20:19] <kompewter> [ DSpace/DSpace at dspace-4_x · GitHub ] - https://github.com/DSpace/DSpace/tree/dspace-4_x
[20:20] <helix84> Right. I'm wondering why it doesn't show up here: https://github.com/DSpace/DSpace/branches
[20:20] <kompewter> [ Branches · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/branches
[20:20] <helix84> It's probably nothing
[20:20] <tdonohue> helix84: it doesn't show up in that list cause currently "dspace-4_x" = "master" (and https://github.com/DSpace/DSpace/branches only shows branches != master)
[20:20] <kompewter> [ Branches · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/branches
[20:21] <tdonohue> or to be more accurate, dspace-4_x doesn't include any *new* commits that are not merged on master...it's not directly *equal to* master
[20:21] <mhwood> It does show in the drop list of branches on the DSpace/DSpace page.
[20:22] <helix84> sorry for the distraction
[20:23] <tdonohue> So, sounds like we have 1857, 1867 and 1873 all as additions to 4.1. Anything else we should try to prepare for 4.1?
[20:25] <mhwood> DS-1756? DS-1757?
[20:25] <kompewter> [ https://jira.duraspace.org/browse/DS-1756 ] - [DS-1756] Wrongly aligned text on item view in mobile theme - DuraSpace JIRA
[20:25] <kompewter> [ https://jira.duraspace.org/browse/DS-1757 ] - [DS-1757] Missing images in mobile theme - DuraSpace JIRA
[20:26] <tdonohue> yes, those both look like good "quick fixes" we can add to a 4.1
[20:27] <helix84> I tested 1757. I'll confirm 1756, too.
[20:27] <misilot> DS-1817 ?
[20:27] <kompewter> [ https://jira.duraspace.org/browse/DS-1817 ] - [DS-1817] Improvement of Collection Dropdown on Move Item Page - DuraSpace JIRA
[20:27] <tdonohue> sounds good, thanks helix84. Both of those sound like they could be merged immediately once verified (as both are small tweaks)
[20:27] <hpottinger> there are "quite a few" issues tagged for 4.1 in JIRA
[20:28] <helix84> 1817 should work. I just forgot to add the calling code to one or two places and 1817 adds it.
[20:29] <tdonohue> hpottinger: yea, I saw that too. I think it's mostly "carried over" tickets from 4.0 that were just rescheduled. I'm not sure many of them have PRs yet, but perhaps they'd warrant a quick review in next week's "JIRA Review Hour"?
[20:29] <helix84> tdonohue++
[20:30] <helix84> is it just me or does http://mobile.demo.dspace.org/xmlui/ show without a stylesheet?
[20:30] <kompewter> [ DSpace Home ] - http://mobile.demo.dspace.org/xmlui/
[20:30] <tdonohue> Ok, so next week's "JIRA Backlog/Review Hour" (at 19:00UTC in #dspace, before this meeting), will be devoted towards reviewing JIRA tickets tagged for "4.1" release, just to see if there's any other "quick fixes" to be had
[20:31] <tdonohue> helix84: I'm seeing it as stylized (with the red header, etc)
[20:31] <hpottinger> helix84: I see styles on that
[20:32] <tdonohue> So, based on this discussion so far, it sounds like we would want to wait *at least* a week to cut a 4.1 (just so we can review tickets next week & get in some other fixes still). Should we think about a 4.1 in early Feb?
[20:34] <helix84> Sounds good. We should also check all bugs against 4.0 to see if there are any serious ones that we should fix ASAP.
[20:34] <tdonohue> Or is there another timeline we want to shoot for (earlier or later)? Just trying to get us to set a goal, so we have general timelines around when fixes need to get into "dspace-4_x" branch in time for 4.1
[20:35] <mhwood> Tangent: Jira issue page has a "Git commits" tab that always says "There are no subversion log entries for this issue yet." "Commits" shows Git stuff.
[20:35] <mhwood> Early Feb sounds good. That starts just over a week from now.
[20:36] <hpottinger> housekeeping: same RT, same RT lead?
[20:36] <hpottinger> for the record: I'm in
[20:36] <tdonohue> I think that's a question for the RT. How do you all feel? Have time for a 4.1? Do we need new volunteers?
[20:37] <mhwood> I can do that.
[20:37] <tdonohue> ok, so, sounds like same RT for 4.1 (assuming bollini is also game). But, others are more than welcome to chip in, and RT feel free to ask for help if it is needed.
[20:38] <mhwood> Yes indeedy.
[20:39] <tdonohue> RE: helix84's note above. We should try and find tickets that are marked as "bugs against 4.0" and schedule them for 4.1 if they are serious. I suspect the serious ones should already be scheduled, but we might want to do a quick skim to be sure
[20:40] <helix84> mhwood: is DS-1744 meant to go to 4.1?
[20:40] <kompewter> [ https://jira.duraspace.org/browse/DS-1744 ] - [DS-1744] Upgrade to latest log4j - DuraSpace JIRA
[20:41] <mhwood> Yes, I see that I haven't got it in 4_x yet, setting up to correct that now. Unless we want it to wait for 5.0.
[20:41] <helix84> mhwood: I've got it, just confirming.
[20:41] <helix84> mhwood: I'm backporting now.
[20:42] <mhwood> Oh, OK, thanks.
[20:42] <tdonohue> I'm slightly hesitant to upgrade dependencies in bug-fix releases, *unless* those dependency updates actually fix a bug for us
[20:42] <mhwood> Memory leak fix.
[20:42] <tdonohue> But, 1744 seems to qualify for 4.1, as it fixes a memory leak :)
[20:43] <mhwood> I have a raft of other dependency tweaks, but they are unscheduled or for 5.0, IIRC.
[20:43] <tdonohue> yep, I have seen most/all of those mhwood. I agree, they look great for 5.0 :)
[20:44] <tdonohue> Ok, so anything else we want to chat through via 4.1? Sounds like we have a tentative schedule (early Feb) for 4.1. We have started to approve some fixes that should be in 4.1. Next week we'll review tickets scheduled for 4.1 (in "JIRA Review Hour"). Anything we missed?
[20:46] <tdonohue> Ok, hearing nothing else
[20:47] <helix84> FYI backports from master to 4_x are now done
[20:47] <mhwood> Thanks helix84
[20:47] <tdonohue> yes, thanks helix84!
[20:47] <tdonohue> OK, any other topics folks wish to bring up today?
[20:48] <hpottinger> mhwood: dependency tweaks, can you share?
[20:48] <mhwood> I just made a first pass at Metadata for All. So far it builds but has not been run.
[20:48] <helix84> mhwood: yay!
[20:48] * helix84 throws confetti
[20:48] <hpottinger> Oh, that reminds me, "let's talk about features"
[20:48] <tdonohue> hpottinger: for mhwood's dependency tweaks, see his recent PRs: https://github.com/DSpace/DSpace/pulls/mwoodiupui
[20:48] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls/mwoodiupui
[20:49] <tdonohue> "Metadata for All"! awesome!
[20:49] <helix84> mhwood: where do I look?
[20:49] <mhwood> https://github.com/mwoodiupui/DSpace/tree/metadata-for-all
[20:49] <kompewter> [ mwoodiupui/DSpace at metadata-for-all · GitHub ] - https://github.com/mwoodiupui/DSpace/tree/metadata-for-all
[20:51] <mhwood> It's really starting to bug me that I can't hang metadata on Collections, so I thought I'd try to fix that.
[20:51] <tdonohue> so how does it work? I.e. what are you using for "metadata for all" / any docs or rough notes around?
[20:51] <mhwood> So far, all I've done is to move the metadata methods and fields from Item to DSpaceObject, and repair any damage that caused.
[20:51] <tdonohue> gotcha. makes sense
[20:52] <mhwood> There's no new code to take advantage of it yet.
[20:53] <helix84> mhwood: oh, so this is a new implementation, not a port of mdiggory's work?
[20:53] <tdonohue> still, it sounds like a good first step.
[20:53] <helix84> mhwood: I was wondering where the schema changes are :)
[20:54] <mhwood> I went looking the other day and found discussion but no code. I guess it just isn't linked, or I missed the link. Oops.
[20:54] <tdonohue> I think there was a (very old now) PR that mdiggory had with some code. But, I don't know how "built out" it really was
[20:55] <helix84> mhwood: here it is: https://github.com/DSpace/DSpace/pull/12
[20:55] <kompewter> [ Support Metadata On All DSpaceObjects by mdiggory · Pull Request #12 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/12
[20:55] <tdonohue> helix84 found it :) I was just looking for that same PR
[20:55] <hpottinger> oh, Lyncode has been working on OAI...
[20:55] <helix84> it has everything except UI changes
[20:56] <hpottinger> https://github.com/DSpace/DSpace/pull/441
[20:56] <kompewter> [ OAI 2.1 by lyncodev · Pull Request #441 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/441
[20:56] <helix84> hpottinger: yes, it should be interesting to hear about the upgrade to OpenAIRE on OR14
[20:56] <hpottinger> pre 4.1 thing: we should look for PRs without JIRAs
[20:57] <mhwood> Oh, I remember that PR. It was closed, pending discussion of the scope of the project.
[20:57] <helix84> I'll open an issue for 441
[20:57] <hpottinger> 441 is still open
[20:57] <tdonohue> hpottinger: yep, I just noticed joao had that PR (#441). It *sounds* like it fixes DS-1856 (but it does a lot more than just fix that issue).
[20:57] <kompewter> [ https://jira.duraspace.org/browse/DS-1856 ] - [DS-1856] OAI-PMH indexes metadata of non-public Items - DuraSpace JIRA
[20:58] <hpottinger> ah, well I remember another OAI bugfix
[20:58] <helix84> well, it depends on the new version of xoai
[20:58] <tdonohue> yea, not sure if PR#441 would qualify for 4.1...it sounds like major changes? But, it's unclear
[20:58] <helix84> tdonohue: definitely major
[20:59] <tdonohue> Ok, well, if you create a new ticket for PR#441, could you link it up to 1856? Both could just be scheduled for 5.0, I guess. Unless we convince Joao to push out the 1856 fix earlier
[21:01] <helix84> tdonohue: There actually was an open issue. All linked now.
[21:02] <tdonohue> cool, thanks.
[21:02] <mhwood> I noted mdiggory's PR on the Wiki page Metadata for All.
[21:02] <tdonohue> good idea, mhwood.
[21:03] <tdonohue> Any other last topics for today (noticing we are at one hour now)?
[21:03] <helix84> mhwood: add yours, too. We may discover some differences in your approaches.
[21:03] <mhwood> I'd like to draw attention to a note on -devel about curious code in Item.addMetadata
[21:04] <tdonohue> mhwood: yea, I saw your note. Haven't had a chance to dig in yet. At a glance, it does look a bit odd to me too
[21:04] * jefftrimble (~jefftrimb@maag127.maag.ysu.edu) Quit (Quit: Leaving)
[21:04] <mhwood> helix84: will do.
[21:04] <hpottinger> another possibility for 4.1: DS-1854/ DSPR#434
[21:04] <kompewter> [ https://github.com/DSpace/DSpace/pull/434 ] - DS-1854 by AnjaLeBlanc
[21:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1854 ] - [DS-1854] Meta data to queries in reply; Listing of all items; Pagination; Maximal pagination size option; item search using discovery - DuraSpace JIRA
[21:05] <helix84> hpottinger: I tried to rebase that. It's a merging mess.
[21:06] <helix84> hpottinger: I might just have to squash some parts :/
[21:06] <tdonohue> hpottinger: 1854 seems a bit "gray" to me. There's a few seeming "bug fixes" in there, but also a lot of new features/improvements
[21:06] <hpottinger> Agreed, tdonohue, new stuff
[21:06] <helix84> Actually, tim already said his opinion on this when I asked earlier. Definitely an improvement, not a bug fix.
[21:07] <tdonohue> also new configs, which I am not usually a fan of adding in a bug-fix release (as it complicates upgrades, etc)
[21:07] <hpottinger> I'm just skimming the list of PRs and blurting out the ones that look interesting
[21:07] <helix84> I suggested we might treat REST API in 4.0 as beta and subject to change in 4.1
[21:08] <hpottinger> searching with REST would be helpful, 'tis true
[21:09] <tdonohue> "subjected to change in 4.1" is ok. But, I start to get hesitant when we talk about adding a bunch of new configs between 4.0 and 4.1. We could make an exception, but I just wanted to note that this starts to cross some "boundaries" on what we allow in a "bug-fix-only" release :)
[21:09] <tdonohue> but, that is just my opinion. I'm just one person :)
[21:09] <mhwood> We may need to pick it apart and tease out the bug fixes, leaving the rest for later?
[21:09] <helix84> I'm only suggesting that because REST is still hot and we didn't really commit yet to it being a stable interface
[21:11] <tdonohue> helix84: yea, I can understand where you are coming from, honestly. I wouldn't "veto" this if others really wanted to push it into 4.1. I'm just noting my concerns.
[21:12] <tdonohue> In any case though, it sounds like the PR itself is still a mess...so we cannot do much of anything until it gets cleaned up
[21:13] <hpottinger> we could ask AnjaLeBlanc to squash/rebase, and split out just the bug fixes from the features
[21:14] <helix84> hpottinger: with all respect, she won't be able to do that. she did all the wrong things when merging. it's just new for her.
[21:14] <helix84> hpottinger: I'll try to take a look at it again, just noting that it seems I'll have to cut some corners.
[21:15] <tdonohue> yea, the PR is a complete mess. It's hard to even tell what is being changed. Ideally it would be nice to split into several PRs (one per feature / logical bug fix), but I know that'd take some work / might be difficult
[21:15] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[21:15] <hpottinger> understood, I've done the same (and worse) with Git
[21:15] <helix84> tdonohue: I don't think that's possible
[21:16] <helix84> tdonohue: it builds up on previous stuff in non-obvious ways
[21:16] <hpottinger> oh, look, it's PeterDietz!
[21:16] <PeterDietz> hi all
[21:16] <tdonohue> helix84: oh, I understand. That does complicate things, when it's all intermingled
[21:16] <helix84> I'll try to fix it up and we'll be wiser next week
[21:16] <mhwood> Discussing PR#434
[21:17] <tdonohue> sounds great, helix84. Thanks
[21:17] <hpottinger> DSPR#434
[21:17] <kompewter> [ https://github.com/DSpace/DSpace/pull/434 ] - DS-1854 by AnjaLeBlanc
[21:18] <PeterDietz> I've been involved in reviewing this PR somewhat. Helping to guide it along in the right direction.
[21:18] <hpottinger> PeterDietz: would you be able to help pull out the features from the bug fixes?
[21:18] <hpottinger> or, ahem, "bug fixes"
[21:18] <PeterDietz> I think one of the first things, is that it has too much git-stuff going on. i.e. a merge/pull got chomped up and added hundreds of changes, when the actual change is much smaller, and confined to rest as Anja said
[21:19] <tdonohue> yea, it's not really possible to review as-is. helix84 was saying he'd be willing to try and help clean it up
[21:19] <PeterDietz> I'm nervous as to what one calls DSpace REST API v1.0, I guess that is what shipped with DSpace 4.0
[21:20] <PeterDietz> This PR will change the responses enough that we've have to let an API consumer know that the API has changed
[21:21] <tdonohue> hmm..yea, that sounds like a REST API v2.0 then if the responses are not compatible with REST API v.1.0 / DSpace 4.0
[21:21] <PeterDietz> And I think it would be confusing if DSpace 4.0, and 4.1 had different API's.
[21:21] <hpottinger> OK, that's clearly in "new feature" territory
[21:22] <mhwood> So is there stuff in there that *could* still be 1.0, that can be teased out?
[21:22] <PeterDietz> These are definitely valid improvements to the API, I think we want to bring this in to the next release
[21:22] <helix84> PeterDietz: as in next major release?
[21:23] <tdonohue> PeterDietz ++ I agree on 4.0 vs. 4.1. I'm fine with the REST APIs being ever so slightly different though, as long as the one in 4.1 is still *compatible* with the one in 4.0.
[21:23] <PeterDietz> There is room to tease apart a few things. For instance this provides /items/ list, and paging, this is currently not in REST1.0, so it being a non-breaking change, is allowable to be added.
[21:23] <PeterDietz> But, we can't really change the response for /items/:id, /collections, ... and so on
[21:24] <mhwood> Since it needs worked over anyway, it might not be much more work to see how much we could adopt for 4_x, and save the rest for 5.0 (and get it into master soon).
[21:24] <PeterDietz> next major, yes. i.e. 4.0 -> 4.1 shouldn't break things. But 4.x -> 5.x could introduce a better response from API. I'm thinking that WRITE would be a good feature for 5
[21:25] <tdonohue> We're well over our meeting time here :) Love the discussion. Just noting that we won't have any other "official topics" after this one (so if folks need to head out, feel free)
[21:25] <tdonohue> PeterDietz++
[21:27] <hpottinger> +1 putting the C, U, and D in CRUD
[21:27] <PeterDietz> Well, since the official portion was out. I had a question. Anyone willing to consider the pro's/con's of Hydra + ActiveDSpace vs build a new rails UI system on top of DSpace REST
[21:28] <hpottinger> +1 joining communities
[21:28] <helix84> what's ActiveDSpace?
[21:29] <mhwood> The piece someone would have to write, to bolt Hydra onto DSpace.
[21:29] <PeterDietz> my fictional name for a Ruby on Rails gem that speaks to DSpace. Hydra has something called ActiveFedora, that allows Hydra to talk to fedora
[21:29] <tdonohue> Well, doing it yourself has the obvious disadvantages of requiring you to (a) support it yourself, (b) develop it all yourself, and (c) bug fix it yourself. Joining a large community of collaborators can ease those burdens :)
[21:30] <mhwood> OTOH how general is the bottom side of Hydra? Will it fit onto DSpace well?
[21:30] <tdonohue> "ActiveDSpace" is similar to "ActiveFedora" which is what Hydra uses to communicate with Fedora ;)
[21:30] <helix84> I'd start by asking who's interested in a Rails interface. I think hardy mentioned something.
[21:31] <mhwood> I think we have more than enough UIs already, and spend too much time developing more, but I'm an old grump....
[21:31] <tdonohue> I've had informal chats with others in the past around the concept of an "ActiveDSpace". It's unknown how easy it would be to implement (no one has tried, and those in the Hydra world don't know DSpace well enough to know)
[21:31] <PeterDietz> The old grump in me says I don't particularly like XMLUI, therefore I'd rather decouple the UI from the Application
[21:31] <helix84> mhwood: I would generally agree, but probably it's because none of them are good enough for ordinary people to customize and develop :)
[21:31] <mhwood> ActiveDSpace could just adapt Hydra to dspace-rest.
[21:32] <mhwood> That would be a good driver for fleshing out the REST stuff.
[21:33] <helix84> whatever happened to SkylightUI?
[21:34] <helix84> written in a popular language, communicates with backend via a fast HTTP interface...
[21:34] <PeterDietz> Also, the roll-your-own I was thinking of for DSpace, I was going to limit it to just read-only portion. The submission / management /workflow portion is so complex, that it would take many man years to redo. But a simple presentation layer would be simpler to accomplish
[21:35] <tdonohue> From my (vague, possibly incorrect) understanding, Hydra may make some "assumptions" about the underlying layer...essentially that it's "Fedora-like". I'm not sure if DSpace would fit well or not...so, it may need investigating whether ActiveDSpace idea is even possible. If it is, great. If not, then we should learn why not
[21:35] <mhwood> PeterDietz++. We need to stop thinking of the UI as a monolith, and consider what we could/should do if we e.g. break it up into browse/search/read, submission, and administration.
[21:35] <hpottinger> So, who wants to play?
[21:36] <tdonohue> PeterDietz: that sounds like SkylightUI, only in Ruby on Rails. SkylightUI (built by Kim Shepherd & Stuart Lewis & others) was/is a read-only PHP UI for DSpace: https://github.com/skylightui/skylight
[21:36] <kompewter> [ skylightui/skylight · GitHub ] - https://github.com/skylightui/skylight
[21:38] <tdonohue> But, I *fully agree* +1000 that we should stop building UI monoliths. There's no reason the Admin UI and the Submission UI and the Browse/Search UI need to be the same thing. They may need to be similar looking (sharing themes) but need not be the same.
[21:38] <helix84> tdonohue: couldn't agree more
[21:40] <hpottinger> Jorum is working towards a RoR DSpace UI
[21:40] * hpottinger is pretty sure he didn't spill any secrets there, hopes that's true
[21:41] <tdonohue> Looking at the SkylightUI github, it looks like that's also still an active project (at least kshepherd is working on it). It's updated for DSpace 3
[21:41] <mhwood> I question just how similar those refactored UIs need to be. They should have a basic resemblance of some sort, but really, you're talking about different audiences.
[21:41] <hpottinger> I think Stuart Lewis might be able to fill us in on the future of Skylight
[21:42] <tdonohue> mhwood: oh, I didn't mean they need to be *identical* :) Just meant that you might want to Submission UI to look somewhat similar to the Browse/Search (so it doesn't seem like an entirely different system to those users who use both). But, if you standardized on a CSS or JS platform (e.g. Bootstrap) for the UIs, that may be all you need
[21:45] <tdonohue> I'd actually expect we should talk to kshepherd about Skylight. Stuart is now at Edinburgh, and Skylight was built at U of Auckland (where Stuart used to be and Kim still is). So, Kim might actually know more..but who knows :)
[21:46] <helix84> Kim is still in Auckland?
[21:46] <tdonohue> I thought he was. Unless I haven't heard the latest :)
[21:47] <mhwood> http://nz.linkedin.com/pub/kim-shepherd/5/376/502
[21:47] <helix84> oh, so it seems: http://nz.linkedin.com/pub/kim-shepherd/5/376/502
[21:48] <hpottinger> well, suffice to say I think it would be a good idea to also ask Stuart about Skylight, if one were curious
[21:49] <tdonohue> In any case, it sounds like we have several folks interested in similar ideas but possibly on different platforms.... Skylight UI (on PHP) vs. a read-only Ruby on Rails interface (possibly by multiple groups).
[21:50] <tdonohue> just wish we could pull together a collaborative project here :) (though this discussion is a good first step of getting it all in our minds, I guess)
[21:50] <hpottinger> anybody going to the Users Group after SPARQ in Kansas City?
[21:53] <hpottinger> I might be going, and if I do end up going, I'd be up for some hacking on RoR (or, maybe PHP, if you buy enough beer)
[22:03] <mhwood> Gotta go, thanks all!
[22:03] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:03] * kstamatis (b03a8014@gateway/web/freenode/ip.176.58.128.20) Quit (Quit: Page closed)
[22:04] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has left #duraspace
[22:04] <tdonohue> I'm not gonna be at SPARC, unfortunately
[23:15] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Remote host closed the connection)
[23:16] * PeterDietz (~peterdiet@dhcp-164-107-232-172.osuwireless.ohio-state.edu) has joined #duraspace
[23:21] * PeterDietz (~peterdiet@dhcp-164-107-232-172.osuwireless.ohio-state.edu) Quit (Ping timeout: 272 seconds)
[23:25] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.