Log of the #duraspace-ff channel on chat.freenode.net

Using timezone: Eastern Standard Time
* dwilcox joins07:11
* jgpawletko joins07:40
* awead joins08:06
* jcoyne joins08:24
* dhlamb joins08:38
* acoburn joins08:49
* Yinlin leaves08:58
* mikeAtUVa joins09:01
* osmandin joins09:11
* ksclarke joins09:15
* whikloj joins09:17
* github-ff joins09:30
[fcrepo-camel] acoburn opened pull request #49: https://jira.duraspace.org/browse/FCREPO-1311 (master...remove-secure-option) http://git.io/FwiT
* github-ff leaves
* github-ff joins09:44
[fcrepo-camel] awoods pushed 2 new commits to master: http://git.io/Fwy6
fcrepo-camel/master cbcf633 Aaron Coburn: removed 'secure' endpoint option...
fcrepo-camel/master 10214db Andrew Woods: Merge pull request #49 from acoburn/remove-secure-option...
* github-ff leaves
* travis-ci joins09:52
fcrepo4/fcrepo-camel#117 (master - 10214db : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-camel/compare/7e8d2a81d158...10214db04c10
Build details : http://travis-ci.org/fcrepo4/fcrepo-camel/builds/48766792
* travis-ci leaves
* awoods leaves10:12
* ajs6f joins10:13
* awoods joins10:23
<ajs6f>acoburn: Non-Fedora question: are you continuing to experiment with Apache Stanbol?10:24
* yinlin joins10:25
<awoods>[Standup]
- Yesterday:
** Finalized OR2015 TWG proposal
** Submitted OR2015 Fedora committers workshop proposal
** Announced Java 8 requirement starting in April
** Reviewed and merged: https://jira.duraspace.org/browse/FCREPO-1311
- Today:
** Review and merge: https://jira.duraspace.org/browse/FCREPO-1309
** Review and merge: https://jira.duraspace.org/browse/FCREPO-1310
** Review and merge: https://jira.duraspace.org/browse/FCREPO-1258
<acoburn>ajs6f: not actively
<yinlin>awoods: - Yesterday: Fixed a FCREPO-1307 critical issue including a unit test, sent PR. https://github.com/fcrepo4/fcrepo4/pull/699 - Today: Will submit new PR for FCREPO-1290 with unit test. - No blockers
<awoods>** Work: https://jira.duraspace.org/browse/FCREPO-1308, wiki docs
- No blockers
<yinlin>awoods: do we have a Google hangout meeting at 3pm today?
<acoburn>ajs6f: at least not recently — I'd like to, but I haven't had time
<ajs6f>acoburn: Cool. I haven't done anything interesting with it lately, but I was think about the possibility of a MARC-specific enhancement engine for Linked Data reconciliation.10:26
<awoods>yinlin: yes, to wrap-up this sprint.
<ajs6f>acoburn: One could take advantage of the semantics of MARC to select vocabularies against which to reconcile.
acoburn: E.g. for a 650$z, look in LCSH geographical terms, or GeoNames, or the like.10:27
awoods: When we go to Java 8 for the build machinery, I assume we simultaneously open the door for the use of Java 8 language features? The "pseudo-functional" Collections API would clean out a lot of boilerplate from the RDF generation machinery.
<acoburn>ajs6f: I've been playing with an LDPath-based expression engine for camel that uses a backend that comes from the stanbol codebase
<awoods>ajs6f: absolutely. Please add tickets now.
<ajs6f>acoburn: That would be very handy for Fedora 4 sites using Camel.10:28
<acoburn>ajs6f: I also have some code that does geonames reconciliation with stanbol that I plan return to in the somewhat near term
ajs6f: exactly. it's much nicer than using XPath all the time
<ajs6f>acoburn: It's the MARC/RDA/AACR2 nexus that interests me near Stanbol, because I want to get the hell away from it. But using the (poorly-defined and confusing) formal semantics for that stuff might let one apply automated methods such as Stanbol's enhancement regimes with much greater accuracy.10:29
acoburn: I've thought about cutting a set of LDPath Hamcrest matchers for use in Fedora's test framework.10:30
acoburn: For pretty much the same reasons as you're using it in Camel: clarity and concision.
* aawoods_ joins
* awoods leaves10:31
* ajs6f1 joins10:36
* ajs6f leaves
<ajs6f1>awoods: https://jira.duraspace.org/browse/FCREPO-131210:39
<awoods>ajs6f1: ?
<ajs6f1>awoods: The ticket for which you asked.10:40
<awoods>ajs6f1: thanks10:41
<ajs6f1>awoods: No, thank _you_. You're a wonderful tech lead and it's a pleasure to work with you.
<awoods>ajs6f1: are you feeling ok?10:42
<ajs6f1>awoods: I'm just basking in your reflected light.
* whikloj leaves10:43
<osmandin>[Standup] Yesterday: re-did PR 1258 / Today: doing FCREPO-1283 / Blockers: None.10:46
* ajs6f1 leaves10:48
* acoburn leaves10:52
* scossu joins
* acoburn joins
* ajs6f joins10:53
<awoods>scossu: I have been thinking about your fcr:transform comment: https://wiki.duraspace.org/display/FEDORA40/RESTful+HTTP+API+-+Transform?focusedCommentId=67242312#comment-6724231210:54
scossu: There may be a way to use the "reverse property selector", maybe...
scossu: by using the Prefer header of: http://fedora.info/definitions/v4/repository#InboundReferences on the fcr:transform request.10:55
scossu: https://wiki.duraspace.org/display/FEDORA40/RESTful+HTTP+API+-+Containers#RESTfulHTTPAPI-Containers-GETRetrievethecontentoftheresource
<ajs6f>awoods: Using the reverse property selector like this indicates a CWA in play. That's not inherently wrong, but it bears mentioning.10:56
* dwilcox_ joins10:57
* dwilcox leaves11:00
* escowles joins
<scossu>awoods: I will check that out after the call. Thanks.
* dshalvi joins11:01
<awoods>https://wiki.duraspace.org/display/FF/2015-01-29+-+Fedora+Tech+Meeting
* dwilcox leaves11:22
* dwilcox joins
<ajs6f>mikeAtUVa: Are you thinking of some particular set of resources or collections or the like that would benefit from this?11:34
<mikeAtUVa>ajs6f: all of our master files, and anything in a system that isn't fedora 4 (ie, a federation over archivesspace)
<ajs6f>mikeAtUVa: Right, right. That might be a much simpler road to integration with AS than some kind of API-to-API welding.11:35
Cool.
mikeAtUVa: I wrote a FOXML sequencer early in the F4 project. It wasn't hard, just a few paragraphs of Scala.11:39
<ruebot>mikeAtUVa++11:40
<ajs6f>We've had discussion before about using PREMIS as support for audit info inside the repo.11:43
<ruebot>ajs6f: yeah. that's exactly what i'm getting at with the audit info.
<dhlamb>islandora has a terrifying layer of xslts that work with foxml to produce solr docs. it's a flat format and could be adapted to work with RDF if you wanna go that route
personally i'd rather slit my wrists with a dull butter knife, but xslts are an option
<ajs6f>ruebot: Yeah. We should probably understand what we mean by audit before mikeAtUVa finds himself having to deal with it.11:44
<dhlamb>but it does touch pretty much all the datastrems
<ruebot>ajs6f: https://github.com/Islandora/Islandora-Fedora4-Interest-Group/issues/7
<ajs6f>ruebot: Cool. That should inform the needs nicely.11:45
<ruebot>excellent!11:48
here is the call info: https://github.com/Islandora/Islandora-Fedora4-Interest-Group/blob/master/meetings/03.md11:54
<mikeAtUVa>Maybe call it 4.2 so as not to confuse anyone.11:59
<scossu>Tech meeting minutes are online: https://wiki.duraspace.org/display/FF/2015-01-29+-+Fedora+Tech+Meeting12:23
<osmandin>afk12:43
* jgpawletko_mtg leaves13:17
<yinlin>awoods: can you tell why a Untracked file show in the PR?13:25
<awoods>yinlin: on a call13:26
<yinlin>awoods: ok. later
<ajs6f>awoods: Do you want to start a Java 8 "feature master" branch? I.e. a feature branch to which the only direct commit would be the change to pom.xml for Java 8, then off of which we'd take Java 8 language-feature-using branches? Or do you just want to start multiple feature branches and assume merging the pom.xml stuff later won't be too bad?13:39
<awoods>ajs6f: on a call
<ajs6f>NW!!!!
afk bbs13:49
* acoburn leaves13:50
* acoburn1 joins
* acoburn1 leaves13:51
* acoburn joins
<awoods>ajs6f: If you want to get started on Java8 work, a Java8 branch makes sense.13:55
<jcoyne>ajs6f: lambdas everwhere!13:56
<awoods>yinlin: did you need some feedback?13:57
<yinlin>awoods: yes. please check the email.13:59
<awoods>yinlin: see response14:00
* dwilcox leaves
<awoods>yinlin: The issue is that your master branch has local updates.
<yinlin>awoods: no it is not, https://github.com/yinlinchen/fcrepo4/blob/master/fcrepo-kernel-impl/src/main/java/org/fcrepo/kernel/impl/rdf/impl/PropertiesRdfContext.java https://github.com/yinlinchen/fcrepo4/blob/master/fcrepo-http-commons/src/main/java/org/fcrepo/http/commons/domain/PreferTag.java14:03
awoods: I work on the branch.... https://github.com/yinlinchen/fcrepo4/blob/fcrepo-1307/fcrepo-http-commons/src/main/java/org/fcrepo/http/commons/domain/PreferTag.java14:04
* dwilcox joins14:06
<awoods>yinlin: ok, good14:10
yinlin: but clearly PropertiesRdfContext was added to this commit: https://github.com/yinlinchen/fcrepo4/commit/e3f5b43350a607ff1b6c619b4cb9bdfc9ba70d92
yinlin: I need to step away for lunch14:11
<yinlin>awoods: ok talk to you later
* github-ff joins14:14
[fcrepo4] yinlinchen closed pull request #699: Address the 1 critical issue from Sonar report. (master...fcrepo-1307) http://git.io/FuhI
* github-ff leaves
* github-ff joins14:29
[fcrepo4] yinlinchen opened pull request #700: Override "equals(Object obj)" to comply with the contract of the "compar... (master...fcrepo-1307) http://git.io/FKl1
* github-ff leaves
<yinlin>awoods: new PR, fixed the previous problem. https://github.com/fcrepo4/fcrepo4/pull/700
* dwilcox leaves14:37
* dwilcox_ joins
* github-ff joins14:41
[fcrepo4] ajs6f created Java8 (+1 new commit): http://git.io/FKur
fcrepo4/Java8 4c528f1 ajs6f: Step to Java 8
* github-ff leaves
* travis-ci joins14:47
fcrepo4/fcrepo4#3321 (Java8 - 4c528f1 : ajs6f): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo4/commit/4c528f1bebe5
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/48804976
* travis-ci leaves
* ajs6f1 joins
* ajs6f leaves14:48
<awoods>osmandin/yinlin: here is the page for 3pm: https://wiki.duraspace.org/display/FF/2015-01-29+Sprint2015-1+Wrap-up+Meeting14:49
* ajwagner joins14:52
* rarian leaves14:56
* github-ff joins14:59
[fcrepo4] acoburn opened pull request #701: Travis ci support (master...travis-ci-support) http://git.io/FK6L
* github-ff leaves
* github-ff joins15:00
[fcrepo4] acoburn closed pull request #701: Travis ci support (master...travis-ci-support) http://git.io/FK6L
* github-ff leaves
<ajs6f1>acoburn: Did you see that I started a "submaster" for Java 8 stuff?
<acoburn>yes — I did the PR incorrectly15:01
<ajs6f1>As long as you know where it's at.
* dshalvi leaves15:03
* github-ff joins
[fcrepo4] acoburn opened pull request #702: updated travis-ci configuration (Java8...travis-ci-support) http://git.io/FKPm
* github-ff leaves
* osmandin leaves15:14
* github-ff joins15:34
[fcrepo4] ajs6f pushed 2 new commits to Java8: http://git.io/FKNg
fcrepo4/Java8 9213ff0 Aaron Coburn: updated travis-ci configuration
fcrepo4/Java8 8f4e276 ajs6f: Merge pull request #702 from acoburn/travis-ci-support...
* github-ff leaves
* travis-ci joins15:51
fcrepo4/fcrepo4#3324 (Java8 - 8f4e276 : ajs6f): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/4c528f1bebe5...8f4e276bc684
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/48810900
* travis-ci leaves
* dhlamb leaves16:00
* dwilcox_ leaves16:06
* osmandin joins16:19
* ajs6f joins16:35
* ajs6f1 leaves
<ajs6f>awoods: There's a good amount of Guava (so to speak) built-in to Java 8. I'm inclined to replace what we can from Guava with Java 8 equivalents. Is that worth an epic? Mostly it feels like one because of scale (there will be impacts all _over_ the code). But it's not really. No user will much care.16:40
Maybe just a really fat ticket.16:41
<acoburn>awoods: will the ~April move to java8 necessitate another minor version upgrade? That is, 4.216:42
* osmandin leaves
<ajs6f>awoods: Actually, I take that back. We still have the whole machinery of subtasks in Jira available. That seems like a better tool.
One of the things about so-called semantic versioning that I don't like (although I like a lot) is that it's essentially outward-facing.16:43
It's interested in impacts on clients of a deployed service, not impacts on infrastructure supporting that deployment.16:44
(Like shifting JVMs.)
acoburn: In awoods absence, let me turn that question around: would _you_ expect a minor-version bump on the basis of a JVM shift?17:00
awoods'
<jcoyne>ajs6f: that's what Solr did17:01
* mikeAtUVa leaves
<ajs6f>jcoyne: A good point.17:02
<jcoyne>< 4.7 supported JVM 6
4.8 was 7+
<ajs6f>Right, right.
<acoburn>ajs6f: I'm not sure. I'd generally expect a new point release (4.1.1) would run on the same infrastructure that 4.1.0 ran on
<ajs6f>acoburn: Is that one-tenth of a positive answer?17:03
<acoburn>ajs6f: but with a minor release there's some recognition that there is a change
<ajs6f>ruebot: Any thoughts about the opinions likely to be found in your community?
<acoburn>ajs6f: If I had to choose, I'd say that incrementing to 4.2 would make sense
<ajs6f>acoburn: Right, but the change is normally measured across client behvior.
Maybe it doesn't matter. Maybe the audit functionality will be so utterly silencing that a minor version bump becomes the obvious choice.17:05
<acoburn>ajs6f: true. I don't really have a strong opinion. I just thought that, given that the earlier expectation was that 4.1 would support migration from 3 -> 417:06
ajs6f: and (depending on how awoods frames the announcement), if the new expectation is that a 4.2 version would have better support for migrations17:07
<ruebot>ajs6f: jcoyne's point about solr makes sense to me
<ajs6f>Yes, that's another thing. I didn't think much about the announcement that 4.1 would concern itself with migration, but it now seems premature. But 20/20 hindsight.
ruebot: Fair enough.17:08
<acoburn>ajs6f: I wanted to just raise this before we set expectations about which version will support certain features
<awoods>ajs6f/acoburn/ruebot: off hand, I would expect a minor version bump for a JVM upgrade17:09
<ajs6f>acoburn: I think you're right to raise the question.
<awoods>That is what we did for 3.8
<ajs6f>awoods: I don't disagree, but it has to be admitted that the 3-series versions made as much sense as ice-cream flavor combinatorics.
<ruebot>I guess the biggest thing is communicating what version is the migration version. But, the more we talk about it, it doesn't sound like that will be a version of Fedora. But, instead a stand alone utility/tool.17:10
* ruebot snorts
<awoods>ruebot: it is a slight of hand...17:11
keep them looking at the version...
then boom, an out of band utility does the job.
<ajs6f>ruebot: In all seriousness, you're pointing at the very real fact that the architecture was never versioned independently of the reference impl, a notion that barmintor has (rightly) whaled on in various fora.17:12
<ruebot>Maybe we need to have a rationale paragraph with ever release note stating the rationale for the version increment :-)17:17
* ajs6f leaves
<awoods>not a horrible idea
<ruebot>At least these version numbers are saner than the Islandora version numbers which are tied to Drupal version numbers :-\17:18
* acoburn leaves17:31
<ksclarke>Drupal versioning is the worst17:40
or maybe it's just the paired drupal + module versioning that's so painful17:41
* ksclarke leaves18:14
* ksclarke joins18:32
* awead leaves18:33
* scossu leaves19:00
* jcoyne leaves19:23
* jcoyne joins19:54
* dhlamb joins20:16
* dhlamb leaves20:21
* jcoyne leaves20:34
* dhlamb joins20:46
* jcoyne joins21:20
* jcoyne leaves21:28
* jcoyne joins21:32
* jcoyne leaves23:12
* ksclarke leaves23:33
* dhlamb leaves23:49
* jcoyne joins23:53
* jcoyne leaves00:08

Generated by Sualtam