Timestamps are in GMT/BST.
[6:56] -rajaniemi.freenode.net- *** Looking up your hostname...
[6:56] -rajaniemi.freenode.net- *** Checking Ident
[6:56] -rajaniemi.freenode.net- *** Found your hostname
[6:56] -rajaniemi.freenode.net- *** No Ident response
[6:56] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:56] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:56] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[7:34] * DSpaceSlackBot (~DSpaceSla@ec2-50-17-201-82.compute-1.amazonaws.com) Quit (Remote host closed the connection)
[7:34] * DSpaceSlackBot (~DSpaceSla@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[12:17] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:58] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[14:32] <DSpaceSlackBot> <tdonohue> <here>: Reminder our weekly DSpace DevMtg is at the top of the hour (<30mins). Agenda is at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-10-18
[14:32] <kompewter> [ DevMtg 2017-10-18 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-10-18
[14:34] <DSpaceSlackBot> <mwood> I'll probably be late -- getting on a bus at 11:00, but it supposedly has WiFi.
[15:00] <DSpaceSlackBot> <tdonohue> <here>: It's DSpace DevMtg time. Agenda is linked above :point_up:
[15:01] <DSpaceSlackBot> <tdonohue> It looks like we may have a good number of folks here today, but it might be good to do a quick roll call to see who is actually paying attention ;)
[15:01] <DSpaceSlackBot> <terrywbrady> I have a staff meeting that will start in a min. I will join in later if it ends early.
[15:02] <DSpaceSlackBot> <tom_desair> I’m here but I can’t stay for the whole meeting
[15:02] <DSpaceSlackBot> <philip.muench> I'll be paying attention, but just to observe :slightly_smiling_face:
[15:02] <DSpaceSlackBot> <tdonohue> While folks are chiming in, I'll add in a few quick reminders... First up, the DSpace 7 team is meeting again tomorrow (at this same time, 15UTC) via Hangouts. More info at: https://wiki.duraspace.org/display/DSPACE/DSpace+7+Working+Group
[15:02] <kompewter> [ DSpace 7 Working Group - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+7+Working+Group
[15:03] <DSpaceSlackBot> <mwood> I'll catch up in a few minutes.
[15:03] <DSpaceSlackBot> <tdonohue> Next, the new DSpace Entities Working Group had their first meeting last week...the next one is Fri, Oct 27 (a week from this Fri). Notes and more info at: https://wiki.duraspace.org/display/DSPACE/DSpace+Entities+Working+Group
[15:03] <kompewter> [ DSpace Entities Working Group - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Entities+Working+Group
[15:04] * mhwood (~mhwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[15:04] <DSpaceSlackBot> <tdonohue> Sounds like a lot of folks are only here for a partial meeting...but, I'll go ahead and move along with the agenda (and we'll see what we can get done today)
[15:05] <DSpaceSlackBot> <tdonohue> I don't have a ton of updates this week from the DSpace 7 team. The team is still working on search & submission functionality. They are supportive of the discussions regarding code management of "master" (see #2 in Agenda)
[15:05] <DSpaceSlackBot> <tdonohue> I will mention though that we have a new REST API Test Framework in the works from @tom_desair at https://github.com/DSpace/DSpace/pull/1866 This could use more eyes & feedback
[15:05] <kompewter> [ DS-3484: REST API integration tests with Spring MVC test by tomdesair · Pull Request #1866 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1866
[15:06] <DSpaceSlackBot> <tdonohue> I know the DSpace 7 team has been watching this and is supportive. But, I'd encourage others to take a look, as we are striving for more test coverage in all the DSpace 7 work...and this means also on the `master` branch
[15:07] <DSpaceSlackBot> <tdonohue> @tom_desair is there anything else you wanted to specifically mention about this work?
[15:08] <DSpaceSlackBot> <tdonohue> (Also, I just noticed, it looks like Travis is "stalled" on building/approving the latest PR code, just an FYI)
[15:08] <DSpaceSlackBot> <tom_desair> I was having many problems with Travis :travis:
[15:08] <DSpaceSlackBot> <tom_desair> There was a bug in my code that I could not reproduce locally on any of our machines. But we finally managed to identify it.
[15:09] <DSpaceSlackBot> <tom_desair> However, it indeed seems that I need to trigger travis again
[15:09] <DSpaceSlackBot> <tom_desair> Yesterday Travis and Github were having some issues, some maybe there are still some after problems.
[15:10] <DSpaceSlackBot> <tdonohue> Yes, it could be an artifact of that. Likely either a minor rebase or a new commit should trigger Travis to rebuild.
[15:10] <DSpaceSlackBot> <tom_desair> https://www.traviscistatus.com/incidents/26f004880gqk
[15:10] <kompewter> [ Travis CI Status - GitHub commit delays ] - https://www.traviscistatus.com/incidents/26f004880gqk
[15:10] <DSpaceSlackBot> <tom_desair> Yes I really need to rebase with all those “Try to fix Travis” commits :)
[15:11] <DSpaceSlackBot> <tom_desair> But the good news is that we can now even use SOLR in our IT tests
[15:11] <DSpaceSlackBot> <tom_desair> (for the new REST API)
[15:11] <DSpaceSlackBot> <tom_desair> So that allows us to write tests for Browse indexes and Discovery search
[15:11] <DSpaceSlackBot> <tom_desair> And normally also stats related things, but I didn’t try that yet (as we don’t do stats yet in DSpace 7)
[15:12] <DSpaceSlackBot> <tdonohue> Yes, that's great news!
[15:12] <DSpaceSlackBot> <tdonohue> Ok, gonna move along now with our agenda. I know the DSpace 7 team will be watching this PR and discussing more in tomorrow's meeting. But, other eyes/opinions/thoughts are welcome!
[15:13] <DSpaceSlackBot> <tdonohue> The next topic on the agenda is a carry-over from last week (as we were a very small group of 3 last week). Enabling code management/checks on `master`
[15:14] <DSpaceSlackBot> <tdonohue> First off, we now have Google's ErrorProne enabled on `master`. See https://github.com/DSpace/DSpace/pull/1861 This is just a tool to check Java code for common coding mistakes (and suggest corrections)
[15:14] <kompewter> [ DS-3712: Add Error Prone checks to catch common Java code mistakes by tdonohue · Pull Request #1861 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1861
[15:15] <DSpaceSlackBot> <tdonohue> Last week we also discussed enabling test/code coverage supports (and all were supportive), specifically this PR also from @tom_desair: https://github.com/DSpace/DSpace/pull/1865
[15:15] <kompewter> [ DS-3711: JaCoCo maven plugin by tomdesair · Pull Request #1865 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1865
[15:16] <DSpaceSlackBot> <tdonohue> So, if others have not yet seen that work, or have comments on whether to enable code coverage reports on `master`, I'd encourage you to take a look & comment on this
[15:16] <DSpaceSlackBot> <tdonohue> The idea here would be to enable Coveralls reports on the `master` branch. They look like this: https://coveralls.io/builds/13658718
[15:16] <kompewter> [ DSpace/DSpace | Build #4808 | Coveralls - Test Coverage History & Statistics ] - https://coveralls.io/builds/13658718
[15:17] <DSpaceSlackBot> <tdonohue> We have similar Coveralls reports for the DSpace 7 Angular UI already...for example: https://coveralls.io/builds/13752350
[15:17] <kompewter> [ DSpace/dspace-angular | Build #220 | Coveralls - Test Coverage History & Statistics ] - https://coveralls.io/builds/13752350
[15:18] <DSpaceSlackBot> <tom_desair> I still need to test if there is no impact on a “released” version.
[15:18] <DSpaceSlackBot> <tdonohue> So, this helps us track the code coverage both on `master` and `dspace-angular` similarly. Currently our percentages are quite low, but we can work to improve that ;)
[15:19] <DSpaceSlackBot> <tdonohue> @tom_desair: if we wanted, we could even do a very early "7.0-snapshot" release to see what happens. But, we'd have to merge the PR first.
[15:19] <DSpaceSlackBot> <tom_desair> I’ll first try to mimic a release locally
[15:20] <DSpaceSlackBot> <tdonohue> I suspect releases won't be affected by this... but it is worth a test to be sure we didn't break anything in our POMs
[15:20] <DSpaceSlackBot> <tdonohue> Moving along.... last on the list of code mgmt tools / checks on `master`...
[15:21] <DSpaceSlackBot> <tdonohue> We also had support last week for looking at more strictly enforcing our Java code style (again on `master`) using CheckStyle.
[15:22] <DSpaceSlackBot> <tdonohue> This would just allow us all to create code that is more readable, and more consistent...and avoid all those automatic alignment/spaces changes that various IDEs keep doing to our PRs
[15:22] <DSpaceSlackBot> <tdonohue> I've started analyzing this a bit...and realized our documented Java code style itself could use some updates (it's based on Sun code standards from 1999, and those are no longer maintained)
[15:23] <DSpaceSlackBot> <tdonohue> My notes are all on this Wiki page: https://wiki.duraspace.org/pages/viewpage.action?pageId=90967266
[15:23] <kompewter> [ Code Style Guide (WIP) - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/pages/viewpage.action?pageId=90967266
[15:24] <DSpaceSlackBot> <tdonohue> This is really the start of a discussion... I noted on that page that we might want to look at more modern Java code styles (namely Google's documented style, and even Fedora Commons documented style, since it's another DuraSpace project)
[15:24] <DSpaceSlackBot> <tdonohue> But, at this point, it's really open to discussion, comments. So, I'd like to hear from others on this. Feel free to add comments to that wiki page
[15:24] <DSpaceSlackBot> <tdonohue> Or we have some time today we could spend on this as well...if you already have initial thoughts
[15:25] <DSpaceSlackBot> <tdonohue> The end goal here would be to (1) Update our code styles (if needed), (2) Configure Checkstyle on `master` to use/validate our code style, (3) Determine a time to merge this into `master` (based on discussion with DSpace 7 team)
[15:27] <DSpaceSlackBot> <tdonohue> I think the one thing we do want to avoid here is having *too many rules*....I don't want to make it a pain to develop PRs against DSpace. But, I *do* want to ensure we are using common styles (that can be imported into our IDEs), so that we can avoid PRs that do a ton of strange reformatting, etc
[15:28] <DSpaceSlackBot> <tdonohue> I also think our documented styles could use a refresh here...and would like to potentially borrow some best practices from Fedora (and/or Google). But, that's where I could use more input going forward.
[15:29] <DSpaceSlackBot> <tdonohue> In any case, sounds like others may need time to digest this (or have been pulled away from this discussion). So, I'll leave it at that
[15:30] <DSpaceSlackBot> <tdonohue> All the other topics on our agenda are usual "carry over" topics. We have lists of tickets we could dig into further, or a small number of tickets in the "received" backlog.
[15:31] <DSpaceSlackBot> <tdonohue> But, before we do either...are there any other topics / tickets that folks here would like to discuss in more detail? Anything you could use feedback or more eyes on?
[15:32] <DSpaceSlackBot> <philip.muench> Well, if nobody else is here, I actually have some questions :slightly_smiling_face:
[15:33] <DSpaceSlackBot> <tdonohue> Go for it @philip.muench
[15:33] <DSpaceSlackBot> <philip.muench> It conderns DS-3715 and 3132.
[15:33] <kompewter> [ https://jira.duraspace.org/browse/DS-3715 ] - [DS-3715] 2 item level embargo bugs in OAI-PMH - DuraSpace JIRA
[15:34] <DSpaceSlackBot> <philip.muench> Both of these are about how to deal with item/bitstream level embargoes in OAI-PMH
[15:36] <DSpaceSlackBot> <philip.muench> For DS-3715, I created a PR that fixes incremental updates to the OAI index for items with item level embargoes. I would like to do the same for items with bitstream level embargoes.
[15:36] <kompewter> [ https://jira.duraspace.org/browse/DS-3715 ] - [DS-3715] 2 item level embargo bugs in OAI-PMH - DuraSpace JIRA
[15:36] <DSpaceSlackBot> <tdonohue> This looks to be the PR: https://github.com/DSpace/DSpace/pull/1867
[15:36] <kompewter> [ DS-3707, DS-3715: Fixes to item level embargo/privacy in OAI-PMH by philip-muench · Pull Request #1867 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1867
[15:37] <DSpaceSlackBot> <philip.muench> Exactly. The PR mentioned in DS-3132 creates the needed nodes in the xml structure, but updates to embargo data also will only get triggered if the item itself gets updated or if a full import to the OAI index is done.
[15:37] <kompewter> [ https://jira.duraspace.org/browse/DS-3132 ] - [DS-3132] Expose embargo end date in OAI2 - DuraSpace JIRA
[15:38] <DSpaceSlackBot> <philip.muench> This is because of the fact that updates to bitstream or bundle resource policies do not trigger an update to the items lastmodified date.
[15:40] <DSpaceSlackBot> <philip.muench> Can anyone think of a solution to that problem?
[15:40] <DSpaceSlackBot> <tdonohue> Arguably, modifying a bitstream or bundle of an item *should* update the item's last modified date....as that updates the item.
[15:41] <DSpaceSlackBot> <tdonohue> But, I'm not sure if doing that would cause other issues (hopefully not)...it seems like something we could prove out via Unit Tests though
[15:42] <DSpaceSlackBot> <terrywbrady> Just joining in here. I also ran into a situation where I noticed that the item modification date does not update when a bitstream is updated. I do not think that there is a bitstream modification date in the system.
[15:43] <DSpaceSlackBot> <tdonohue> No, there isn't a bitstream modification date. That's why I'm wondering myself why we don't update the *item* modification date, when one of its bitstreams or bundles changes. A bitstream/bundle belongs to an Item, and updating one therefore probably should update the Item's modified date
[15:45] <DSpaceSlackBot> <terrywbrady> I suspect that if you are building derivative resources with filter media (re-indexing text), perhaps you would not want to modify an item update date.
[15:45] <DSpaceSlackBot> <philip.muench> That is a good point.
[15:45] <DSpaceSlackBot> <tdonohue> Good point, @terrywbrady. Maybe it's just the ORIGINAL bundle then?
[15:46] <DSpaceSlackBot> <terrywbrady> Perhaps the rule needs to be bundle specific
[15:46] <DSpaceSlackBot> <terrywbrady> Or configurable by bundle
[15:48] <DSpaceSlackBot> <philip.muench> A second set of methods, so that filter-media can create bundles/bitstreams without updating the date?
[15:49] <DSpaceSlackBot> <terrywbrady> I have not looked at the early part of this discussion. Let me scroll up and see if there is some code to consider
[15:51] <DSpaceSlackBot> <tdonohue> I wonder if this is related specifically to the ORIGINAL bundle (which are the original uploaded files). If bitstreams in that bundle are updated, then the Item should be considered... but other bundles are more "transient", and are created based on those ORIGINAL bitstreams
[15:51] <DSpaceSlackBot> <terrywbrady> I presumed that there would be some code in org.dspace.content that would trigger an update to item modification date based on specific bitstream changes
[15:52] <DSpaceSlackBot> <philip.muench> I tried it just about an hour ago, at least a bitstream resource policy update does not trigger an item update. I do not know about bundle resource policies.
[15:53] <DSpaceSlackBot> <sulfrian> Maybe we need a `OAIConsumer` to trigger the reindex of an item on certain events?
[15:54] <DSpaceSlackBot> <philip.muench> There was an implementation of that I saw a while back. Let me search quickly.
[15:55] <DSpaceSlackBot> <philip.muench> DS-2644
[15:55] <kompewter> [ https://jira.duraspace.org/browse/DS-2644 ] - [DS-2644] Consuming events that need an alteration of the OAI Index - DuraSpace JIRA
[15:56] <DSpaceSlackBot> <tdonohue> The idea of an `OAIConsumer` has come up before...it'd allow us to auto-update the OAI index without requiring a cron job be run.
[15:56] <DSpaceSlackBot> <philip.muench> https://github.com/ufal/clarin-dspace/blob/lindat/dspace-oai/src/main/java/cz/cuni/mff/ufal/event/OAIIndexEventConsumer.java
[15:56] <kompewter> [ clarin-dspace/OAIIndexEventConsumer.java at lindat · ufal/clarin-dspace · GitHub ] - https://github.com/ufal/clarin-dspace/blob/lindat/dspace-oai/src/main/java/cz/cuni/mff/ufal/event/OAIIndexEventConsumer.java
[15:56] <DSpaceSlackBot> <tdonohue> But, if I recall correctly, the `OAIConsumer` idea was hard to implement properly as required? merging OAI code into the `dspace-api`.
[15:57] <DSpaceSlackBot> <sulfrian> Ah I see. The problem is that the `dspace-oai` webapp is separated from the `dspace-api`.
[15:57] <DSpaceSlackBot> <tdonohue> Personally, I'd *like* to see an `OAIConsumer` happen. I haven't had time myself to dig into how to do so though (thoughts/ideas are welcome)
[15:58] <DSpaceSlackBot> <philip.muench> I will look into it. It would be a much cleaner solution than what I implemented for DS-3715
[15:58] <kompewter> [ https://jira.duraspace.org/browse/DS-3715 ] - [DS-3715] 2 item level embargo bugs in OAI-PMH - DuraSpace JIRA
[15:59] <DSpaceSlackBot> <sulfrian> Maybe the an `OAIConsumer` can at least gather the items to index, so that the indexer do not need to rely on the last modification time?
[15:59] <DSpaceSlackBot> <tdonohue> There *is* an RDFConsumer... and `dspace-rdf` is separate from the `dspace-api`. So, that might be a place to look...how was RDFConsumer implemented, and can we do something similar for OAI
[15:59] <DSpaceSlackBot> <tdonohue> The RDFConsumer though is shipped in the `dspace-api`. That might be why it works ok: https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/rdf/RDFConsumer.java
[15:59] <kompewter> [ DSpace/RDFConsumer.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/rdf/RDFConsumer.java
[16:01] <DSpaceSlackBot> <tdonohue> I'm noticing here we have already used up our full hour (time flies!). Thanks for the questions @philip.muench... this has been a good discussion
[16:01] <DSpaceSlackBot> <philip.muench> Nice to be welcomed so warmly, so thx right back!
[16:01] <DSpaceSlackBot> <sulfrian> There is at lease some rdf stuff in `dspace-api`, too. I see a `RDFUtil` and some other classes. So we might need to integrate some bits of the OAI stuff into `dspace-api`.
[16:02] <DSpaceSlackBot> <tdonohue> Since our hour is up, I'm going to consider the official meeting "closed" (i.e. no new topics will be raised). But, I'd encourage discussions/brainstorms to continue (as long as folks are interested/available)
[16:03] <DSpaceSlackBot> <philip.muench> Well, since it's already 18 pm in germany, I will say goodbye for now :9
[16:04] <DSpaceSlackBot> <tdonohue> @sulfrian: yes, that's prompting my memory a bit. I think that might have been the core issue here... some/much the OAI code would need to be moved to dspace-api to support an `OAIConsumer`. That said, I don't know offhand how much of the code would need moving (and it might still be worth looking into, as it sounds like a better long-term solution perhaps)
[16:05] <DSpaceSlackBot> <tdonohue> So, I'd still say this is worth looking at more closely. We really should have an `OAIConsumer` (if not in 6.x, then maybe in 7.0). We should understand what would be required to make that happen
[16:10] <DSpaceSlackBot> <sulfrian> The problem, that items with the embargo needs to be indexed after the expiration of the embargo would not change with an `OAIConsumer`. We do not have events for an expiration of the embargo (at least with the current embargo system, the pre-3.x embargo stuff could implement that easily with a custom lifter).
[16:12] <DSpaceSlackBot> <sulfrian> We could index the items during archiving, but hide it until the embargo is expired.
[16:16] <DSpaceSlackBot> <tdonohue> @sulfrian: Yes, that's actually how Discovery (search/browse index) works, IIRC. All items are indexed during archiving...but embargoed ones are hidden, until embargo expires.
[16:16] <DSpaceSlackBot> <tdonohue> So, OAI should/could act similarly
[16:21] <DSpaceSlackBot> <tdonohue> Honestly (and this might be a crazy idea), a part of me wonders if OAI should/could leverage the Discovery index in some way. Not sure if that works well in practice though...but it seems like there is some code here that should be "shared" between the Discovery index and OAI index
[16:41] <DSpaceSlackBot> <philip.muench> On my way home, I thought about how this could work. Actually, the OAI index works the way @sulfrian described it, and the item.public flag is the responsible flag for an item being displayed or not. It might be feasible to instead use a date, and compare that to the current one while OAI querying.
[16:41] <DSpaceSlackBot> <philip.muench> Or, to make it robust, use a list of dates, since theoretically, you could install multiple resource policies per item/bundle/bitstream.
[21:39] * tdonohue (~tdonohue@dspace/tdonohue) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.