#duraspace IRC Log

Index

IRC Log for 2015-04-08

Timestamps are in GMT/BST.

[6:28] -wilhelm.freenode.net- *** Looking up your hostname...
[6:28] -wilhelm.freenode.net- *** Checking Ident
[6:28] -wilhelm.freenode.net- *** Found your hostname
[6:28] -wilhelm.freenode.net- *** No Ident response
[6:28] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:28] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:28] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:11] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[12:15] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:20] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has joined #duraspace
[13:58] * hpottinger (~hpottinge@173-20-173-237.client.mchsi.com) has joined #duraspace
[14:06] * hpottinger_ (~hpottinge@174.154.134.110) has joined #duraspace
[14:08] * robint (81d7fa56@gateway/web/freenode/ip.129.215.250.86) has joined #duraspace
[14:08] * hpottinger_ (~hpottinge@174.154.134.110) Quit (Read error: Connection reset by peer)
[14:08] * hpottinger (~hpottinge@173-20-173-237.client.mchsi.com) Quit (Ping timeout: 250 seconds)
[14:32] * hpottinger (~hpottinge@mu-162188.dhcp.missouri.edu) has joined #duraspace
[15:00] <peterdietz> hi all
[15:00] <robint> Hello!
[15:01] <tdonohue> Hi all, it's obviously that time again. Here's the agenda for today's DSpace Developers Meeting: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-04-08
[15:01] <kompewter> [ DevMtg 2015-04-08 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-04-08
[15:02] <tdonohue> The primary topic today is trying to find a way to move along the DSpace 5.2 release (which we've been talking about for several weeks running). Just wondering where we stand, and how we can move along some of these "stalled" PRs or tickets
[15:02] <tdonohue> Oh, and we do have a 5.2 page now, thanks to hpottinger: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.2+Status
[15:02] <kompewter> [ DSpace Release 5.2 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.2+Status
[15:03] <tdonohue> We also have a fair number of PRs which are under consideration for 5.2...but, most seem to be waiting on help: https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A5.2
[15:03] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A5.2
[15:03] * arnobc (Brett@arnobc.alfred.edu) has joined #duraspace
[15:04] <tdonohue> Plus, the ever present DS-2486 still needs some more eyes & testers
[15:04] <kompewter> [ https://jira.duraspace.org/browse/DS-2486 ] - [DS-2486] Missing fields in solr statistics data from previous DSpace versions - DuraSpace JIRA
[15:04] <tdonohue> (Though, I'll admit, it looks at a glance like aschweer has done some excellent work here...but it could use more testers / verifiers)
[15:05] <mhwood> I looked it over and I agree, it looks like very nice work. I haven't gotten 'round to actually testing yet, alas.
[15:06] <hpottinger> yes, please, I'm getting ready to test it now, in a situation where people might hit the site while the stats reindex is in process
[15:06] <tdonohue> So, after that dump of info... perhaps we start with 2486, which is definitely the most pressing ticket to get into 5.2. Is there anyone who will be able to help chip in on testing 2486 in the next week?
[15:06] <hpottinger> I will, I've given the previous PR a +1, this new PR I haven't yet tested, but the work looks solid
[15:07] <mhwood> I just need to convince myself that I know how to test it....
[15:07] <tdonohue> thanks hpottinger. Anyone else willing to also chip in on testing this?
[15:07] <hpottinger> I *think* some other people (like, anyone who thinks they might be upgrading to 5.x any time soon) might be able to find some time to test?
[15:08] <hpottinger> I think, especially, any hosting providers will be *keenly* interested in ensuring we get stats right
[15:08] <tdonohue> Yes, if you are upgrading to DSpace 5.x and using Solr Stats, then 2486 would likely be of high interest to you
[15:09] <hpottinger> hosting providers, or, anyone who might have multiple DSpace instances...
[15:10] * hpottinger looks pointedly around the room, without pointing
[15:10] <mhwood> He means me.
[15:11] <hpottinger> ha, I wasn't singling anyone out, mhwood, I think we *all* support more than one
[15:11] <mhwood> :-)
[15:11] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[15:12] <tdonohue> I'm going to admit, it's doubtful I'll have much dev time to help in coming week or two (As mentioned last week, we are behind on the Strategic Planning / RoadMap work, and much of my time is going towards that in the coming weeks)
[15:13] <tdonohue> So, while I want to try and help us all drive along 5.2 (and 2486) to a resolution, I'm probably not going to be able to be "actively" doing so myself
[15:13] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[15:13] <hpottinger> If you're prepping for an upgrade and have a staging server for people to review, testing DSPR#905 fits right in with that, you can run a stats upgrade while people are reviewing other work
[15:13] <kompewter> [ https://github.com/DSpace/DSpace/pull/905 ] - Ds 2486 reindex solr by aschweer
[15:14] <peterdietz> We host a lot, but we've shifted gears to ES. It would still be worth taking a look to ensure solr is working well
[15:14] <hpottinger> s/stats upgrade/stats reindex/
[15:14] <kompewter> hpottinger meant to say: If you're prepping for an upgrade and have a staging server for people to review, testing DSPR#905 fits right in with that, you can run a stats reindex while people are reviewing other work
[15:14] <tdonohue> So, I'd really ask others to see if you can find a few hours to spare to help chip in (on 2486 or any other ticket for that matter), so we can get 5.2 out the door in the next few weeks or month
[15:15] <tdonohue> peterdietz: you may need to be on the lookout for similar issues with ES. Plus, you may want to review 2486 anyhow, as it is likely going to eventually replace your old "stats-util -e" export code (maybe not in 5.2, but eventually)
[15:18] <pbecker> hi.
[15:18] <pbecker> Is there more to discuss about 5.2 or may I chip in with another (new) topic?
[15:18] <tdonohue> So, 2486 needs testers, we've established that. We have at least one (hpottinger). Are there other tickets/PRs that folks would like to see get into 5.2? We have a list of PRs, but little activity on most of them as of yet: https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A5.2
[15:18] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A5.2
[15:19] <pbecker> I think DSPR#876 is an important one as well. I reviewed it and would be glad, if we could merge it asap.
[15:19] <kompewter> [ https://github.com/DSpace/DSpace/pull/876 ] - Fix for DS-2482 by cjuergen
[15:20] <tdonohue> pbecker: as I noted on that PR, as long as it's verified by a JSPUI user to work (and you are one!), I'd say merge it. It's a tiny code change, and it looks reasonable
[15:21] <pbecker> all right.
[15:22] <tdonohue> Anyone else have tickets/PRs to bring up to discuss for 5.2?
[15:23] <mhwood> DS-2518. I guess I'm the only EZID user.
[15:23] <kompewter> [ https://jira.duraspace.org/browse/DS-2518 ] - [DS-2518] EZID DOI IdentifierProvider doesn&#39;t set the location in metadata - DuraSpace JIRA
[15:23] <hpottinger> DSPR#893 would be worth testing while messing with stats
[15:23] <kompewter> [ https://github.com/DSpace/DSpace/pull/893 ] - [DS-2212] Ignore _version_ field when sharding solr statistics by aschweer
[15:24] <pbecker> merged and cherry picked for dspace-5_x
[15:27] <hpottinger> I pointed this out last week, but DSPR#850 needs testing by someone who knows something about SWORD
[15:27] <kompewter> [ https://github.com/DSpace/DSpace/pull/850 ] - [DS-2131] SWORDv2 ingestion fails with NullPointerException when replacing a non archived item by KevinVdV
[15:28] <hpottinger> this might come in handy: https://github.com/CottageLabs/dip
[15:28] <tdonohue> I agree that both of those would be nice... PR 893 would be good to test alongside other Solr fixes. I admit, I'm not using EZID, mhwood, but your PR seems a bit small...so if it's an "obvious fix", perhaps it's just one to merge immediately
[15:28] <kompewter> [ CottageLabs/dip · GitHub ] - https://github.com/CottageLabs/dip
[15:29] <tdonohue> huh, I hadn't seen that tool, hpottinger. Why don't you add a link to it into the 850 PR or it's associated ticket?
[15:31] * tdonohue notes I just emailed -commit to ask for more help on 5.2 as well.
[15:31] <hpottinger> tdonohue: I added a comment to DSPR#850, as per your suggestion
[15:31] <kompewter> [ https://github.com/DSpace/DSpace/pull/850 ] - [DS-2131] SWORDv2 ingestion fails with NullPointerException when replacing a non archived item by KevinVdV
[15:31] <tdonohue> thanks
[15:32] <tdonohue> Ok, any other tickets we want to touch on with 5.2? I'll admit, I don't want to belabor the point that we need help with 5.2 -- I do realize that the committers at these meetings are the "usual suspects" and we may need others to chip in as well.
[15:33] * robint (81d7fa56@gateway/web/freenode/ip.129.215.250.86) Quit (Ping timeout: 246 seconds)
[15:34] <hpottinger> AND non-committers are welcome to help test PRs, too, and we notice that kind of thing
[15:34] <tdonohue> +1 - yes, any non-committers who are listening in (or reading this later), we do appreciate your feedback as well. So your testing and +1s help, and we do notice & recognize your efforts
[15:35] <mhwood> 2518 is merged, closed.
[15:35] <tdonohue> Ok, not hearing anything more on 5.2. Seems like we still are in a state of "needing more help / testing" on the major tickets. As mentioned, I just emailed Committers as well for support
[15:35] <tdonohue> thanks mhwood
[15:36] <tdonohue> Any other topics folks would like to discuss today? pbecker, it sounded like you may have had something to discuss (at least you mentioned a "new topic" earlier)?
[15:36] <pbecker> I have to leave in ten minutes, but that may be sufficient.
[15:36] <pbecker> I worked on the Item level versioning in the last weeks.
[15:37] <pbecker> I created/worked on several tickets which resulted in several PRs.
[15:37] <pbecker> I think those PRs must be tested together as they depend on each other.
[15:38] <pbecker> Perhaps it is to early, but I would be glad if we could talk about how these can get into master (for the 6.0 release).
[15:38] <pbecker> To name some of the tickets: DS-1348, DS-1349, DS-1814
[15:38] <kompewter> [ https://jira.duraspace.org/browse/DS-1348 ] - [DS-1348] Item level versioning breaks persistence and lacks meta information - DuraSpace JIRA
[15:38] <kompewter> [ https://jira.duraspace.org/browse/DS-1349 ] - [DS-1349] Item level versioning exposes personal data (name and email of submitter, versioning creator) - DuraSpace JIRA
[15:38] <kompewter> [ https://jira.duraspace.org/browse/DS-1814 ] - [DS-1814] Allow submitter to create a new version of an item - DuraSpace JIRA
[15:39] <pbecker> and DS-2497
[15:39] <kompewter> [ https://jira.duraspace.org/browse/DS-2497 ] - [DS-2497] DSpace should keep the version number persistent - DuraSpace JIRA
[15:40] <pbecker> I just want to avoid a situation where I have to rebase all these PRs. So I would be glad to get the in before a lot of work for 6.0 is done else where.
[15:40] <pbecker> s/get the in/get them in
[15:40] <kompewter> pbecker meant to say: I just want to avoid a situation where I have to rebase all these PRs. So I would be glad to get them in before a lot of work for 6.0 is done else where.
[15:40] <tdonohue> right. makes sense. I'm scanning the tickets here to remind myself
[15:42] <tdonohue> One question, what happens with people who are already using Item Level versioning? Any way to "clean up" or "correct" old, un-persistent versions? Guess I'm wondering if we need a migration path here
[15:43] <pbecker> The only problem might be the handles. I think it should be compatible with all possible states that may exist out there. But yes, it is one point we might to have to test again.
[15:45] <tdonohue> So, either way, it sounds like to me, we really need a discussion & decision around the change in *behavior*. We need to verify that the new behavior is acceptable (it seems reasonable to me), and that there's no use cases we are accidentally abandoning with changing this behavior
[15:46] <tdonohue> I notice also that @mire staff were initially responsive on this, but they don't seem to have responded on the proposed change of behavior in the PR? As they helped build the Item Versioning, I wonder if we need to get them back into the discussion here?
[15:47] <pbecker> I tried to make discuss this in jira (DS-1348) and #dspace (regarding DS-2497) already. But if necessary we should talk about it again.
[15:47] <kompewter> [ https://jira.duraspace.org/browse/DS-1348 ] - [DS-1348] Item level versioning breaks persistence and lacks meta information - DuraSpace JIRA
[15:47] <kompewter> [ https://jira.duraspace.org/browse/DS-2497 ] - [DS-2497] DSpace should keep the version number persistent - DuraSpace JIRA
[15:47] <hpottinger> @-name some names in the ticket
[15:47] <pbecker> s/make/
[15:47] <kompewter> pbecker meant to say: I tried to discuss this in jira (DS-1348) and #dspace (regarding DS-2497) already. But if necessary we should talk about it again.
[15:48] <tdonohue> yep, I'm looking at 1348...there's good discussion there, but then it stops after you created the PR. Just wondering, pbecker, if your proposed behavior in the PR is actually "accepted", or if people haven't reviewed that?
[15:48] <pbecker> so what is the best way to get the discussion started now and not one or two weeks before pr freeze?
[15:49] <hpottinger> I'd tag mdiggory to see if he has any comments on the design
[15:49] <tdonohue> pbecker: as hpottinger mentions, you could mention names in the ticket (1348) to see if there are any last comments/suggestions on the change in behavior. mentioning users by name now sends them an email "ping" on that ticket.
[15:49] <pbecker> tdonohue: mhwood and hpottinger "accepted" the idea, and mdiggory did not respond anymore. one reason I brought it up today.
[15:49] <tdonohue> So, you could "@mdiggory" and ask him directly whether he approves of the behavior change in the PR, or has any concerns/comments.
[15:49] <pbecker> all right.
[15:49] <pbecker> hpottinger, thanks.
[15:50] <peterdietz> I think part of the issue is that during the release / development cycle, developers will live on master, but the rest of the year / off-cycle, developers will live on whatever version their site is using. So, if my site is still 4.x, it will be hard to work on 6.x, until I dedicate time to focus on 6.x
[15:50] <tdonohue> We could also schedule time in a future meeting and try and get one or more @mire staff in this discussion. I agree though, I'd rather move this forward sooner than later
[15:50] <hpottinger> to be clear, I haven't tagged anyone, I was just saying mdigorry would be the person at @mire I'd tag
[15:51] <peterdietz> Soon my sites will be on 5.x, which shrinks the gap. Also, if you stood up a specific feature / demo site, that demonstrates here is my UI problem, and here is another instance that has this PR in it. Test this fixed behavior..
[15:51] <pbecker> So I'll tag mdigorry and abollini (as he reported DS-1814) and would be glad, if this topic could be discussed in two weeks again.
[15:51] <kompewter> [ https://jira.duraspace.org/browse/DS-1814 ] - [DS-1814] Allow submitter to create a new version of an item - DuraSpace JIRA
[15:52] <tdonohue> pbecker: if you don't get responses to the ticket...the next step would be to either describe the behavior change in an email (to -devel or -commit) asking for "final feedback" and/or schedule a future meeting to discuss this. My opinion is that we need this behavior change to have more eyes...once it's fully 'vetted', then the PR itself seems very reasonable
[15:53] <pbecker> tdonohue: thanks, that is a roadmap.
[15:53] <tdonohue> thanks for bringing it up again, pbecker. And thanks for your hard work on this
[15:54] <tdonohue> Any other topics that folks would like to discuss today? We're nearing the end of the meeting, but we have a few more minutes here
[15:55] <mhwood> peterdietz brought up the Java roadmap the other day. I've just updated my dev. environment to Java 8.
[15:55] <tdonohue> aha, yes, Java 8. I forgot about that.
[15:55] <mhwood> IIRC Java 7 is EOL at the end of *this month*.
[15:55] <tdonohue> Is anyone running DSpace on Java 8 yet? I admit, I'm still on Java 7, even though, yes it is EOL this month
[15:56] <mhwood> I'm thinking that we ought to develop and test on 8, and leave the compiler input/output versions at 7 for now.
[15:56] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Ping timeout: 265 seconds)
[15:56] <tdonohue> We likely should have a ticket to update our dependencies to Java 8 (and track any issues we may find). DSpace 6 should obviously now require Java 8
[15:56] <tdonohue> +1 to developing and testing on Java 8 now for "master"
[15:57] <hpottinger> sounds like a job for Vagrant-DSpace
[15:57] <peterdietz> Yeah, Oracle is ending jdk7 support. Its an open thing, so maybe someone else will continue support for openjdk7... ??? But, to be safe, jdk8 is where the language has moved. So, we need to ensure we're compatible / working good
[15:57] <pbecker> sorry, have to go.
[15:57] <tdonohue> +1 vagrant-dspace also being updated to Java 8, hpottinger
[15:57] <pbecker> good bye everyone!
[15:57] <tdonohue> bye pbecker
[15:57] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[15:58] <peterdietz> Not just build errors, but, if we had an automated user / acceptance testing thing (umm... selenium, cucumber), then hopefully that could catch explosions caused by changing jdk
[15:58] <tdonohue> my opinion is that DSpace 6 should require Java 8 or above (as we shouldn't be encouraging usage of any EOL versions of any prerequisites). So, that means we need to obviously develop "master" with Java 8 from here on out
[15:59] <tdonohue> peterdietz: I'd welcome some automated user/acceptance testing..just needs someone(s) to help make that happen (i.e. get it started, and let us know how to chip in)
[16:00] <mhwood> Do we want to update the compiler plugin's version config right away? That would ensure awareness, but also throw a brief stumbling block in front of everyone developing on master.
[16:00] <tdonohue> mhwood: yes, as long as doing so doesn't completely "break" the compilation of "master"
[16:01] <tdonohue> i.e. we shouldn't break master....but we should move it quickly to using Java 8
[16:01] <mhwood> So that needs testing and maybe fixing. Who wants to write the Jira?
[16:01] <tdonohue> I'd welcome whoever wants to start this process to write the JIRA ticket ;)
[16:01] <hpottinger> I look away from IRC for a minute, and peterdietz agrees to write acceptance tests
[16:02] <mhwood> Do they make a Cucumber for Java?
[16:02] <hpottinger> yuck
[16:03] <hpottinger> https://github.com/cucumber/cucumber-jvm
[16:03] <kompewter> [ cucumber/cucumber-jvm · GitHub ] - https://github.com/cucumber/cucumber-jvm
[16:03] <tdonohue> yep: https://cukes.info/
[16:03] <kompewter> [ Cucumber ] - https://cukes.info/
[16:03] <tdonohue> https://pragprog.com/book/srjcuc/the-cucumber-for-java-book
[16:03] <kompewter> [ The Pragmatic Bookshelf | The Cucumber for Java Book ] - https://pragprog.com/book/srjcuc/the-cucumber-for-java-book
[16:03] <tdonohue> From "cukes.info" site: "Cucumber works with Ruby, Java, .NET, Flex or web applications written in any language. "
[16:05] <tdonohue> So, yea, if anyone wants to start playing with Cucumber + DSpace, I'd welcome it
[16:06] <tdonohue> Ok, so we are now "over time" here. Any final thoughts before we close out the meeting?
[16:06] <mhwood> Or even e.g. Selenium without Cucumber (for those of us who are less enthusiastic about Cucumber.)
[16:06] <tdonohue> sure thing
[16:07] <mhwood> I just found http://www.uispec4j.org/
[16:07] <kompewter> [ UISpec4J | Java/Swing GUI Testing Made Simple! ] - http://www.uispec4j.org/
[16:07] <mhwood> No opinion yet.
[16:07] <mhwood> Hm, may not fit. More reading....
[16:08] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[16:08] <hpottinger> DS-2288
[16:08] <kompewter> [ https://jira.duraspace.org/browse/DS-2288 ] - [DS-2288] Acceptance test suite - DuraSpace JIRA
[16:08] <mhwood> Ds-2518 went to master but not to 5_x yet. I'm working on that now.
[16:10] <tdonohue> Ok, not hearing any further discussion topics. So, we'll close out today's meeting. It sounds like we have a few activities here (please feel free to claim one of interest to you): (1) continue pushing forward on 5.2 & Solr issues, (2) Update "master" to use Java 8, (3) Consider acceptance testing frameworks for DSpace (cucumber, selenium, etc)
[16:11] <hpottinger> there's a comment on DS-2288 that points to Dryad's tests: http://wiki.datadryad.org/Testing
[16:11] <kompewter> [ Testing - The Dryad data repository wiki ] - http://wiki.datadryad.org/Testing
[16:11] <kompewter> [ https://jira.duraspace.org/browse/DS-2288 ] - [DS-2288] Acceptance test suite - DuraSpace JIRA
[16:13] <mhwood> So are we on Jira backlog, then?
[16:13] <tdonohue> oh, yep. we are...move on over to #dspace for that
[16:15] <mhwood> http://java-source.net/open-source/web-testing-tools
[16:15] <kompewter> [ Open Source Web Testing Tools in Java ] - http://java-source.net/open-source/web-testing-tools
[16:47] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Ping timeout: 246 seconds)
[17:05] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[21:00] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:35] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has left #duraspace
[22:28] * hpottinger (~hpottinge@mu-162188.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)

These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.