Timestamps are in GMT/BST.
[6:49] -hubbard.freenode.net- *** Looking up your hostname...
[6:49] -hubbard.freenode.net- *** Checking Ident
[6:49] -hubbard.freenode.net- *** Found your hostname
[6:49] -hubbard.freenode.net- *** No Ident response
[6:49] * DuraLogBot (~PircBot@atlas.duraspace.org) 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.188.8.131.52 on Fri Oct 22 01:19:41 UTC 2010
[10:21] * fasseg (~fas@HSI-KBW-095-208-193-241.hsi5.kabel-badenwuerttemberg.de) Quit (Remote host closed the connection)
[12:10] * mhwood (firstname.lastname@example.org) has joined #duraspace
[13:02] * tdonohue (~email@example.com) has joined #duraspace
[15:56] * hpottinger (~firstname.lastname@example.org) has joined #duraspace
[18:13] * helix84 (~email@example.com) has joined #duraspace
[19:09] * PeterDietz (~firstname.lastname@example.org) has joined #duraspace
[19:57] * pbecker (5cce7344@gateway/web/freenode/ip.184.108.40.206) has joined #duraspace
[19:57] * l_a_p (~email@example.com) has joined #duraspace
[19:58] * bollini (~firstname.lastname@example.org) has joined #duraspace
[20:00] <tdonohue> Hi all, it's time for our weekly DSpace Developers Meeting. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-09-11
[20:00] <kompewter> [ DevMtg 2013-09-11 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-09-11
[20:01] <tdonohue> We'll start off with a few Pull Request reviews...here's our open PRs: https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:01] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:01] <tdonohue> the next one due for review is #283: https://github.com/DSpace/DSpace/pull/283 DS-1633
[20:01] <kompewter> [ DS-1633 Sherpa/Romeo integration in the submission upload step by abollini · Pull Request #283 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/283
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-1633 ] - [#DS-1633] Sherpa/Romeo integration in the submission upload step - DuraSpace JIRA
[20:04] * pbecker (5cce7344@gateway/web/freenode/ip.220.127.116.11) Quit (Quit: Page closed)
[20:04] <tdonohue> Sherpa/Romeo integration is a nice idea. Just not sure I fully understand how this implementation works. Might be nice to have a screenshot or two. I like that it can be easily enabled/disabled.
[20:04] * pbecker (5cce7344@gateway/web/freenode/ip.18.104.22.168) has joined #duraspace
[20:04] <bollini> It can be turned off, it is enabled by default. The sherpa/romeo data are loaded via ajax so no performance issues for the submission if there are any network problems
[20:05] <helix84> big plus that this is a service, so could be used from XMLUI, too
[20:05] <tdonohue> (seems slightly odd to have this integration be part of the *upload* step, rather than part of the metadata capture step, or possibly the "review" step...but again, maybe if I saw a screenshot it'd make more sense)
[20:06] <bollini> it make sense in the upload step because sherpa/romeo tell about permission for fulltext
[20:06] <bollini> I can add a screen tomorrow, I already use the last API from sherpa but I want to check that also the schema is ok
[20:06] <tdonohue> bollini: oh, I see. So, it can warn folks that they shouldn't upload the publishers PDF, if they aren't allowed to (for example)
[20:07] <tdonohue> ok, that makes sense
[20:07] <tdonohue> I agree with helix84 - glad this is a service, and I hope that'll make it easier to "port" over to XMLUI as well
[20:07] <bollini> tdonohue: exactly and I plan to extend it to the advanced embargo as soon as I complete the review of the zuki PR
[20:08] <tdonohue> in that case, I'm +1 this feature. I like it (and I hope we can find someone to also port it to the XMLUI at some point)
[20:08] * cknowles (81d70406@gateway/web/freenode/ip.22.214.171.124) has joined #duraspace
[20:08] <helix84> also +1 to the idea; haven't tried the implementation
[20:09] <mhwood> +1 to the idea.
[20:09] <hpottinger> I might be up for the port to XMLUI, we have folks here interested in this feature
[20:09] <snail> i think it's a great idea
[20:10] <bollini> the fast root to port to the xmlui is to use the same servlet to produce the sherpa/romeo data and include them via ajax in the upload screen
[20:10] <mhwood> I wouldn't say I did a thorough review, but a quick look over the files looks good.
[20:10] <helix84> bollini: that would require JSPUI to be deployed, right?
[20:11] <helix84> ideally, that servlet would be a part of REST API if we had one
[20:11] <bollini> helix84: you can copy the servlet in the xmlui web.xml (not the best solution but it works)
[20:12] <tdonohue> my only question with 1633 is around RichardRodgers similar "MetadataWebService" curation task. It also claims to support Sherpa/Romeo integration: DS-1647 (But admittedly, I like the move towards AJAX that bollini has been doing)
[20:12] <kompewter> [ https://jira.duraspace.org/browse/DS-1647 ] - [#DS-1647] Curation Task for Consuming Web Services - DuraSpace JIRA
[20:12] <bollini> that servlet actually produce an html that is "embedded" via ajax in the upload screen
[20:12] <tdonohue> (just wanted to note we have two different integrations with Sherpa/Romeo in two different PRs)
[20:13] <bollini> tdonohue: it is a different integration. You can get the publisher name from sherpa if you know the ISSN
[20:15] <tdonohue> bollini: ok. I'm not against having two separate Sherpa/Romeo calls (for different purposes). Just would be nice to not duplicate too much in different places (obviously)...and it looks like (at a glance) there isn't much duplication between 1633 and 1647
[20:15] <mhwood> Would have to duplicate the servlet code as well, or invent a new place for common servlets to live.
[20:16] <mhwood> (Between JSPUI and XMLUI, I mean.)
[20:17] <helix84> i'm not thrilled at the idea of injecting HTML into an XMLUI page; but I've done one RoMEO integration and I understand the need for the servlet to bypass cross-domain policy. I'd accept this as it is for 4.0 and keep in mind to rewrite it in a suitable manner for the REST API later.
[20:18] <hpottinger> oh common business logic layer, where are you?
[20:19] <tdonohue> So, it sounds like we are in agreement that 1633 is a "good idea". Just some questions about the best way to "share" code between JSPUI & XMLUI. But, at the very least, it sounds like the JSPUI version should probably get into 4.0 (and we should look into how to then port it to XMLUI)
[20:20] <bollini> ok, I will try to make the final check tomorrow and get this in early so to help others to port to xmlui
[20:20] <mhwood> Sharing code with XMLUI is something on which we need not wait, since there is as yet nothing in XMLUI to use the shared code.
[20:21] <helix84> mhwood++
[20:21] <tdonohue> mhwood++ yea, we can go forward with JSPUI first...then figure out how to share over to XMLUI later
[20:21] <tdonohue> I added one minor comment to the PR: https://github.com/DSpace/DSpace/pull/283 Beyond that, I'm OK with it
[20:21] <kompewter> [ DS-1633 Sherpa/Romeo integration in the submission upload step by abollini · Pull Request #283 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/283
[20:23] <tdonohue> Ok. We're already a good 20 minutes in. So, I'm going to stop there for now. We can do some more PR reviews later on, if we have extra time (or feel it's a better use of our time today)
[20:23] <bollini> tdonohue: should we make this change as part of the XMLUI port or should we start immediately with the new name?
[20:25] <tdonohue> bollini: regarding the configuration name...it seems like it'd might be worth going with a more "generic" name, just so we don't have to switch the config later on. For example, if the config is "jspui." in 4.0, but changes to "webui." in 5.0, then folks need to go migrate their configurations over
[20:25] <helix84> bollini: please, change it to webui now
[20:26] <bollini> tdonohue helix84: ok
[20:26] <tdonohue> Ok, so moving on, the main topic for today is 4.0. I just wanted to leave us some time here to discuss the 4.0 status, or bring up anything that needs immediate "eyes" for 4.0
[20:27] <tdonohue> (There will obviously be an ongoing "placeholder" in this meeting for 4.0....so, even if there's nothing pressing this week, feel free to bring things to a future meeting)
[20:27] <helix84> Off-topic: Elias just replied that submitting an updated mobile theme before the deadline is on his to-do list
[20:28] <bollini> I think that this PR https://github.com/DSpace/DSpace/pull/289 need to be merged soon
[20:28] <kompewter> [ [DS-1623] Upgrade DSpace-SOLR to SOLR 4 by lap82 · Pull Request #289 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/289
[20:28] <bollini> SOLR will be a primary actor of dspace 4 with the switch on by default of discovery
[20:28] <tdonohue> As a friendly reminder of our 4.0 Timelines : we've got ~3.5 weeks until "Deadline for feature Pull Request" (Oct 7) -- our first official "deadline"
[20:29] <bollini> if someone can help with test (elastic search and OAI module) we should be ready to merge
[20:29] <tdonohue> +1 to DS-1623 / PR#289. We should make sure to keep our Solr up-to-date.
[20:30] <kompewter> [ https://jira.duraspace.org/browse/DS-1623 ] - [#DS-1623] Upgrade DSpace-SOLR to SOLR 4 - DuraSpace JIRA
[20:30] <tdonohue> elastic search testing -> glancing over at PeterDietz
[20:30] <helix84> I'll ping Joao about OAI on Solr 4
[20:31] <PeterDietz> I haven't tested any of the upgrade to es0.90, I've been meaning to
[20:31] <tdonohue> To be honest, RE:1623. As long as things don't "break horribly" (i.e. completely crash), we will get plenty more testing in during Testathon. But, it would be nice to do a quick check of Elastic Search & OAI
[20:32] <mhwood> I agree. If it just needs some adjustment, let's get it in and find out where.
[20:32] <tdonohue> PeterDietz: the upgrade to es0.90 is *included* in PR#289. Would you have a chance to pull it down and run a quick test?
[20:33] <PeterDietz> yeah, I'll pull it down and test it
[20:33] <tdonohue> thanks, PeterDietz
[20:34] <tdonohue> In general though, as long as we get a few folks to run a quick test that things don't crash, I'd say we should get PR#289 into master as soon as possible
[20:34] <helix84> email to Joao sent
[20:35] <mhwood> If upgrading ES *does* cause issues, who will have time to sort them out?
[20:36] <tdonohue> mhwood: probably depends on the extent of the issues, if any. Hopefully it *doesn't* :)
[20:36] * pbecker (5cce7344@gateway/web/freenode/ip.126.96.36.199) Quit (Quit: Page closed)
[20:36] <hpottinger> "time [hopefully does not matter]" --tdonohue
[20:38] <tdonohue> this is always one of the "risks" we take on though as we diversify options (e.g. Elastic Search or Solr, JSPUI or XMLUI). We have to continually find time to maintain the diversified array of options. So far we've done great doing so with JSPUI/XMLUI...just a matter of finding more folks who want to help bring Elastic Search forward similarly
[20:39] <tdonohue> (i.e. Elastic Search is gonna have a rough road ahead if it's only ever just PeterDietz. Hopefully we find more users/developers there)
[20:39] <tdonohue> in any case..enough about that
[20:40] <hpottinger> pretty sure we will, ES makes GitHub go
[20:40] <tdonohue> oh, I'm not doubting the usefulness of ES (and I've heard a ton of great things about ES)...just noting that we have a lack of ES support within our "DSpace Developer group" thus far.
[20:42] <PeterDietz> I use ES every day. I've done a bunch of things to our instance today even. I'll try to find time to check this out. (I've just pulled down the PR branch)
[20:42] <tdonohue> So, any other pressing 4.0 topics / PRs / Jira tickets? As noted, we are at about 3.5 weeks until the first deadline...so, I expect things will keep ramping up over the next weeks
[20:43] <mhwood> Time to make a list of things that look like "big stuff" and start asking their contributors if there's any way the RT can help.
[20:44] <bollini> I have a lot of PRs that are related one to the other so the integration phase could be time consuming for me. It will be helpful if I can get an agreement about commit them in advance
[20:46] <mhwood> Is there a list of these, in order (if order is important)?
[20:46] <helix84> bollini: I suggest you make a list so we can review them next week
[20:47] <bollini> #287 #274 will conflict with #289
[20:47] <bollini> https://github.com/DSpace/DSpace/pull/287 https://github.com/DSpace/DSpace/pull/274
[20:47] <kompewter> [ DS-1106 Solr search accent insensitive (ICU Transliteration) by abollini · Pull Request #287 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/287
[20:47] <kompewter> [ DS-1620 Facet date range is sometimes incorrect by abollini · Pull Request #274 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/274
[20:48] <tdonohue> PeterDietz: you may have misunderstood me. My point is that we only have one committer (you) working on DSpace + ES thus far. I just wanted to encourage others to step in and help so that "ES questions" are not always "PeterDietz questions". :) I'm pointing out we need to find more ES support within our group to make DSpace + ES move forward more quickly/smoothly. Just trying to encourage others to chip in / help maintain it.
[20:50] <mhwood> So we need to get 287 and 274 in first, and then 289 can be cleaned up?
[20:50] <bollini> no I want to do the inverse as 289 is the most large
[20:51] <snail> on an unrelated note (since I have to go AFK soon) based on https://jira.duraspace.org/browse/DS-1645 I wrote https://wiki.duraspace.org/display/DSPACE/ODBC+External+Reporting with a few tweaks from helix84. all feedback welcome, even if it's "we use X and you didn't mention X"
[20:51] <kompewter> [ [#DS-1645] support for connecting to institutional reporting tools - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1645
[20:51] <kompewter> [ ODBC External Reporting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/ODBC+External+Reporting
[20:51] <kompewter> [ https://jira.duraspace.org/browse/DS-1645 ] - [#DS-1645] support for connecting to institutional reporting tools - DuraSpace JIRA
[20:51] <bollini> but this will require some work on my side after that 289 is in
[20:51] <tdonohue> yea, seems like we get #289 (Solr4) in ASAP, then rebase/re-test 287 & 274 on the new Solr 4.
[20:52] <helix84> snail: well, I imagined you'll put the actual SQL snippets on the wiki page. It's much easier to look at them there than in Jira comments.
[20:53] <snail> helix84: fair enough
[20:54] <bollini> if you agree I will try to go ahead fast, put in all the SOLR staff as soon as no break are revealed so to give time to test well all togheter
[20:54] * l_a_p (~email@example.com) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812])
[20:54] <helix84> snail: other than that, I don't think we will "do" anything with them at this time - rather it's nice to finally have a place where useful SQL reporting commands can be put and found in one place
[20:55] <hpottinger> A while back I was looking at command-line-based ODBC database interfaces
[20:55] <helix84> bollini: only with Solr 4 I'd prefer if you gave Peter and Joao a few days to test
[20:57] <bollini> helix84: yes, with no break I mean that I want wait for *only* a first rough check of ES and OAI
[20:57] <mhwood> bollini++
[20:57] <tdonohue> +1 for just waiting for a "rough check" of ES & OAI
[20:58] <bollini> but after that I want to put in also the other two fix as soon as possible to avoid other tester to have to reindex more and more their data to check the new configuration
[20:59] <bollini> ok, thanks. I will appreciate if you can also give a fast comment about https://github.com/DSpace/DSpace/pull/292
[20:59] <kompewter> [ DS-1639 AJAX progress bar for file upload in JSPUI by abollini · Pull Request #292 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/292
[21:00] <helix84> bollini: try to ping zuki about reviewing JSPUI features
[21:00] <bollini> this PR will conflict with many other PR (advanced embargo, sherpa/romeo, private item meaning review - not yet send) so it will be helpful for me to know if I can rebase and merge it as soon as I have completed the review of the advanced embargo porting
[21:01] <helix84> personally, I think it's a very beneficial feature and nice implementation, as we already discussed it
[21:03] <tdonohue> PR #292 / DS-1639 seems like a good idea to me too. My only comment (added to the JIRA ticket) was to rename your configuration setting.
[21:03] <kompewter> [ https://jira.duraspace.org/browse/DS-1639 ] - [#DS-1639] AJAX progress bar for file upload in JSPUI - DuraSpace JIRA
[21:05] <bollini> tdonohue: thanks to have highlighted that, I had missed your comment on JIRA (it is not easy track things on two side PR and JIRA)
[21:05] <tdonohue> also, it may need to be disabled by default since you said it doesn't work in IE < 10 (unless it "fails" cleanly and the upload still works in IE 8 or 9)
[21:06] <bollini> tdonohue: no, it works. It is the jquery plugin that don't work with IE < 10
[21:06] <tdonohue> oh, I misunderstood. Nevermind then
[21:07] <bollini> this is the only thing that I dislike of this contribution... I have had to write my "uploader" by hand using "old" technique of iframe and server side progress
[21:08] <tdonohue> bollini: yea, I agree, that's not the "neatest" way of doing things. But, we can always try to improve it / enhance it later
[21:09] <tdonohue> Ok, we're over time here today. Sorry about that. I'll be around for a bit longer though, if there's other topics to discuss. No more "official" meeting topics though
[21:09] <helix84> bollini: I just added a tiny comment to the issue
[21:10] <mhwood> Got to go. Thanks, all.
[21:10] * mhwood (firstname.lastname@example.org) has left #duraspace
[21:11] <bollini> helix84: thanks... you are right but it is no so easy :-( I will try
[21:11] <helix84> bollini: it's not a show-stopper if you won't do it
[21:12] <bollini> off topic: what do you think should be the browser compliance out-of-box for dspace?
[21:13] <helix84> I don't know - what's in the latest service pack of Windows 7?
[21:13] <bollini> I have noted that jquery has started to unsupport < IE9
[21:13] <helix84> As Tim said, it also matters whether it fails gracefully
[21:14] <bollini> it is no so easy... twitter don't support < IE8
[21:14] <tdonohue> "Failing gracefully" is most important.
[21:14] <bollini> it redirect to the mobile site and ask to upgrade
[21:14] <helix84> I'd prefer not to be too conservative - by the time people will start adopting DSpace 4 en masse, the browser landscape will have moved significantly
[21:14] <tdonohue> I'd say we could look at major sites like twitter as a good reference...chances are, if you cannot use twitter from your browser, than you cannot be expected to use DSpace ;)
[21:14] <bollini> just to be clear this is not related to any PR that is already in
[21:15] <bollini> I'm facing this problem with the new theme for jspui
[21:16] <tdonohue> That being said, for IE we probably need to go back to Windows XP (sorry, some libraries are still back there, esp. public libraries). The latest version of IE that even *runs* on Windows XP is IE 8.
[21:16] <helix84> tdonohue: the difference between dspace and twitter is that twitter is a web service, so it has to work now. DSpace will be used for years, so we can shed legacy support a bit more aggresively.
[21:17] <bollini> actually it works pretty well in IE8 with some workaround but I'm not able to get it works fine with IE7
[21:18] <helix84> About a year ago a website I made a few years back was reported slightly broken on IE7. I had to ignore it because I couldn't find any computer with IE7 anymore :(
[21:18] <tdonohue> I think supporting IE8 and above is fine...we probably don't need to go all the way back to IE7
[21:19] <hpottinger> wait, Microsoft makes an image for testing IE compatiblity
[21:19] <snail> this aggressive approach only works for things like submission and search, direct access to items found via google scholar and etc should work from a much broader range of browsers
[21:19] <hpottinger> http://www.microsoft.com/en-us/download/details.aspx?id=11575
[21:19] <tdonohue> But, I do think we need to support IE8, just because of Windows XP (which is still in rather wide use, unfortunately): http://www.troyhunt.com/2013/01/the-impending-crisis-that-is-windows-xp.html
[21:19] <kompewter> [ Troy Hunt: The impending crisis that is Windows XP and IE 8 ] - http://www.troyhunt.com/2013/01/the-impending-crisis-that-is-windows-xp.html
[21:19] <kompewter> [ Download Internet Explorer Application Compatibility VPC Image from Official Microsoft Download Center ] - http://www.microsoft.com/en-us/download/details.aspx?id=11575
[21:21] <helix84> hpottinger: there used to be a pack that helped you install several IE versions in parallel, so you could run whichever version you wanted. But it was discontinued, I don't remember the name anymore.
[21:21] <hpottinger> helix84, I think I just linked it?
[21:22] <hpottinger> looks like a whole lot of downloading required, though
[21:22] <helix84> hpottinger: no, these are separate VMs. The pack was an installer of the actual programs.
[21:22] <bollini> for IE7, IE8 you can also use an IE9 browser change the compatibility settings... or I'm wrong?
[21:22] <tdonohue> yea, there are now "browser compatibility settings" in more modern versions of IE
[21:23] <helix84> bollini: you can use the legacy rendering mode, but in my experience that doesn't mean it will work in the older version 100%
[21:24] <helix84> (but my experience with IE is quite outdated now)
[21:25] <helix84> http://www.askvg.com/how-to-run-multiple-internet-explorer-versions-simultaneously/
[21:25] <kompewter> [ Internet Explorer Collection: Run Multiple IE Versions Simultaneously - Tweaking with Vishal ] - http://www.askvg.com/how-to-run-multiple-internet-explorer-versions-simultaneously/
[21:26] <helix84> here's something similar, never tried this one
[21:27] <bollini> anyway is it nice to know that we at most agree to use IE8+, probably if dspace will make clear a requirement in this direction it will help us (developer and service provider) to convince also reluctant users
[21:30] <bollini> I need to go... thanks to all for your time! see you next week
[21:34] * cknowles (81d70406@gateway/web/freenode/ip.188.8.131.52) Quit (Quit: Page closed)
[21:34] * bollini (~email@example.com) Quit (Ping timeout: 245 seconds)
[21:52] * helix84 (~firstname.lastname@example.org) Quit (Quit: helix84)
[22:09] * tdonohue (~email@example.com) has left #duraspace
[22:25] * hpottinger (~firstname.lastname@example.org) Quit (Quit: Later, taterz!)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.