Log of the #fcrepo channel on chat.freenode.net

Using timezone: Eastern Standard Time
* thomz joins02:59
* youn joins07:56
* dwilcox joins07:57
* youn leaves08:43
* dwilcox leaves08:44
* dwilcox joins08:47
* youn joins09:11
* acoburn joins09:12
* mohamedar joins09:24
* youn leaves09:31
* dwilcox leaves09:35
* dwilcox joins09:41
* bseeger joins09:45
* peichman joins09:50
* osmandin joins09:52
* github-ff joins10:00
[fcrepo4] acoburn opened pull request #1117: Set the tombstone response type as text/plain (master...fcrepo-2123) https://git.io/vP2ft
* github-ff leaves
* github-ff joins10:04
[ontology] acoburn created fcrepo-2123 from master (+0 new commits): https://git.io/vP2fa
* github-ff leaves
* github-ff joins
[ontology] acoburn pushed 1 new commit to fcrepo-2123: https://git.io/vP2fo
ontology/fcrepo-2123 71e97e2 Aaron Coburn: Add hasTombstone property...
* github-ff leaves
* github-ff joins10:05
[ontology] acoburn opened pull request #40: Add hasTombstone property (master...fcrepo-2123) https://git.io/vP2f1
* github-ff leaves
* github-ff joins10:17
[fcrepo-camel] acoburn opened pull request #127: Use an in-memory broker configuration for test suite (master...fcrepo-2264) https://git.io/vP2Ug
* github-ff leaves
* awoods joins10:28
<acoburn>awoods: what's the status of the jcr.Session PR?11:02
<awoods>acoburn: on a call11:04
* thomz leaves11:17
* youn joins11:32
* jjtuttle leaves11:34
* osmandin leaves11:39
* github-ff joins11:42
[fcrepo4] acoburn opened pull request #1118: Remove sonatype's oss-parent pom (master...fcrepo-1964) https://git.io/vP2nw
* github-ff leaves
<awoods>acoburn: I am now reviewing PR-110711:45
* github-ff joins11:49
[fcrepo4] acoburn opened pull request #1119: Upgrade to guava 19.0 (master...fcrepo-1959) https://git.io/vP2cF
* github-ff leaves
* bseeger leaves11:53
* dwilcox leaves12:26
* dwilcox joins12:27
* youn leaves12:28
<awoods>acoburn: PR-1107 is pending response.12:41
* peichman1 joins12:59
* peichman leaves13:00
<awoods>acoburn: You have created a flurry of PRs. Do you want to hold off on merging them into master to avoid other rebasing conflicts?13:01
<acoburn>awoods: https://jira.duraspace.org/browse/FCREPO-226813:02
awoods: those shouldn't conflict
awoods: plus, I've already got merge conflicts to deal with, so if there are more, I might as well do them all at once13:03
awoods: your responses have been responded to13:04
* bseeger joins13:10
* peichman1 leaves13:12
* peichman joins13:15
<awoods>acoburn: One minor response to "private" or open to testing.
<acoburn>awoods: "this is not used in any testing code" — ahhh, but it is, you just haven't seen it yet13:16
<awoods>acoburn: that would explain it
<acoburn>awoods: it was my attempt to keep the PR < 4,000 changed lines13:17
<awoods>acoburn: much appreciated
acoburn: It looks like ajs6f has some comments that have not been addressed on PR-110713:22
<acoburn>awoods: can you point those out?13:23
<awoods>acoburn: https://github.com/fcrepo4/fcrepo4/pull/1107#discussion_r8197616913:24
acoburn: https://github.com/fcrepo4/fcrepo4/pull/1107#discussion_r81976299
acoburn: https://github.com/fcrepo4/fcrepo4/pull/1107#discussion_r81976919
acoburn: https://github.com/fcrepo4/fcrepo4/pull/1107#discussion_r8197862113:25
acoburn: https://github.com/fcrepo4/fcrepo4/pull/1107#discussion_r8197874413:26
<acoburn>awoods: 2, 3, 4 have been dealt with in code review commits
awoods: 5 has already been dealt with13:27
awoods: I'll handle #1 in a new commit
<awoods>acoburn: I am just noting the "ajs6f requested changes" at the bottom of: https://github.com/fcrepo4/fcrepo4/pull/1107
acoburn: maybe it is an artifact of GitHubs new review process.13:28
<acoburn>awoods: yes
<awoods>acoburn: it would be nice if ajs6f were able to remove his red 'x' and red 'O'. Otherwise, committing the PR seems premature.13:29
<acoburn>awoods: are you thinking this would be committed separately from the implementation?13:30
acoburn: I am saying that in GitHub, it looks like ajs6f still has concerns.13:31
<acoburn>awoods: this PR has three parts: 1. add new interfaces in fcrepo-kernel-api; 2. add implementations for those interfaces in fcrepo-kernel-modeshape 3. remove the current use of jcr.Session in the http layers
awoods: so far, you only see 1 and 2
awoods: I have 3 complete on a local branch
<awoods>acoburn: sure13:32
<acoburn>awoods: I assumed they'd all be part of one big commit
* cmmills joins
<awoods>acoburn: however, is it correct to assume that PR-1107 is ready to commit?
acoburn: you are saying it should wait?
<acoburn>awoods: it is ready to commit
awoods: personally, it would be nice if it were committed sooner
<awoods>acoburn: I agree. I am saying that it appears in GitHub that ajs6f still has reservations.13:33
<acoburn>awoods: I have to do all sorts of gymnastics locally to keep various branches in sync
awoods: yes, that is just a matter of getting ajs6f to sign off on it
<awoods>acoburn: exactly13:34
* mikeAtUVa joins13:38
<acoburn>awoods: actually, I'm not going to add another commit for a while — I'm in the middle of rebasing13:40
awoods: and this will probably take a few days
awoods: if you'd like to send a PR against my work with this change, I'd merge it: https://gist.github.com/acoburn/256cad10de01ccca2fc8acd3af3ebb42
awoods: nm, I'll take care of this13:45
* bseeger leaves13:46
* bseeger joins13:52
* dhlamb leaves14:12
* dhlamb joins14:13
* youn joins14:28
* whikloj joins14:29
* whikloj leaves14:30
* whikloj joins14:31
* bseeger leaves14:35
* whikloj leaves
* youn leaves14:38
<acoburn>awoods: the rebasing wasn't as bad as I thought14:47
<awoods>acoburn: good14:48
<acoburn>awoods: so shall I wait until PR 1107 is merged?
awoods: i.e. before making the rest of the impl public?
<awoods>acoburn: yes, please... just waiting on ajs6f
<acoburn>awoods: sounds good14:49
* youn joins
* youn leaves14:56
* youn joins15:14
* youn leaves15:21
* mohamedar1 joins15:27
* mohamedar leaves15:30
* whikloj joins15:31
* whikloj leaves15:37
* coblej joins15:38
* dhlamb leaves15:40
<coblej>awoods: FWIW, I am unable to reproduce the problem reported in https://jira.duraspace.org/projects/FCREPO/issues/FCREPO-2076 using fcrepo-webapp-plus-4.7.0-RC-1.war on our development server using the test script with up to 100,000 objects15:41
I added a comment to the ticket to that effect
<awoods>coblej: that sounds like good news15:42
<coblej>awoods: yes, I think so15:43
<awoods>coblej: shall we close that ticket as "Fixed with 4.7.0"?15:44
<coblej>awoods: I think that would be reasonable, especially given that, as far as I know, no one else was ever able to reproduce the problem
<awoods>coblej: thank you for closing the loop on that one.15:45
* github-ff joins15:46
[fcrepo4] acoburn opened pull request #1120: Deprecate the backup and restore endpoints (master...fcrepo-2044) https://git.io/vP2xs
* github-ff leaves
<coblej>awoods: you're welcome ... some interaction of infinipan with our local environment maybe(?)
<awoods>coblej: ISPN seems to be problematic on a couple of fronts.15:47
<coblej>awoods: yep
* cmmills leaves15:57
* cmmills joins
* bseeger joins16:00
* whikloj joins16:06
awoods/acoburn: does Fedora work with isMemberOfRelations?16:14
<acoburn>whikloj: not the I know of
<whikloj>I saw ITs for hasMemberRelation, but not for isMemberOfRelation16:15
<awoods>whikloj: yes, I believe Fedora supports both.16:17
<whikloj>awoods: Ok thanks, I'll have to test. Also, do we need an 4.7.0-RC-2?
<acoburn>whikloj: was there an issue with the first RC?16:19
<awoods>whikloj: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/rdf/impl/LdpIsMemberOfRdfContext.java
<whikloj>acoburn: I saw that there was a blocker bug added to the Release testing page, which I think was the issue kford was having that mikeAtUVa had fixed16:20
<acoburn>whikloj: the path locking?16:21
<whikloj>acoburn: yes, I believe so
acoburn: https://jira.duraspace.org/browse/FCREPO-2086
<acoburn>whikloj: but is it a blocker?
<whikloj>acoburn: I assumed as it was listed under "Testing Blocker Tickets"16:22
<awoods>whikloj/acoburn: that is a patch that we will back-ported to 4.6... so including it in 4.7.0 only makes sense.
<acoburn>whikloj: I mean, it's an existing bug that goes back to much older versions
whikloj: I don't see why that would be a blocker
whikloj: that said, I'd expect a 4.7.1 version to be released pretty soon16:23
<awoods>acoburn: Do you see having that patch in 4.7.0 being problematic?
<acoburn>awoods: I'd like people to start using 4.7.x as soon as possible16:24
awoods: including Amherst
awoods: in that sense, yes
<awoods>acoburn: sure, but we know of a critical patch... and 4.7.0 is in release testing...
<mikeAtUVa>We intentionally decided to put it off because it's a significant change with potentially severe impact. The 50% performance decrease is a key example of that. That said... the repository's clearly broken for concurrency without it.
<acoburn>awoods: what mikeAtUVa said16:25
<awoods>acoburn: unfortunately, there are also a lot of updates in master...16:26
<acoburn>awoods: why is that a negative thing?
awoods: we discussed the path locking issue a few months ago and decided to put it off
<mikeAtUVa>awoods, acoburn: cherry-picking merges are a pain...
<awoods>acoburn: We could potentially release 4.7.0, followed by a 4.7.1 that includes the critical patch, without the other updates.
<acoburn>awoods: really? you want to do the cherry picking?16:27
awoods: that will be a complete pain
<awoods>acoburn: not really, hence the 4.7.0 including the patch
<mikeAtUVa>awoods, acoburn: but I have to cherry-pick for the back-porting, right?16:28
<acoburn>awoods: fine, what I'm arguing about is not putting off the release any longer than we have to
awoods: it is _absolutely imperative_ to get people off of ISPN
awoods: there are plenty of other issues, too, but that is the biggest one16:29
<awoods>acoburn/whikloj/mikeAtUVa: I am happy to go with committer consensus... with the recognition that we are knowingly putting out a 4.7.0 that contains a critical bug... a bug that is known to corrupt repositories.
barmintor/cbeer: thoughts ^^16:30
<acoburn>awoods: if you see it as a critical bug, then fine, put it into the release
<whikloj>I'm not sure, I've have also heard concerns about the performance implications of the path locking
<acoburn>whikloj makes a very important point16:31
<awoods>mikeAtUVa: It may be worth making the injected bean optional.
<mikeAtUVa>whickloj: unless I'm wrong (and it's possible) the performance implications hit for exactly the cases that are most likely to result in corruption without the fix, so the choice is between slowness or corruption.
<awoods>mikeAtUVa: I know you have designed for that.
<acoburn>awoods: one of the big reasons _not_ to make this part of the release is that it is a significant change — are _you_ confident that the implementation is solid?16:32
<whikloj>mikeAtUVa: So it doesn't impact regular use?
<awoods>acoburn: we would probably want to test it :)
<whikloj>mikeAtUVa: I mean regular as in not causing concurrency issues
<mikeAtUVa>whikloj: it shouldn't... though I think if Keven Ford does the test I recommended in the last e-mail and confirms it, I'll be more comfortable.
<acoburn>awoods: for example, I get periodic (20%) unit test failure with the path locking commit in place16:33
awoods: that's not a good thing to put into a release at the last minute
<awoods>acoburn: That is news to me
<mikeAtUVa>acoburn: that's troubling... were you going to mention it?
<acoburn>awoods: I am using mvn install -rf :fcrepo-http-api a lot
mikeAtUVa: eventually, I was busy with other things
mikeAtUVa: I thought I had plenty of time to look into it16:34
<mikeAtUVa>acoburn: I completely understand... it wasn't relevant if we had a whole release cycle to work it out.
<acoburn>mikeAtUVa: but now it seems like I don't
<whikloj>If this doesn't affect normal uses, and if we can diagnose the errors acoburn is seeing then I am less concerned about performance. But I haven't tested the patch yet either
<awoods>I will add it to tomorrow's agenda for discussion.16:35
<barmintor>I don't lke periodic unit test failure, and I'm more concerned with fencing off corruption first, then identifying how to minimize the locking16:36
<mikeAtUVa>acoburn: unit tests or integration tests?16:38
<acoburn>mikeAtUVa: unit tests
<mikeAtUVa>acoburn: if they're really unit test failures and they're that frequent, I wonder why I haven't seen them or they haven't ever happened in travis.16:39
<acoburn>mikeAtUVa: I'll try running a few builds and giving more details...
<mikeAtUVa>acoburn: thanks... sorry this has become a pressing concern.16:40
<acoburn>mikeAtUVa: https://gist.github.com/acoburn/e29e2477f8105308de435e80aa1c6d01
mikeAtUVa: (first try)16:41
mikeAtUVa: I added the failure status in the gist (you may want to reload)16:42
mikeAtUVa: second try failed at a different location
<mikeAtUVa>acoburn: thanks... I'll see what I can make of it... it occurs to me that I haven't actually run all the tests a lot since the final changes were made to that PR.16:43
<acoburn>mikeAtUVa: third try failed in three places16:44
awoods: see what I mean?
awoods: I'm not sure that I'd veto putting this into the RC, but I'm very uneasy about it — we need more time to work with the new impl16:46
<awoods>acoburn: Agreed, this should not be taken lightly.
<acoburn>awoods: and doing this at the 11th hour seems especially bad16:47
<awoods>acoburn: We should probably add more time to the clock.
<mikeAtUVa>It just means we're still an unspecified number of releases away from having a product that isn't known to be critically defective.
Though not supporting concurrency is easier to workaround than whatever's wrong with infinispan.16:48
<acoburn>awoods: my main concern is in getting off of ISPN
<awoods>acoburn: whereas I have a range of concerns.16:49
<acoburn>awoods: that's fair16:50
<barmintor>awoods: is there a respec version of the CRUD spec or is that still just a working doc?16:52
I can't find my links
<awoods>barmintor: no... still in the google-doc.16:53
<barmintor>awoods++ // thanks
<awoods>barmintor: I would like to put some focus on that in the next few days. Are you looking to do the same?
<barmintor>awoods: yes, but next week
awoods: I'm booked the next 2 days16:54
awoods: except for the cal tomorrow
<awoods>barmintor: let's stay in touch.
* acoburn leaves16:55
* bseeger leaves16:59
* mikeAtUVa leaves17:22
* coblej leaves17:29
* whikloj leaves17:40
* whikloj joins17:41
* dwilcox leaves17:42
* dwilcox joins17:43
* whikloj_ joins17:44
* whikloj_ leaves
* whikloj leaves17:45
* peichman leaves18:07
* mohamedar1 leaves18:12
* youn joins18:58
* youn leaves18:59
* dwilcox leaves20:23
* dwilcox joins21:13
* dhlamb joins21:17
* dwilcox leaves21:18
* mikeAtUVa joins22:09
* mikeAtUVa can't reproduce acoburn's errors building from master with at least 10 tries.... he's too careful and skilled to be making some user error, so I guess there may be either a timing issue or a relevant difference in build environment (maybe java in OSX interrupts threads sometimes). Do you ever have failed tests after the FCREPO-2086 commits, awoods?22:25
* mikeAtUVa leaves22:42
* dhlamb leaves23:11
* github-ff joins23:15
[fcrepo4] acoburn opened pull request #1121: Clean up RdfLexicon (master...fcrepo-2009) https://git.io/vPaXw
* github-ff leaves

Generated by Sualtam