Timestamps are in GMT/BST.
[0:21] * griffinj (0ce778c7@gateway/web/cgi-irc/kiwiirc.com/ip.12.231.120.199) has joined #duraspace
[1:39] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Remote host closed the connection)
[1:39] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[1:43] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Ping timeout: 246 seconds)
[1:47] * griffinj (0ce778c7@gateway/web/cgi-irc/kiwiirc.com/ip.12.231.120.199) Quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
[1:53] * griffinj (0ce778c7@gateway/web/cgi-irc/kiwiirc.com/ip.12.231.120.199) has joined #duraspace
[1:57] * griffinj (0ce778c7@gateway/web/cgi-irc/kiwiirc.com/ip.12.231.120.199) Quit (Client Quit)
[3:41] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[3:45] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Ping timeout: 246 seconds)
[6:39] -adams.freenode.net- *** Looking up your hostname...
[6:39] -adams.freenode.net- *** Checking Ident
[6:39] -adams.freenode.net- *** Found your hostname
[6:39] -adams.freenode.net- *** No Ident response
[6:40] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:40] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:40] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:52] * helix84_ (~ctenar@195.178.95.132) has joined #duraspace
[6:55] * helix84 (~ctenar@195.178.95.132) Quit (Ping timeout: 272 seconds)
[7:42] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[7:47] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Ping timeout: 272 seconds)
[10:54] * phil1 (~Adium@89.101.211.218) has joined #duraspace
[11:44] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[11:48] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Ping timeout: 245 seconds)
[12:50] * phil1 (~Adium@89.101.211.218) Quit (Quit: Leaving.)
[13:09] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:09] * phil (~Adium@89.101.211.218) has joined #duraspace
[13:33] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[14:06] * phil (~Adium@89.101.211.218) Quit (Quit: Leaving.)
[14:32] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[15:43] * awoods (~awoods@70.114.129.113) has joined #duraspace
[16:15] * phil1 (~Adium@89.101.211.218) has joined #duraspace
[16:15] * phil1 (~Adium@89.101.211.218) has left #duraspace
[17:11] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) has joined #duraspace
[17:28] * phil1 (~Adium@89.101.211.218) has joined #duraspace
[17:39] * phil1 (~Adium@89.101.211.218) Quit (Quit: Leaving.)
[19:47] <tdonohue> REMINDER TO ALL: the DSpace Developers Meeting starts in 13mins (20:00UTC or 3:00pm EST)
[19:59] * kstamatis (b03a8b00@gateway/web/freenode/ip.176.58.139.0) has joined #duraspace
[20:00] * bollini (~bollini@host3-252-dynamic.7-87-r.retail.telecomitalia.it) has joined #duraspace
[20:02] <tdonohue> Hi all, It's time for the DSpace Developers Mtg.
[20:02] <tdonohue> Unfortunately, the DuraSpace wiki just crashed...so, I cannot link to the agenda
[20:04] <tdonohue> We have someone looking into the wiki crash... here's the agenda page for when it returns: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-11-06
[20:05] <tdonohue> So, we're gonna do this meeting "on the fly"
[20:05] <tdonohue> The main topic for today is obviously DSpace 4.0 and the Testathon
[20:06] <tdonohue> There were some specific JIRA tickets logged recently that I wanted to be sure we looked at and discussed today (but others are free to add more)
[20:06] <tdonohue> first was DS-1749
[20:06] <kompewter> [ https://jira.duraspace.org/browse/DS-1749 ] - [DS-1749] Graceful deprecation for different index update launcher commands - DuraSpace JIRA
[20:07] <bollini> just note, the dspace wiki is now running
[20:07] <tdonohue> (which has also been logged as a "bug" by a testathon user as DS-1762)
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-1762 ] - [DS-1762] When run command "dspace index-init" - DuraSpace JIRA
[20:07] <tdonohue> thanks bollini
[20:07] <tdonohue> agenda page again: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-11-06
[20:07] <kompewter> [ DevMtg 2013-11-06 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-11-06
[20:08] <bollini> tdonohue: I only noted that someone other has fixed
[20:08] <tdonohue> right, I meant thanks for letting me know the wiki is back :)
[20:09] <mhwood> 1749: there seems to be some confusion about whether Lucene indexing is still supported.
[20:09] <helix84_> hi everyone
[20:09] <bollini> DS-1749 hide also a bug in the current installation process
[20:09] <kompewter> [ https://jira.duraspace.org/browse/DS-1749 ] - [DS-1749] Graceful deprecation for different index update launcher commands - DuraSpace JIRA
[20:09] <bollini> looking to https://github.com/DSpace/DSpace/blob/master/dspace/src/main/config/build.xml#L949
[20:09] <kompewter> [ DSpace/dspace/src/main/config/build.xml at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace/src/main/config/build.xml#L949
[20:10] <helix84_> I actually have a comment on 1749 I haven't had time to write up
[20:10] <bollini> we are still running DSIndexer during the installation process
[20:10] <tdonohue> So, regarding Ds-1749, it seems like we have a few options here... (1) we change the default "dspace index" to point at Discovery instead of Lucene, or (2) we change all our docs to tell people to no longer user "dspace index" unless they are using Lucene
[20:10] <helix84_> I think renaming the update-discovery-index to index-init/index-update is a really bad idea
[20:10] <tdonohue> bollini: that's a good point. Definite bug
[20:11] <helix84_> it will lead to much confusion and questions
[20:11] <helix84_> as it is now, it's easy to explain which command uses which backend
[20:12] <tdonohue> helix84_ : I actually worry the other route will cause too much confusion. In all our docs (all over the place) we have mentiosn of "dspace index"...and if we don't find all mentions and change them, people will report errors
[20:12] <mhwood> Add a warning: "Solr index is default -- are you sure?"
[20:12] <helix84_> but if we start mixing commands and dspace versions... I really don't want to answer those questions
[20:12] <bollini> I agree with Ivan... probably we should remove the DSIndexer from the auto-running script in fresh_install and change the documentation to say what script they need to run. mhwood: good suggestion too
[20:12] <mhwood> Indeed, the old commands should continue to do what they have done until they are no longer supported.
[20:12] <helix84_> tdonohue: I'll be happy to fix the docs
[20:13] <tdonohue> well, the other route is to not let *anything* use "dspace index". All commands are changed to "dspace index-lucene" or "dspace index-solr" and "dspace index" just reports that you need to use the other commands
[20:13] <helix84_> mhwood: where should that warning appear?
[20:13] <hpottinger> +1 mhwood, +1 backwards compatibility, especially where cron jobs are involved
[20:14] <mhwood> When you run "dspace index" it can remind you that perhaps you no longer want to do that.
[20:14] <helix84_> tdonohue: it's a false choice. the third way is to let the commands do what they do now and educate the users
[20:14] <helix84_> mhwood,,
[20:14] <helix84_> mhwood++
[20:14] <mhwood> Idea off the top of my head: "dspace index --lucene", "dspace index --solr". I have no idea yet whether this is good or bad.
[20:15] <tdonohue> my problem is that (in my mind) "dspace index" should re-index DSpace (as the command implies). If "dspace index" now just throws errors by default, how does that help?
[20:15] <mhwood> Can the command look at the config. to see which it should do? or, at least, definitely say "this won't work"?
[20:16] <tdonohue> I agree I'd love to have "backwards compatibility"...but if by default it throws errors, that's also not backwards compatibility
[20:16] <helix84_> ok, actually - and I hope you believe me when I say that - "dspace index" is not discussed all that much _on the lists_. we usually deal with index-init/index-update and update-discovery index.
[20:16] <tdonohue> mhwood: I like that conceptually...just not sure how to do that
[20:16] <bollini> mhwood: so simple so good!
[20:16] <helix84_> I don't have a strong opinion on what "dspace index" should do, only that the other three should continue to do what they do
[20:17] <helix84_> and that wouldn't throw any errors
[20:17] <bollini> why not look to the configuration as mhwood propose and just do the right work?
[20:17] <helix84_> but it would update an index that is not used by default (a situation we've had since 1.8)
[20:18] <helix84_> so I suggest to add a text to each of those commands to say which index it's updating
[20:18] <tdonohue> that's wrong, helix84_. In a default installation of DSpace 4.0, "dspace index-init" and "dspace index-update" will throw errors. See DS-1762
[20:18] <kompewter> [ https://jira.duraspace.org/browse/DS-1762 ] - [DS-1762] When run command "dspace index-init" - DuraSpace JIRA
[20:18] <helix84_> tdonohue: I see, that's because of ItemCounterDAOSolr.
[20:19] <tdonohue> I like mhwood's idea to see if we can change "index", "index-init" and "index-update" to be "smart" and index based on configs.. just not sure how hard that'd be
[20:20] <bollini> discovery/lucene is easy to individuate for jspui but hard for xmlui
[20:20] <helix84_> first problem there is - AFAIK there's no _single_ config property that changes which index is used
[20:22] <bollini> the browse init should can always run (just do nothing with solr)
[20:22] <bollini> the ItemCounter is needed if we use cache https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L972
[20:22] <kompewter> [ DSpace/dspace/config/dspace.cfg at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L972
[20:22] <tdonohue> helix84_ : IIRC, mhwood had a way of telling whether Discovery or Lucene is enabled in the new "./dspace version" command... looking for it now
[20:23] <PeterDietz> can't you have both indexes at the same time? Its just a config change to switch discovery-ui on/off. I would say to leave the commands be explicity (un-smart), and have the repo administrator type in which index they are updating
[20:23] <tdonohue> here it is..he's parsing the "enabled" event consumers: https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/app/util/Version.java#L61
[20:23] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/app/util/Version.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/app/util/Version.java#L61
[20:24] <mhwood> Thanks, I had forgotten.
[20:24] <bollini> we can have both index in use... one from an UI one from the other
[20:24] <bollini> this is what we have done in the demo site until dspace 3
[20:24] <PeterDietz> Thus, I guess lucene-index-update becomes new, and index-update gets deprecated/killed, and discovery-index-update stays.
[20:24] <bollini> just note that, I don't recommend that...
[20:24] <mhwood> So, each type of index manipulator could look at the config. and see whether it is enabled.
[20:25] <helix84_> As Peter and Andrea pointed out, it's not so simple. Moreover, the consumer is not the only option that decides.
[20:25] <tdonohue> PeterDietz: I'm ok with that. But it's misleading that Lucene indexing is generically named ("index", "index-init", "index-update"), while the default Discovery indexing is oddly named ("update-discovery-index"). It seems like they both should say what index they work against
[20:25] <tdonohue> oh, I see PeterDietz just said the same thing by suggestiong "update-lucene-index" or similar
[20:25] <helix84_> it's a good idea, let's just make the naming consistent - update-lucene-index
[20:25] <mhwood> tdonohue: yes, we should destroy the specific commands and just have "index", which can be told which you mean and can discover whether it should refuse to run on that index.
[20:26] <tdonohue> mhwood++
[20:26] <tdonohue> I'd rather this all be "./dspace index --lucene" and "./dspace index --discovery", which is what mhwood seems to be saying...
[20:27] <hpottinger> OK, if we destroy the old commands, we need to document the changes in the upgrade docs.
[20:27] <mhwood> Yes, that's what I'm saying.
[20:27] <helix84_> if we want to have any sort of smart decisionmaking, we need to sort 2 things out: 1) single config option for turning on discovery 2) what if someone wants to use both indexes
[20:27] <bollini> I'm still thinking that it will be nice to have dspace index to do the right job without user prompt
[20:28] <bollini> dspace index need to run all the needed scripts
[20:28] <mhwood> There are two different pieces of indexing: (1) which indexing service(s) you feed, and (2) which one you use in a UI.
[20:28] <bollini> so we just need to list all the scripts and found a parameter that say if we need to run it or not
[20:28] <tdonohue> "./dspace index" could just "do the right thing" by checking to see if you have Discovery or Lucene enabled. But, you can specifically run "./dspace index --lucene" and "./dspace index --discovery" to force a specific indexing
[20:29] <helix84_> tdonohue: that would be logical if we had a single option. see mhwood's comment.
[20:29] <tdonohue> helix84_ sorry, I misstated...I meant this:
[20:30] <mhwood> Well, DTRT could mean "init/update/whatever all the services that are enabled".
[20:30] <tdonohue> ./dspace index -> Would index Discovery or Lucene (OR BOTH) depending on config settings
[20:30] <bollini> wait I think that we are doing confusion here
[20:30] <bollini> https://github.com/DSpace/DSpace/blob/master/dspace/config/launcher.xml#L123
[20:30] <kompewter> [ DSpace/dspace/config/launcher.xml at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace/config/launcher.xml#L123
[20:30] <helix84_> not smart, but I don't have a problem with it :)
[20:31] <bollini> dspace index run org.dspace.browse.IndexBrowse
[20:31] * lap1 (~l.pascare@95.235.235.192) has joined #duraspace
[20:31] <mhwood> Good point. People already have habits related to "index" too. Ugh.
[20:32] <helix84_> I think we should write down all the options and problems to help us decide
[20:32] <helix84_> rushing this will only lead to confusion
[20:33] <helix84_> for example, I'd like to take the time to review all config options related to indexing
[20:34] <tdonohue> So, anyone want to jot down the various options on a wiki page or something for us to work from? We just need to get this moving forward
[20:34] <helix84_> I'll do it
[20:34] <hpottinger> I think we need to be wary of taking decision-making from repository admins, making scripts "smart" takes control away, even if it's appealing, we can't assume we can program a perfect AI
[20:34] <helix84_> I'll send it to -commiters for comments
[20:34] <bollini> helix84_: you win a beer :-)
[20:35] <tdonohue> hpottinger: I agree. My opinion is it's ok to be "smart" by default. But we need to allow folks to specify exactly what they want to override those defaults
[20:35] <mhwood> We don't need an AI to work with existing knowledge.
[20:35] <mhwood> Where we get into trouble is in assuming more knowledge than we actually have.
[20:36] <hpottinger> smart defaults with the ability to override I'm OK with
[20:36] <helix84_> I think nobody disagrees with that
[20:36] <hpottinger> other way we get into trouble is if the environment in which the "smarts" exists changes
[20:36] <mhwood> Sure: if you tell it which one, it does that one or says "I can't". If you don't choose, it does all configured options.
[20:36] <bollini> mhwood: for example we are assuming that consumers are always used...but someone could decide to do index only in batch
[20:37] <tdonohue> So, this is what is kinda in my head: https://gist.github.com/tdonohue/7343600 But, as helix84_ says, we should figure out what all options are out there, to see what we need exactly
[20:37] <kompewter> [ New "index" commands? ] - https://gist.github.com/tdonohue/7343600
[20:38] <helix84_> let's move on and leave this for -commit or for next DevMtg
[20:38] <mhwood> Is there some way to talk to each indexing service, which never blows up, and which will tell us whether it is being used?
[20:38] <helix84_> mhwood: we could check whether the index exists and is non-empty
[20:38] <tdonohue> We probably should move along here...we've spent a lot of time on this one issue (though it is an important one)
[20:38] <helix84_> mhwood: but that still doesn't help with the option that both are being used
[20:38] <bollini> helix84_: the first time that you install dspace indexes are empty
[20:38] <mhwood> That's the sort of thing I was thinking. But you're right, we should move on and resume discussion on the ML.
[20:39] <mhwood> You ask each service. All that can be used, are used.
[20:40] <mhwood> Anyway, next issue?
[20:40] <bollini> https://jira.duraspace.org/browse/DS-1483
[20:40] <kompewter> [ [DS-1483] Store link to "primary bitstream" in citation_pdf_url for Google Scholar (request from Google) - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1483
[20:40] <kompewter> [ https://jira.duraspace.org/browse/DS-1483 ] - [DS-1483] Store link to "primary bitstream" in citation_pdf_url for Google Scholar (request from Google) - DuraSpace JIRA
[20:40] <tdonohue> re: 1483, aschweer created this PR: https://github.com/DSpace/DSpace/pull/379
[20:40] <kompewter> [ DS-1483 Generate citation_pdf_url in more cases by aschweer · Pull Request #379 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/379
[20:41] <tdonohue> The big question on 1483 is: Is this considered a "bug"? I tend to think it is...cause Google Scholar is telling us it's not as good as it could be. But, we need to decide whether to let this into 4.0
[20:41] <tdonohue> (and whether we agree with aschweer's approach)
[20:42] <mhwood> It's behavior specifically for Google Scholar, so changing the meaning shouldn't bother anyone else.
[20:42] <tdonohue> mhwood: correct
[20:43] <helix84_> I think it's a bug (because it causes issues for Scholar). I think Andrea's fix is reasonable.
[20:43] <PeterDietz> From Andrea's email, it sounds like Google has changed their definition of a PDF, and they are no longer limiting it to just application/pdf things
[20:43] <bollini> we have only a conceptual problem here.... primary bitstream was used to manage html content
[20:43] <tdonohue> Does anyone have time to try and run some tests against Andrea's code? I did a code review...but I haven't tested it.
[20:43] <PeterDietz> i.e. link us to your text, doc, jpg, etc...
[20:43] <mhwood> Yes, it sounds like it never did what they wanted, but they have now better understood what they wanted?
[20:44] <tdonohue> PeterDietz: Google Scholar told us their change in policy regarding "citation_pdf_url" . See the description in DS-1483 ticket
[20:44] <kompewter> [ https://jira.duraspace.org/browse/DS-1483 ] - [DS-1483] Store link to "primary bitstream" in citation_pdf_url for Google Scholar (request from Google) - DuraSpace JIRA
[20:45] <tdonohue> Anurag (The lead at Google Scholar) specifically told me that "citation_pdf_url" NEED NOT BE A PDF. It was initially assumed to be a PDF, but it's since changed to mean "the most important document to index"
[20:45] <bollini> we should clarify that primary bitstream is the "most important bitstream", what we link for google but we should also introduce a boolean flag that say show this bitstream in the bitstream list entry
[20:45] <mhwood> Where there *is* a "most important" document....
[20:46] <tdonohue> bollini: yes, we would need to clarify the meaning of "primary bitstream". Or, the other option is to instead use the bitstream ordering feature, and link the *1st* bitstream in "citation_pdf_url"
[20:48] <bollini> use the ordering is not a good idea in my opinion... the google need will impose you a specific "order presentation"
[20:48] <mhwood> bollini, I agree. That overloading is worrisome.
[20:48] <tdonohue> yea, just mentioned it as another option
[20:49] <tdonohue> so it sounds like using "primary bitstream" is OK with everyone, assuming we document that?
[20:49] <bollini> imho use the primary bitstream is the right way. Only want to note (also for dspace 5 not necessary for dspace 4) that a visibility flag on the bitstream could be a nice addition and will complete the requirements
[20:49] <helix84_> ok, a note here - we're trying to cram multiple meanings into a few knobs,
[20:49] <mhwood> Item 1234/5678: Journal of Chemical Solubilities vol III. Bitstreams: issue 1, issue 2.... Order sometimes doesn't tell you what GS wants to know.
[20:50] <helix84_> suppose we do metadata on all objects (incl. bitstreams) - we could have one property for each purpose
[20:50] <helix84_> there would be no need to mix the meaning of primary bitstream/bitstream order/bitstream for Scholar
[20:51] <mhwood> What does "primary" mean, in the absence of Google Scholar? Because what GS wants, means: "if a search engine would only find *one* of the bitstreams, which one do you want it to find?"
[20:51] <bollini> BTW this visibility flag on the bitstream looks like the discoverable flag on the item...
[20:51] <tdonohue> right, but since we don't have "metadata for all objects" (yet), I guess the question is...is aschweer's PR a "good enough" solution for now? Or would we rather keep the current (very limited) logic
[20:51] <mhwood> aschweer's code seems to be a step in the right direction.
[20:51] <helix84_> tdonohue: right, for now I agree that the patch improves the current situation
[20:52] <PeterDietz> There is a point that it is better the punt, and leave the dealing with minute details up to the end-repository.. This adds support for a wider net of content-type, and picking a "primary" out of a crowd of bitstreams. Two scenarios that were punted on previously
[20:52] <tdonohue> So, that being said, would someone like to help test aschweer's work? It seems like something we should work to merge soon
[20:53] <tdonohue> PeterDietz: We only had a narrow-net of content type before because Google Scholar initially said it was only for PDFs. Google Scholar has now changed their policies
[20:54] <mhwood> *mumble, we need a scripting language for expressing GS policies*
[20:54] <tdonohue> So, it would seem odd to continue to limit "citation_pdf_url" to PDFs only, when we created it for Google Scholar, and they are now telling us it should link to any content type
[20:55] <hpottinger> I'm already testing something else for Andrea (DS-951 DSPR#377) I'll add DS-1483 DSPR#379 to the list
[20:55] <kompewter> [ https://github.com/DSpace/DSpace/pull/377 ] - DS-951 Time calculations when parsing log files by aschweer
[20:55] <kompewter> [ https://github.com/DSpace/DSpace/pull/379 ] - DS-1483 Generate citation_pdf_url in more cases by aschweer
[20:55] <kompewter> [ https://jira.duraspace.org/browse/DS-951 ] - [DS-951] Monthly stats report ignores items archived on first and last day of the month - DuraSpace JIRA
[20:55] <kompewter> [ https://jira.duraspace.org/browse/DS-1483 ] - [DS-1483] Store link to "primary bitstream" in citation_pdf_url for Google Scholar (request from Google) - DuraSpace JIRA
[20:55] <tdonohue> Long story short, I'm +1 PR#379, assuming it gets some testing
[20:55] <tdonohue> thanks, hpottinger
[20:56] <mhwood> Yes, assuming it works as advertised, +1, and we should look at the issue again later.
[20:57] <tdonohue> I agree, this isn't the "end" of this idea/issue.... as it's part of SEO, it's essentially "neverending" as SEO policies always change and there's always improvements to make
[20:57] <bollini> +1 from me too... (are we sure that the pdf file need to be public?)
[20:57] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:57] <aschweer> hi folks -- sorry I'm late, I broke production yesterday so couldn't join this meeting from the beginning
[20:57] <mhwood> Were your ears burning? We're discussing PR 379
[20:58] <mhwood> Thanks for joining us. It's good timing.
[20:58] <tdonohue> hi aschweer: we're discussion your PR for DS-1483. It sounds like it has approval, but needs others to test
[20:58] <aschweer> I was catching up on the log and then hpottinger mentioned that you're still talking about this :)
[20:58] <kompewter> [ https://jira.duraspace.org/browse/DS-1483 ] - [DS-1483] Store link to "primary bitstream" in citation_pdf_url for Google Scholar (request from Google) - DuraSpace JIRA
[20:59] <aschweer> yes, testing would be great. abollini, the "bs must be public" one is a component of my logic I'm not sure about, it works for "my" repos but maybe not for others
[20:59] <mhwood> And I think hpottinger said he would do that testing.
[20:59] <tdonohue> So, it sounds like we have a +3 on PR#379, assuming it gets more testing (which hpottinger has volunteered for). Anyone else wanting to vote?
[21:00] <hpottinger> I'll vote after I test, but +3 sounds like "good to merge" unless there's a veto
[21:00] <hpottinger> and I do like that green button
[21:01] <mhwood> I tend to agree with the "public" requirement. Unless GS is logged on somehow, it is anonymous, and shouldn't see things that other anonymous users don't see, no?
[21:01] <tdonohue> yep, it sounds like it'd be "good to merge" unless there is a late veto
[21:01] <tdonohue> mhwood++ GS needs a public bitstream..it's an anonymous user
[21:01] <aschweer> cool, thanks folks. and sorry for leaving the PR so late, I was travelling last week
[21:02] <helix84_> +1 on Andrea's patch, too
[21:02] <helix84_> mhwood++
[21:02] <mhwood> Well, that is why we left time for things coming in late.
[21:03] <tdonohue> Since we are running out of time, I just wanted to quickly mention that I also would like to see aschweer's "Advanced Embargo" UI rework (DS-1709) ported to JSPUI (if anyone has time). The old UI is rather confusing and we just had anothing question on it on the list
[21:03] <kompewter> [ https://jira.duraspace.org/browse/DS-1709 ] - [DS-1709] Advanced Embargo form does not work with non-anonymous group. Embargoed items are immediately publicly available! - DuraSpace JIRA
[21:04] <aschweer> I / someone needs to look at my wording changes though -- right now it gets confusing when simple embargo is switched on. I'm hoping to get to that today but since I broke production, all bets are off
[21:04] <aschweer> also, should we switch to simple embargo forms by default?
[21:05] <lap1> i'm working on porting to jspui
[21:05] <bollini> we are interested in working on the JSPUI side... we are just much busy at least until the end of the next... maybe zuki can help too (I will try to reach him)
[21:05] <mhwood> Ah, thank you lap1.
[21:05] <tdonohue> thanks lap1!
[21:05] <bollini> s/the next/the next week/
[21:05] <kompewter> bollini meant to say: we are interested in working on the JSPUI side... we are just much busy at least until the end of the next week... maybe zuki can help too (I will try to reach him)
[21:05] <tdonohue> aschweer: I had reviewed the wording of the "Advanced Embargo" form (when I tested & merged it). It seemed OK. But, I hadn't looked as closely at the Simple Embargo form yet
[21:06] <aschweer> yeah the wording on the advanced form is fine, but the wording is being reused by the simple form in a way I didn't expect
[21:06] <tdonohue> oh, I see. I didn't realize that
[21:06] <aschweer> me neither...
[21:07] <tdonohue> I agree, it seems reasonable to have the "simple embargo" be default. But, we should fix it's wording obviously :) Perhaps that's another ticket to add?
[21:08] <tdonohue> Ok, I realize we are "over time" at this point. But, I did want to see if there's anything else pressing for 4.0? Anything else folks noticing in Testathon that needs immediate attention/eyes?
[21:09] <aschweer> has anyone had a look at the wording for the request item functionality? that one is likely to get lots of attention and a lot of the wording isn't suitable for production use right now
[21:09] <tdonohue> DS-1751 is the ticket around request item wording issues
[21:09] <kompewter> [ https://jira.duraspace.org/browse/DS-1751 ] - [DS-1751] Request a copy of the document page has 'Mensaje:' (should be message?) - DuraSpace JIRA
[21:10] <aschweer> thanks tdonohue, was just looking for it in jira
[21:10] <helix84_> I reviewed the Request Item functionality in both UIs but I didn't focus on wording :/
[21:10] <helix84_> I think it would benefit from DCAT feedback
[21:11] <aschweer> I can take a stab at rewording but I won't promise that it'll be proper English afterwards...
[21:11] <aschweer> yes DCAT feedback would be great
[21:11] <tdonohue> I'm glad to help review any new wording too... I'm sure others in DCAT would be willing to help with wording if needed.
[21:11] <helix84_> they're supposed to test during testathon anyway, right?! ;)
[21:11] <aschweer> and good point helix84_, I didn't check jspui wording
[21:11] * hpottinger volunteers for proofreading duty.
[21:12] * mhwood too.
[21:12] <helix84_> it would also be good if the wording was the same in both UIs as much as possible (didn't check that, either)
[21:12] <aschweer> helix84_++
[21:13] <aschweer> so this likely involves reviewing jspui wording, xmlui wording, e-mail templates
[21:13] * keithgilbertson (~keithgilb@2600:1003:b106:cbe0:346e:9768:4542:e301) has joined #duraspace
[21:13] <bollini> I have tranlated in English (hope) some terms that I was found when work to the jspui porting
[21:13] <bollini> I have not noted the terms in xmlui...sorry
[21:13] <helix84_> bollini: you mean from portugese?
[21:13] <bollini> yes
[21:14] <bollini> but not sure that the final language is really English :-)
[21:14] <aschweer> bollini: for what it's worth -- I have my doubts ;)
[21:14] <bollini> ok, we can create a new messages_andrea for that :-)
[21:15] <mhwood> Well, if I know what to look for, I can examine it.
[21:15] <aschweer> mhwood: have you had a look at the messages.xml lines and e-mail templates referenced from the jira issue?
[21:15] <mhwood> Which issue?
[21:16] <tdonohue> DS-1751
[21:16] <kompewter> [ https://jira.duraspace.org/browse/DS-1751 ] - [DS-1751] Request a copy of the document page has 'Mensaje:' (should be message?) - DuraSpace JIRA
[21:16] <bollini> all the jspui messages start from here: https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/resources/Messages.properties#L1772
[21:16] <kompewter> [ DSpace/dspace-api/src/main/resources/Messages.properties at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/resources/Messages.properties#L1772
[21:16] <mhwood> I wll look those over. Thank you.
[21:17] <aschweer> thanks mhwood
[21:17] <tdonohue> So, here's another Testathon ticket I was wondering the answer to: DS-1758 We may need some basic documentation on how to customize the new JSPUI?
[21:17] <kompewter> [ https://jira.duraspace.org/browse/DS-1758 ] - [DS-1758] Header/branding in bootstrap - DuraSpace JIRA
[21:17] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Read error: Connection reset by peer)
[21:17] <helix84_> mhwood: you would see all the newly added messages in the PR
[21:18] <mhwood> I will find them. Thanks!
[21:18] <bollini> I will add some documentation and will answer to this issue, just not sure when probably after the end of the testhaton
[21:18] <tdonohue> bollini: that's fine, just wanted to make you aware
[21:19] <bollini> I have just claimed the issue
[21:19] <bollini> another JSPUI thing: we haven't yet enabled the new startsubmissionlookup step but as there is a bug that is blocking we need to fix it before https://jira.duraspace.org/browse/DS-1755
[21:19] <kompewter> [ [DS-1755] Manual submission in "Bibliographic import and lookup in Submission" does not function - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1755
[21:19] <kompewter> [ https://jira.duraspace.org/browse/DS-1755 ] - [DS-1755] Manual submission in "Bibliographic import and lookup in Submission" does not function - DuraSpace JIRA
[21:19] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[21:20] <helix84_> oh, I tested the new BTE import UI in JSPUI - I have yet to file the bugs...
[21:21] <bollini> helix84_ are you talking about the administrative import UI or the new submission step?
[21:22] <helix84_> administrative UI, I'm not sure I knew about the submission step
[21:22] <kstamatis> helix84_ expecting your bugs :)
[21:22] <helix84_> in submission, I only tested RoMEO and it worked just fine
[21:22] <bollini> helix84_ yes, you know and love it :-) it is what I have presented at OR this year
[21:23] <tdonohue> Small sidenote: in general, it might be good to immediately mark any testathon tickets as "fix for 4.0" when they seem reasonable .. I've been trying to do some of that myself, just to ensure nothing gets overlooked
[21:24] <bollini> helix84_ as I have said before, it is not yet enabled in the demo dspace site as zuki has found a bug
[21:24] * cknowles (~cknowles@cpc19-sgyl35-2-0-cust180.18-2.cable.virginm.net) has joined #duraspace
[21:24] <helix84_> I'll try to order more spare time ;)
[21:24] <aschweer> ooh helix84_ can you send some my way too...?
[21:24] <helix84_> maybe we can get a batch discount
[21:24] <bollini> last thing from my side... someone is available for documentation cleanup? I have send an email to the release list some days ago
[21:25] <tdonohue> Speaking of stuff on the demo.dspace.org site. Is the new REST API now working there?
[21:25] <bollini> helix84_ : this is the documentation https://wiki.duraspace.org/display/DSDOC4x/Submission+User+Interface#SubmissionUserInterface-ConfiguringStartSubmissionLookupStep
[21:25] <kompewter> [ Submission User Interface - DSpace 4.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC4x/Submission+User+Interface#SubmissionUserInterface-ConfiguringStartSubmissionLookupStep
[21:26] <tdonohue> bollini: your suggested hanges to the Submission UI docs sounded reasonable to me. I just haven't had time myself to help.
[21:26] <mhwood> Oh. I did not set up a new Context for REST. Did anyone else notice my omission?
[21:26] <kstamatis> tdonohue just checked... REST seems to work
[21:26] <helix84_> bollini: thanks, I haven't tested that yet, but I will
[21:26] <kstamatis> http://demo.dspace.org/rest
[21:26] <kompewter> [ DSpace REST ] - http://demo.dspace.org/rest
[21:26] <tdonohue> kstamatis: thanks for verifying.
[21:27] <tdonohue> I think we still need to *link* to the new REST API. It's not showing up here: http://demo.dspace.org/
[21:27] <kompewter> [ DSpace 4.0 Demonstration Repository ] - http://demo.dspace.org/
[21:29] <kstamatis> tdonohue +1. But users need to make GET calls using the "Accept" header in order to get JSON or XML back
[21:29] <kstamatis> Not all REST endpoints support html...
[21:30] <tdonohue> right, I understand. Just want to make it findable. It's very similar to how we link to SWORD (v1 & v2) from http://demo.dspace.org/ but it just spits back XML (once you login)
[21:30] <kompewter> [ DSpace 4.0 Demonstration Repository ] - http://demo.dspace.org/
[21:30] <PeterDietz> I was going to make a change to the rest api to get rid of HTML serialization
[21:30] <PeterDietz> then it will default to xml in the browser
[21:31] <tdonohue> PeterDietz: that seems like a reasonable change
[21:31] <helix84_> PeterDietz: then we could have some nice client-side XSLT like in OAO
[21:31] <helix84_> OAI
[21:32] <tdonohue> So, does anyone want to link the REST API from 'http://demo.dspace.org', or should I?
[21:33] <bollini> I need to leave now. Thanks to all.
[21:33] * bollini (~bollini@host3-252-dynamic.7-87-r.retail.telecomitalia.it) has left #duraspace
[21:33] <tdonohue> OK, I'll link up the REST API in a bit then
[21:34] <tdonohue> I didn't have any other topics for today. So, the official meeting is ended. If anyone has anything else needing discussion, I'll still be hanging around here for a while
[21:35] * cknowles (~cknowles@cpc19-sgyl35-2-0-cust180.18-2.cable.virginm.net) has left #duraspace
[21:37] * kstamatis (b03a8b00@gateway/web/freenode/ip.176.58.139.0) Quit (Quit: Page closed)
[21:47] <tdonohue> Link to REST API has now been added to http://demo.dspace.org
[21:47] <kompewter> [ DSpace 4.0 Demonstration Repository ] - http://demo.dspace.org
[21:48] <mhwood> Looks good to me.
[21:59] * lap1 (~l.pascare@95.235.235.192) has left #duraspace
[22:01] * keithgilbertson (~keithgilb@2600:1003:b106:cbe0:346e:9768:4542:e301) has left #duraspace
[22:03] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:03] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has left #duraspace
[22:37] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) Quit (Quit: Later, taterz!)
[22:56] * aschweer (~schweer@schweer.its.waikato.ac.nz) has left #duraspace
[23:59] * misilot (~misilot@p-body.lib.fit.edu) Quit (Ping timeout: 240 seconds)
[23:59] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.