Timestamps are in GMT/BST.
[0:29] * edInCo (~smuxi@seta.coalliance.org) Quit (Remote host closed the connection)
[2:07] * kdweeks (~Adium@2001:468:c80:a103:4899:e41e:880:2c08) Quit (Quit: Leaving.)
[6:49] -holmes.freenode.net- *** Looking up your hostname...
[6:49] -holmes.freenode.net- *** Checking Ident
[6:49] -holmes.freenode.net- *** Found your hostname
[6:49] -holmes.freenode.net- *** No Ident response
[6:49] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:49] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:49] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:49] -holmes.freenode.net- [freenode-info] please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup
[12:10] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:33] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has joined #duraspace
[13:48] * kshepherd (kim@ec2-184-73-177-234.compute-1.amazonaws.com) Quit (*.net *.split)
[13:57] * kshepherd (kim@ec2-184-73-177-234.compute-1.amazonaws.com) has joined #duraspace
[14:01] * kdweeks (~Adium@2001:468:c80:a103:58be:5473:afd2:8ebe) has joined #duraspace
[14:09] * kdweeks (~Adium@2001:468:c80:a103:58be:5473:afd2:8ebe) Quit (Quit: Leaving.)
[14:19] * kdweeks (~Adium@2001:468:c80:a103:b062:c364:8ec4:547c) has joined #duraspace
[18:58] * Cgknowles (516436b5@gateway/web/freenode/ip.81.100.54.181) has joined #duraspace
[18:59] * monikam_ (~Monika_Me@monika.Princeton.EDU) has joined #duraspace
[19:01] * Cgknowles (516436b5@gateway/web/freenode/ip.81.100.54.181) Quit (Client Quit)
[19:05] * monikam_ (~Monika_Me@monika.Princeton.EDU) has left #duraspace
[19:17] * bram-atmire (~bram@94-225-35-170.access.telenet.be) has joined #duraspace
[19:24] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Remote host closed the connection)
[19:27] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[19:33] * monikam_ (~Monika_Me@monika.Princeton.EDU) has joined #duraspace
[19:33] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[19:52] * KevinVdV (~KevinVdV@d5153D041.access.telenet.be) has joined #duraspace
[19:55] * robint (5eaf588c@gateway/web/freenode/ip.94.175.88.140) has joined #duraspace
[20:00] <tdonohue> Hi all, it's time for our weekly DSpace Developers Meeting. Rough agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-07-09
[20:00] <kompewter> [ DevMtg 2014-07-09 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-07-09
[20:01] * cknowles_ (~cknowles@cpc19-sgyl35-2-0-cust180.18-2.cable.virginm.net) has joined #duraspace
[20:01] <tdonohue> And, of course, I didn't realize until this morning (for me) that NOW is the start of the World Cup Semi-final game (and we are directly competing with that). So, my complete apologies to those who are avidly watching the World Cup
[20:01] <tdonohue> But, I hope you can just do two things at once (for this first half of the game, at least)
[20:02] <tdonohue> In any case...the primary topic today is really about the 4.2 Release.
[20:02] <robint> Multitask!??
[20:02] * tdonohue laughs...honestly, I have the game on mute right next to me
[20:03] <tdonohue> (so if I go silent, or type gibberish, it's likely something just happened)
[20:03] <robint> After last nights game I daren't take my eyes off it
[20:03] <cknowles_> not as much as last nights match surely
[20:03] <tdonohue> haha. Yes, I agree
[20:04] <tdonohue> In any case...let's quickly talk some 4.2, so we can all get to watching the game :)
[20:05] <tdonohue> 4.2 was initially scheduled for THIS friday. However, we've had requests to delay for one week...as there are concerns of a possible Discovery/Solr issue (as yet unverified) based on recent thread to dspace-tech
[20:05] <tdonohue> This thread, to be exact: http://dspace.2283337.n4.nabble.com/DSpace-4-1-slow-to-submit-edit-delet-item-td4673891.html
[20:05] <kompewter> [ DSpace - Tech - DSpace 4.1 slow to submit/edit/delet item ] - http://dspace.2283337.n4.nabble.com/DSpace-4-1-slow-to-submit-edit-delet-item-td4673891.html
[20:05] <robint> Sounds like it might be the sensible choice to delay a week
[20:05] <mhwood> That would give one more week to clean up the 16 open tickets.
[20:06] <robint> There were also some outstanding issues from Hardy and Pascal B
[20:06] <tdonohue> I agree. I'm not too concerned about a week's delay...especially if we think there may be some valid concerns here (and it sounds like there may be, as the reports are coming from multiple users)
[20:06] <tdonohue> So, we all in favor for delaying the deadline for 4.2 fixes until next Friday, July 18?
[20:06] <robint> +1
[20:06] <mhwood> +1
[20:06] <tdonohue> I'm +1 too
[20:06] <KevinVdV> +1
[20:06] <bram-atmire> +1
[20:08] <tdonohue> Ok. Done, then. We'll delay 4.2 for one week, so we have more time for analysis, cleaning up last tickets, etc. Personally, I'd rather not delay too much more, barring any major discovered issues obviously
[20:09] <tdonohue> speaking of "last tickets"...there are still quite a few "unclaimed" tickets marked for 4.2 (likely all of which will be rescheduled for 5.0 unless they get claimed soon)
[20:09] <tdonohue> Here's the 4.2 unresolved tickets: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+fixVersion+%3D+4.2+AND+resolution+%3D+Unresolved+ORDER+BY+due+ASC%2C+priority+DESC%2C+created+ASC&mode=hide
[20:09] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+fixVersion+%3D+4.2+AND+resolution+%3D+Unresolved+ORDER+BY+due+ASC%2C+priority+DESC%2C+created+ASC&mode=hide
[20:10] <tdonohue> I'd personally like to see DS-1986 (needs some testing, likely), and also, if anyone can get to it, DS-2042 (but it's unclaimed as of yet) both get in...if possible
[20:11] <kompewter> [ https://jira.duraspace.org/browse/DS-1986 ] - [DS-1986] REST API holds on to context for too long, should use DB pool - DuraSpace JIRA
[20:11] <kompewter> [ https://jira.duraspace.org/browse/DS-2042 ] - [DS-2042] Discovery/Solr is improperly indexing the "dc.description.provenance" field - DuraSpace JIRA
[20:11] <mhwood> DS-2036 just waiting on documentation?
[20:11] <kompewter> [ https://jira.duraspace.org/browse/DS-2036 ] - [DS-2036] DSpace upgrade with oracle database, no discovery results - DuraSpace JIRA
[20:11] <tdonohue> mhwood: yes. 2036 just needs docs
[20:12] <tdonohue> (so 2036 is very low hanging fruit)
[20:13] * monikam_ (~Monika_Me@monika.Princeton.EDU) Quit (Quit: Leaving.)
[20:14] <tdonohue> So, if any of you see any 4.2 scheduled tickets that interest or annoy you, please do feel free to claim them & fix them. I'm also hoping to chip in where I can in the coming few days -- and I'm glad to try and help test/review anything new
[20:15] <tdonohue> Any other comments / thoughts / questions on 4.2 (or any of the tickets still marked for 4.2)?
[20:16] <tdonohue> We could also even do a quick review of remaining 4.2 tickets to see if anyone here is interested in helping push any forward, etc
[20:16] * monikam_ (~Monika_Me@monika.Princeton.EDU) has joined #duraspace
[20:17] <robint> tbh depends on work commitments as to whether I can help out, time will tell
[20:17] <tdonohue> makes sense
[20:17] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Ping timeout: 240 seconds)
[20:19] <tdonohue> So, admittedly, the remainder of the agenda today was essentially "Open Discussion". Are there any other topics / works-in-progress / brainstorms that anyone wants to bring up today?
[20:20] <robint> For bram-atmire and KevinVdV - is the intentention to commit Mirage2 for 5.0 with the dependencies on Compass etc?
[20:20] <bram-atmire> not really much of a topic, but what is the recommended dspace development setting for git line endings cfr https://help.github.com/articles/dealing-with-line-endings
[20:20] <kompewter> [ Dealing with line endings · GitHub Help ] - https://help.github.com/articles/dealing-with-line-endings
[20:20] <bram-atmire> @robint good question
[20:21] <bram-atmire> yes is the short answer
[20:21] <mhwood> Anybody know how much work it would take to bring configurable workflow up to parity with old workflow, so we can deprecate the old and schedule its removal?
[20:21] <bram-atmire> the longer answer is that we found a way for maven to run all that building in sandbox environments
[20:21] <bram-atmire> so unlike our previous beta releases of mirage 2, it would not be required to install all the tools manually
[20:21] <tdonohue> bram-atmire: RE: line endings...our .gitattributes file should take care of it: https://github.com/DSpace/DSpace/blob/master/.gitattributes
[20:21] <kompewter> [ DSpace/.gitattributes at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/.gitattributes
[20:21] <bram-atmire> (unless you want to)
[20:22] <robint> bram-atmire: fair enough. I was looking for a Java alternative to Compass but couldn't find anything good
[20:22] <tdonohue> bram-atmire: i.e. line endings should be normalized by Git, based on our .gitattributes
[20:23] <bram-atmire> this compare seems to do something with the line ending: https://github.com/bram-atmire/DSpace/compare/DSpace:dspace-4_x...bram-atmire:dspace-4_x?expand=1
[20:23] <kompewter> [ Comparing DSpace:dspace-4_x...bram-atmire:dspace-4_x · bram-atmire/DSpace · GitHub ] - https://github.com/bram-atmire/DSpace/compare/DSpace:dspace-4_x...bram-atmire:dspace-4_x?expand=1
[20:23] <bram-atmire> so I don’t know whether I can safely do the pull request here
[20:23] <bram-atmire> @robint: we also tested the deployment on windows and seems to work like a charm
[20:23] <tdonohue> bram-atmire: Good to hear you've found a way to build Mirage2 via maven. Is that in the new Mirage2 github?
[20:24] <bram-atmire> Yes - the code is now open on github, and this is where we are preparing the pull request
[20:24] <bram-atmire> https://github.com/atmire/DSpace/tree/mirage2/dspace/modules/mirage2
[20:24] <kompewter> [ DSpace/dspace/modules/mirage2 at mirage2 · atmire/DSpace · GitHub ] - https://github.com/atmire/DSpace/tree/mirage2/dspace/modules/mirage2
[20:24] <bram-atmire> instead of a separate PDF with docs, we also now have the developer docs as readme.md
[20:25] <tdonohue> bram-atmire: I wouldn't worry about that git diff... I've seen those tiny end-of-file changes before as well, and haven't yet seen any issues with that (Not sure off hand why it happens though)
[20:26] <tdonohue> I'll have to look more closely at that new Mirage2 github then... sounds good
[20:27] <robint> tdonohue: Mirage2 working well for us, although just at testing/development stage
[20:27] <bram-atmire> we still need to provide some explanation why it’s sitting in /dspace/modules
[20:27] <bram-atmire> and not in /dspace-xmlui/
[20:27] <bram-atmire> basically:
[20:28] <bram-atmire> 1. we want it to be optional for now, so completely separate from dspace-xmlui
[20:28] <bram-atmire> 2. if people start doing changes/editing, we would want them to work with the source files in /dspace/modules/mirage2
[20:29] <bram-atmire> so in a sense, we believe the theme SHOULD be customized locally and believe this will make local customization easier and more intuitive
[20:30] <bram-atmire> instead of saying, well, if you want to modify the theme, first copy a directory all the way from /dspace-xmlui/themes into /dspace/modules etc
[20:30] <bram-atmire> anyway, i’m a bit out of my league here because I still need to get the full briefing on this
[20:30] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[20:30] <bram-atmire> we should have all of the reasons lined up when we finalize the pull request
[20:31] <robint> That seems logical, but then that logic would also apply to other themes which remain in dspace-xmlui?
[20:31] <tdonohue> It is a bit confusing....as all other source is under [src]/[some-module] instead of [src]/dspace/modules/[some-module]
[20:32] <cknowles_> would the plan be for it to replace dspace-xmlui?
[20:32] <tdonohue> [src]/dspace/modules/ was (initially) created for localized changes only...this would be the first example (ever) of us distributing source code there
[20:32] <mhwood> tdonohue++
[20:32] <mhwood> I tend to ignore dspace/modules and just keep local branches in our SCM.
[20:33] <tdonohue> I use [src]/dspace/modules/ rather heavily myself for things like Overlays (where I can just overlay a *single* file into the source)....and this would kinda go against the whole idea of overlaying things.
[20:34] <mhwood> Actually it shouldn't be that hard to develop a theme entirely separately, package it in a JAR and just drop it in.
[20:34] <tdonohue> But, at the same time here, I do understand that Mirage2 is a bit unique...it's a theme that requires some sort of "compilation". We don't have a great model for this in DSpace -- it'd almost be better served by a true "plugin" framework
[20:35] <mhwood> (Aspects are harder to package separately, as I'm discovering right now.)
[20:35] <bram-atmire> @cknowles_: Mirage 2 in itself can not replace dspace-xmlui
[20:35] <bram-atmire> because it’s an xmlui theme, so it relies on cocoon just like the other themes do
[20:36] <tdonohue> I guess in the end, I'd want to understand why [src]/dspace/modules/mirage2/ and not either [src]/dspace-xmlui-mirage2/ or [src]/dspace-xmlui/mirage2/.... maybe there are really good reasons that I'm not understand
[20:36] <tdonohue> understanding
[20:36] <bram-atmire> yup, we’re aware of the concerns and we’ll make sure to list the pro’s and con’s that lead to this
[20:36] <bram-atmire> I just don’t have all of them right now here, as Art is out of the office this week
[20:37] <tdonohue> gotcha. understood.
[20:37] <bram-atmire> That’s also the reason why we haven’t done the pull request just yet
[20:37] <bram-atmire> Ideally, we would want to get Mirage 2 in as early as possible
[20:37] <bram-atmire> because we have some other contributions for which we will need to build mirage 2 specific UI
[20:38] <tdonohue> +1 agreed...that way other new features can build into it...rather than ignoring it
[20:38] <bram-atmire> such as the sherpa romeo XMLUI compatibility
[20:38] <bram-atmire> and ORCID
[20:40] <tdonohue> Another option to "throw out" here...is to do something like create a [src]/dspace-xmlui-themes/ folder...and have "mirage2" just be one subfolder there. Just seems slightly odd to have one theme be at the same "level" as all other major modules...but, maybe it's the best we can do for now
[20:41] <tdonohue> in any case...needs some more discussion, once the appropriate folks are back in the office
[20:42] <tdonohue> any other topics to jump to here? I saw that mhwood was asking about Configurable Workflow a ways back in the discussion..
[20:43] <bram-atmire> it was a great question
[20:44] <bram-atmire> but I lack the answer
[20:44] <mhwood> We have two workflows. The new one is way more flexible, but is missing a piece or two and needs to be made default for a release cycle or so before we move the old one out. Anybody know how much work that might be? Could new be brought up to parity in *this* cycle?
[20:45] <KevinVdV> What features are missing in the configurable workflow ?
[20:45] * monikam_ (~Monika_Me@monika.Princeton.EDU) Quit (Quit: Leaving.)
[20:45] <mhwood> Richard Rodgers pointed out something missing w.r.t. curation tasks. I haven't looked into it yet.
[20:45] <tdonohue> My big question on Configurable Workflow is who all uses it? I admit, I do not (for DSpaceDirect)...
[20:46] <tdonohue> it doesn't support curation tasks...that is correct
[20:46] <tdonohue> i.e. automatically kicking off a curation task during a workflow step
[20:46] <mhwood> That definitely should be fixed.
[20:47] <mhwood> It doesn't sound like a lot of work, but I don't know that code well at all.
[20:47] <tdonohue> Do others (here) use Configurable Workflow? I have little experience with it so far, admittedly. I need to try it out more, but haven't found a good reason yet
[20:47] <KevinVdV> Neither do I'm afraid (the curation part, not the configurable workflow part)
[20:47] <robint> tdonohue: not used it yet
[20:48] <mhwood> I've used config. workflow exactly once, unmodified, to smoke-test it after fixing up some database scripts that touch it.
[20:49] <bram-atmire> there was an OR14 presentation
[20:49] <mhwood> But I see an old workflow and a new workflow, and ask myself why we need two, and wouldn't it be better to make the new one *the* workflow since enabling it one's self is kind of a pain.
[20:49] <bram-atmire> featuring a very elaborate thesis workflow
[20:49] <bram-atmire> built on the configurable workflow
[20:49] <bram-atmire> let me see if i can find it ..
[20:51] <bram-atmire> https://www.doria.fi/handle/10024/97531
[20:51] <kompewter> [ It’s a workflow engine. It’s working with linked data. It’s repository! – Supporting electronic thesis related processes in University of Helsinki library ] - https://www.doria.fi/handle/10024/97531
[20:52] <tdonohue> I think my one worry here is that it may not be widely used (by most users). We should work to resolve that, and get more experience with it, as it seems like a good improvement to workflow in general. But, I don't know what all is involved in making it "on by default" in DSpace 5 or 6
[20:54] <mhwood> If it's certain that cfg. workflow doesn't support attached tasks then I will write up a ticket to capture that, and perhaps I can work on it.
[20:55] <robint> Maybe one of our aims for 6 should be to rationalise some of these options
[20:55] <tdonohue> And, we'd probably want to somehow "default" Configurable Workflow to "look like" the traditional workflow (if that's even possible)... IIRC, it doesn't by default, or does it?
[20:56] <KevinVdV> The look and feel for the end user/admin should be almost identical
[20:56] <KevinVdV> By default
[20:56] <mhwood> I thought it looked very like the old one by default.
[20:56] <tdonohue> oh, ok. I'm mistaken then :)
[20:57] <tdonohue> robint ++ (regarding "rationalising some of these options")
[20:58] <mhwood> Yes, I also have Ds-1390 (ConfigurationManager vs. ConfigurationService) on my want-to-fix-for-5.0 list
[20:58] <tdonohue> we probably need a ticket for "Turning on Configurable Workflow by default" too. That way we can attach other tasks to it as needed/discovered
[20:59] <mhwood> Will do that ticket right now.
[20:59] <tdonohue> thanks, mhwood!
[21:00] <tdonohue> Ok. Any final topics here? Noticing we are near the 1 hour mark. And I'd rather not go over too much today, World Cup considering (currently at half time)
[21:01] <mhwood> Ticket submitted, linked to "curation task support" ticket.
[21:01] <tdonohue> Not hearing any other topics. So, we'll close out for today. Reminder, if you have a moment over the next week, help us on any of the final 4.2 tickets!
[21:01] <bram-atmire> thanks Tim!
[21:02] <robint> Cheers all
[21:02] <tdonohue> enjoy the rest of the World Cup game! ;)
[21:02] * bram-atmire (~bram@94-225-35-170.access.telenet.be) Quit (Quit: bram-atmire)
[21:02] * robint (5eaf588c@gateway/web/freenode/ip.94.175.88.140) Quit (Quit: Page closed)
[21:02] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:02] <cknowles_> bye
[21:02] <kompewter> see ya!
[21:02] <KevinVdV> Don't mind if I do !
[21:02] * cknowles_ (~cknowles@cpc19-sgyl35-2-0-cust180.18-2.cable.virginm.net) has left #duraspace
[21:03] * KevinVdV (~KevinVdV@d5153D041.access.telenet.be) Quit (Quit: KevinVdV)
[22:06] * 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.