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

Using timezone: Eastern Standard Time
* apb18 leaves00:55
* chadmills joins03:12
* cmmills leaves03:16
* thomz joins03:47
* manez joins07:59
* manez leaves08:03
* coblej joins08:26
* manez joins08:39
* manez leaves08:54
* manez joins08:56
* apb18 joins08:58
* apb18 leaves
* acoburn joins09:17
* kestlund joins09:20
* tolloid joins09:21
* ajs6f joins09:26
awoods: As acoburn pointed out yesterday, my rearrangement in the specs broke the link targets at fedora.info. Do you want to mess with that now or wait until we get a little further? I have what I think will be the final form for links (a single doc named index.html).09:27
<awoods>ajs6f: I am happy to resolve the issue now...09:36
<ajs6f>awoods: Okay— I have no idea how fedora.info is managed, or even what actually runs it.
* esm_ joins09:37
<awoods>ajs6f: You what the spec to live at: http://fedora.info/spec/index.html09:38
ajs6f: we could probably give it a better name
<ajs6f>awoods: To be published there, yes. And in Github, there is now an index.html which is that doc (obviously incomplete and buggy, but it is there).
<awoods>ajs6f: why "index.html"?09:39
<ajs6f>awoods: What do you want to call it. I called it index.html so that http://fedora.info/spec/index.html goes right there.
<acoburn>awoods: like http://fedora.info/specification/index.html ?
* thomz leaves
<ajs6f>awoods: I mean so that http://fedora.info/spec goes there
<awoods>ajs6f: we can manage apache... without having to name things index.html09:40
<ajs6f>awoods: So what do you want to call it?
<awoods>ajs6f: let's brainstorm...
fedora-api ?
<acoburn>I'd be in favor of no name (hence index.html)09:41
<awoods>acoburn: what is your rationale?
<ajs6f>awoods: I do no care. Call it whatever you want, make a commit, and let me know so I can pull the rename. I would be fine with pukebucket.html or corvette.html or eggplant.html or whatever and I also think index.html is simplest.09:42
<acoburn>awoods: most web publishers have abandoned simple file names with extensions
awoods: look at every W3C spec
<acoburn>awoods: exactly09:43
<awoods>acoburn: to you think there is an index.html under that?
<acoburn>awoods: who knows and who cares
awoods: _that_ is the point
<awoods>acoburn: exactly... as long as we are not advertising the link to the spec as: http://fedora.info/spec/index.html09:44
<acoburn>awoods: right, it should be http://fedora.info/spec/
* kefo joins
<awoods>acoburn: agreed
* peichman joins09:45
<awoods>acoburn: although, will we also want to redirect to the most recent version?
<acoburn>awoods: really?09:46
<awoods>acoburn: yes, it was a question
<acoburn>awoods: that's not what W3C does
<awoods>acoburn: It looks like they publish the most recent draft at two URLs09:47
<acoburn>awoods: they publish the current version at the defined location with a link to a "versioned" url with the current and previous versions
<acoburn>awoods: but browsers aren't redirected
awoods: I like the way W3C does it
<awoods>acoburn: maybe we should consider a similar approach for our ontologies09:48
<acoburn>awoods: it would be really easy for someone to bookmark a "versioned" publication and not know that there is a newer version available
awoods: I'd be in favor of that
awoods: see, even ruby-rdf fell into that trap and they're using an old version of the Fedora ontology: https://github.com/ruby-rdf/rdf-vocab/blob/develop/lib/rdf/vocab.rb#L13809:49
<awoods>acoburn: I suppose they did that because they actual care about pointing to a specific version of the ontology.09:50
<acoburn>awoods: well, it's an outdated version09:51
<awoods>acoburn: which would still be possible in the W3C approach
<acoburn>awoods: who knows why they are using that version
<awoods>acoburn: I suppose they will upgrade when they need to
<ajs6f>the check the w3c uses is to include a link in every version to the place where you will find the latest version
just a link rel=canonical, basically
not foolproof, but you can't be09:52
<acoburn>awoods: it just seems cleaner to not redirect the browser, but I also don't feel very strongly one way or the other
awoods: I'm also not the one who's configuring the server09:53
<awoods>acoburn: I am happy to transition the approach
<acoburn>awoods: I like ajs6f's suggestion to include a re=canonical link header
<awoods>acoburn: I think he was speaking in metaphor, but it is a good idea09:54
transition the hell out of that approach, awoods
<acoburn>I see a rel=original link header on the versioned resource (i.e. for the W3C)
<awoods>thanks, ajs6f!
acoburn: what does it point to?
<acoburn>the W3C also includes a memento timegate header09:56
awoods: have a look: curl -IL https://www.w3.org/TR/2015/REC-ldp-20150226/
<ajs6f>yeah, maybe we should actually _use_ the tech we are pushing on our hapless users
<awoods>crazy talk09:57
<ajs6f>i'm going to keep pushing to index.html unless someone stops me10:08
<ajs6f>crap. the authz document isn't actually a spec at all. it's a list of large-scale _requirements_.10:09
sort of10:10
<awoods>ajs6f: sounds like we can work with index.html10:11
* whikloj joins10:17
* esm_ leaves10:19
* apb18 joins10:20
<whikloj>ajs6f: what can I help with10:24
<ajs6f>whikloj: want to rewrite the atomic op spec to discuss headers instead of URIs?
whikloj: Or convert the messaging spec into ReSpec?
<whikloj>ajs6f: I can give either a go, which would you prefer10:25
<ajs6f>whikloj:acoburn: is the messaging spec ready to convert?
<acoburn>ajs6f: yes — it would be nice to add some non-normative language with examples10:26
ajs6f: but that can also happen with PRs on the repository later
<ajs6f>acoburn: okay.
whikloj: If you work on the messaging spec, we will have to align so as not to crash into each other while simultaneously editing the spec doc.10:27
whikloj: OTOH, you can work on reworking the atomiop doc orthogonally to me.
<whikloj>ajs6f: the spec doc is in Github? or are you doing that now?
* coblej leaves10:28
<ajs6f>whikloj: the big doc is in github in respec form and I am going through the google docs pulling the information in them out of them into the github doc
<whikloj>ajs6f: ok, I'll take a shot at the Atomic Op spec. Best to avoid trampling over each other10:29
no, whikloj++++
<whikloj>ajs6f: sent a request for edit access to the Atomic Google doc10:30
ajs6f: assuming you'll get it10:31
<ajs6f>whikloj:awoods ^^^
<acoburn>ajs6f: I don't have permissions to push to the fcrepo-specification repo (it's fine to work from my own fork, but just FYI)10:32
<ajs6f>acoburn: I thikn I can fix that, hang tight
<awoods>whikloj: you now have access to the google-doc10:33
<ajs6f>awoods: I'm going to add acoburn to the committers group for the spec
<ajs6f>wait, no I'm not. I am not an owner of that repo
but I did send a link to add acoburn as a write-enabled member10:35
<acoburn>looks like I'm all set now
thanks everyone!
* ajs6f leaves10:36
* ajs6f joins10:45
* coblej joins10:47
<whikloj>So switching to using headers for Atomic Op means we lose the ability to extend the operation, unless someone has an idea around that?10:57
<awoods>whikloj: because there is no URL to POST against?
<whikloj>awoods: yes, because the "extend" was a POST to a specific URL. Now we just add a header to any other PUT/POST/PATCH/DELETE.10:58
awoods: It may not be widely used and therefore not that important though
<awoods>whikloj: hmm, that is a factor in deciding to go with batchop paths or headers10:59
<whikloj>awoods: though we could say an implementation MAY allow a ??? operation to the root including a ??? header which would duplicate the functionality11:01
<ajs6f>whikloj: no, you extend just by continuing to send any request with the atomicop header.
whikloj: that could be a simple get
if anything, it's is _simpler_ and more RESTful than the URI approach in that respect.11:02
<whikloj>ajs6f: ohhhh yeah, never thought of it that way.
awoods: ok ajs6f solved the problem
<ajs6f>whikloj: That's because you are a sane, level-headed Canuck.
<whikloj>ajs6f: So then what about static expirations, how do we allow for not extending?11:03
<awoods>whikloj: the spec should probably call out the fact that each request extends the atomicop, including GET
<ajs6f>awoods: I am inventing a lot of this authz stuff. I'm just doing the same thing we are trying to do elsewhere— interpret X (in this case WebAC) in light of LDP.
awoods:whikloj: yes, but specifically, each request _asks_ to extend. It is impl-choice whether that succeeds always, never, or sometimes, and if sometimes, when and why11:04
awoods: Luckily, henry story wrote this webac thing, so it jibes with LDP already for the most part11:05
<whikloj>awoods/ajs6f: So to allow for static expiration, we have to allow for a second header at atomic op creation to set the expiration, and allow for a second header for each request to NOT extend the expiration.
<ajs6f>whikloj: wait, what? why? Why would we need either of those things?
whikloj: static exp is a _server_controlled thing, not a client-controlled thing
<whikloj>ajs6f: Did tjohnson want to set a static expiration, like I want my batches to expire at noon everyday?11:06
<ajs6f>whikloj: what tjohnson was saying was that a _server_ may want to set a drop-dead date
whikloj: not that a client would _ask_ for that.
<awoods>ajs6f: WebAC: There are some deltas between the W3C wiki on webac and Fedora's impl... due to ambiguities on the w3c side. We will want to include those deltas in our spec.11:07
<ajs6f>whikloj: and I don't think we let clients ask to not extend an op. If they want to see that they don't send requests to add it after a certain point.. well, they are the client. they can just… NOT send requests after a certain point
awoods: Sure, but I'm not there now.
<awoods>ajs6f: understood
<ajs6f>awoods: In fact, I would really want someone who isn't me to look at that. It's getting really unhealthy to have me this involved with the whole spec thing11:08
awoods: except atomicops and messaging whikloj++ and acoburn++
awoods: and maybe fixity. Depending on what ruebot says to me later today.
<awoods>ajs6f: where do you feel the most unhealthy?11:09
<ajs6f>awoods: My knees, definitely. Lot of soreness after lifting weights, especially heavy squats.
awoods: Also I don't always handle stress well.11:10
<awoods>ajs6f: Those seems unrelated to the spec, but good to know.
<ajs6f>awoods: Sometimes I feel like I lack creative outlets.
<awoods>ajs6f: I could be wrong
<ajs6f>awoods: Sometimes I have a vague sense of foreboding and anxiety.11:11
<whikloj>ajs6f/awoods/acoburn: Do we need to specify what the Headers to use for creating, identifying, committing an atomic op in the Spec?
<ajs6f>whikloj: yes.
<whikloj>ajs6f: thoughts?11:12
<ajs6f>whikloj: That is pretty much the content of the spec
whikloj: Let me poke around
<whikloj>ajs6f++ # I looked before but was unsuccessful
<awoods>whikloj: btw, 4.6.1 vagrant looks good
<ajs6f>whikloj: I don't think there is much off-the-shelf, but there might be something somewhere
ajs6f: Also, we (and I haven't yet looked for this). we need a Link header to return the AtomicOp ID on create11:13
<ajs6f>whikloj: Yes.
awoods:acoburn:whikloj:et al what about X-Correlation-ID for passing the atomicop ID around, both req and response?11:17
It warps the usual semantics a bit, but...
<awoods>ajs6f: https://tools.ietf.org/html/rfc664811:18
<whikloj>ajs6f: it seems close enough, I was wondering about commit/rollback should we use a single X-???-action header with multiple values or two separate headers
<ajs6f>awoods: Not applicable. that's for _new_ headers. This isn't new (if we use it).
awoods: But I'm fine with using something new, because X-Correlation-ID isn't exactly what we want.11:19
awoods: In which case, yes, we avoid X-.
<awoods>ajs6f: where is X-Correlation-ID spec'd?11:20
<whikloj>X-Request-ID?? https://devcenter.heroku.com/articles/http-request-id
<acoburn>alternately, a link header with rel="http://fedora.info/definitions/v4/repository#hasTransactionId", which would require amending the ontology
<ajs6f>awoods: It's not— it was in wide use and is still, for example for microservices approaches
<acoburn>I'd be fine with X-Correlation-ID
<ajs6f>whikloj: I don't think that we can use that— it's specific to one request, and we are specifically interested in multiple reusts.
acoburn: Hm. INteresting. Links, you say? Use links on the Web… well, why not?11:21
<whikloj>ajs6f: ah ok, didn't think of it that way but yes I see
* tolloid leaves11:22
<awoods>acoburn: in the Link header case, would the atomicop ID need to be a URI?
<acoburn>awoods: yes: <info:fedora/blah-blah-blah>
<ajs6f>awoods: acoburn: well, really we want something dereferencable there.11:23
<awoods>ajs6f: it would be unique and transient, no?
<acoburn>ajs6f: really?
<ajs6f>awoods: I'm not saying I can think of a good reason for a client to dereference it. I'm saying that the semantics of Link are so.11:24
awoods:acoburn: I'm not going to freak out about it.
That would go beyond my aforementioned vague sense of foreboding and anxiety.11:25
<awoods>whikloj: are you all done with 4.6.1?
<acoburn>ajs6f: https://tools.ietf.org/html/rfc5988#section-5.111:26
ajs6f: it just specifies that the target IRI is a URI reference
<whikloj>awoods: I think so, the webapp-plus artifacts are good and fcrepo4 has its one-click and normal wars.
<ajs6f>acoburn: Yeah, I know it's not MUST. But common practice is certainly that you can follow links on the web.
acoburn: Like I said, I'm not going to bleat or maunder about it.11:27
<acoburn>ajs6f: and I'm totally fine with using X-Correlation-ID
<ajs6f>acoburn: We can leave it undefined. I think that's okay for now. Any impl can think of their own way to fill that slot.
<whikloj>ajs6f/acoburn: Alternatively we create a new resource to which now holds atomic op information and return that...should be simple
<awoods>whikloj: thanks, I will finish the wiki work then send out the announcement for both 4.6.1 and 4.7.0
<ajs6f>acoburn: I actually like your link idea more now, because X-Corr doesn't really mean what we want.11:28
<awoods>ajs6f: ^^ my sentiment as well
<ajs6f>whikloj: NOT SIMPLE. Think of the distributed case. Also, then we get into a whole nest of weird questions about what we are doing and how that new resource is addressable (via what methods).
<whikloj>fine...kill joy11:29
<ajs6f>whikloj: And pretty soon we are back to URI-based interactions except now we have a layer of header lard spread on top.
acoburn:awoods:whikloj: Ok, let's play acoburn's link idea out. How does it work to begin/commit ops?
I think we need something else there.11:30
<whikloj>ajs6f: I think we need a header to start the atomic op11:31
<acoburn>what I'm thinking is that any resource includes a header like: Link: <http://localhost:8080/fcrepo/rest>; service="http://fedora.info/definitions/v4/repository#hasTransactionService"
then, you POST to that service location
that POST response contains the appropriate Link header11:32
a client uses that link header for all subsequent interactions
<whikloj>acoburn: so the actual interaction is the same as now, just how you get started is different?
<ajs6f>some people use a diff hybrid https://books.google.com/books?id=5CjJcil4UfMC&pg=PA400&lpg=PA400&dq=http+acid+transaction+begin+header&source=bl&ots=SRPVcQINP3&sig=5ChjJcGe0SZV1AVaQRvDqBBbpp0&hl=en&sa=X&ved=0ahUKEwjkte-x3bLQAhUF5SYKHbP8BP4Q6AEITTAI#v=onepage&q=http%20acid%20transaction%20begin%20header&f=false
<acoburn>whikloj: that's just one idea11:33
<ajs6f>acoburn: You want to start by addressing an URI but then walk away with that "location" and use it in a header, eh?
acoburn: Miscegenation for art's sake.
<acoburn>ajs6f: in principle, the target of that link header could be the resource itself11:34
<ajs6f>acoburn: Wait, what? Walk me through how that would work.
<acoburn>ajs6f: right now there's this /fcr:version service on every resource
ajs6f: say we have a /fcr:batch service available, too11:35
<ajs6f>acoburn: yes, that is what we are going away from
acoburn: We are shifting to memento to get _rid_ of that kind of magic endpoint.
<acoburn>ajs6f: the name is irrelevant, and it's not magic if there's a link header pointing to it11:36
<ajs6f>acoburn: I'm not saying have fcr:transaction or whatever wouldn't work, I'm saying two things: one, that's no better than having a special "Start-Atomic" header.
and two, there's a question about how this interacts with create-on-PUT.
although I don't think we need to go too far into that second thing instantly.
<awoods>whikloj: did you push the 4.6.2-SNAPSHOT artifacts to sonatype?
<acoburn>ajs6f: at present, there's a clear separation b/t batch operations and single operations
ajs6f: batch ops have sessions that get put into an in-memory map11:37
<whikloj>awoods: I have not, I'll start that too.
<ajs6f>acoburn: That's impl stuff that no client knows. From the API, there are just resources, some of which have an extra URI-segment and magic semantics.
<acoburn>ajs6f: yes, I know those are impl concerns11:38
<ajs6f>acoburn: For the spec, we can only take the client POV.
<acoburn>ajs6f: still, how do you start a batch op?
ajs6f: and how do you commit a batch op (or roll it back)?
ajs6f: those are different than manipulating resources in the context of a batch op11:39
<ajs6f>acoburn: Yes, I know. I'm not saying I have a great answer. I'm saying that a pair of extra headers (or extra syntax on some Control-Op header) is no worse than anything else.
<acoburn>ajs6f: the headers approach deals with the latter issue — manipulating resources in the context of an existing batch op
ajs6f: I'm not sure it answers how you initiate/commit/rollback the operation11:40
<ajs6f>acoburn: No, it does that and it can do control as well, just not with the same header.
like Start-Op, Abort-Op, Commit-Op
* github-ff joins
[fcrepo-module-auth-xacml] awoods deleted jersey2 at a56739e: https://git.io/vX5NA
* github-ff leaves
<ajs6f>or or Control-Op with syntax a la link: Control-Op: op=info/myop;mode=commit
<whikloj>or Atomic-Op-Cmd: Start|Abort|Commit
<acoburn>ajs6f: that structure works for me11:41
<whikloj>ajs6f/acoburn: Maybe I'll also try and write up acoburn's idea as I understand it. Just for an alternative view
<ajs6f>whikloj: Yeah, sure. Not saying these things are perfect, just that they are at least as intelligible and practical as special endpoints. That have to be discovered by headers anyway!
<acoburn>ajs6f: so in principle, you could start a batch op with any HTTP operation (GET/PUT/POST, etc)11:42
<ajs6f>whikloj: Okay by me. But let's keep moving. I want to have something substantially done by T-giving.
acoburn: Exactly right.
acoburn: It's an accent of the ordinary HTTP vocab, not a new dialect.
<acoburn>ajs6f: and the header that's returned by that includes information that gets re-used in subsequent operations
<ajs6f>acoburn: Right, maybe via your Link idea.
<acoburn>ajs6f: so, say you want to create 3 resources in a batch operation —11:43
<ajs6f>acoburn: although I think we have to think about whether that is really what link means.
avoburn: Three POSTs.
<acoburn>ajs6f: right now there are 5 POSTs, but with this approach there could be only 3
I like that
<ajs6f>Smaller is better. We need to make Fedora smaller and cuter. More kawai.11:44
* github-ff joins
[fcrepo-module-auth-webac] awoods deleted PR-27 at 2934f6d: https://git.io/vX5AS
* github-ff leaves
<acoburn>ajs6f: is there a way to know when the batch op expires?11:45
ajs6f: right now, when you POST to /fcr:tx, you get an Expires header
<ajs6f>acoburn: Bake it into the op identifier?
acoburn: No, that's crappy.
acoburn: I guess it's a case of once you start with your own headers, you keep going.11:46
* github-ff joins
[fcrepo-transform] awoods deleted ForAcoburn at 0858854: https://git.io/vX5Ax
* github-ff leaves
<ajs6f>acoburn: Atomic-Expires or something...
<acoburn>ajs6f: I haven't ever used that Expires header11:47
<ajs6f>acoburn: Or maybe we go back to what whikloj was threatening and make the atomicop ID dereferenceable, but spec that the only MUST is GET, and GET has no defined body but does require the presence of Expires?
<acoburn>ajs6f: and what happens when you interact with Fedora using an expired header?
<ajs6f>acoburn: maybe 409… have to think a bit, but 409 sounds right.
<acoburn>ajs6f: yes, that's what happens now11:48
<ajs6f>acoburn: The conflict is bettween two states of the resource— the one you are addressing in-op via the header, and the one that the server can let you address (out-of-op because the op is dead)
<acoburn>ajs6f: but there's some subtlety there — the resource may actually exist
<ajs6f>acoburn: That's fine. We return 409 from extant resources all the time.
* github-ff joins11:50
[fcrepo-audit] awoods deleted fcrepo-1556.test at aff7752: https://git.io/vX5xr
* github-ff leaves
<whikloj>ajs6f/acoburn: So if you specify X-Correlation-ID but not X-Atomic-Start and the ID is not found. Return 409?
<ajs6f>whikloj: I don't think we want to use those exact headers, but to your question, that's plausible to me.
<acoburn>yes, that works for me11:51
<whikloj>ajs6f: yeah actually headers are TBD
ok and a batch that never existed returns the same response as a batch that has expired?
<ajs6f>whikloj: although maybe the semi-standard 424.
or 412 Precondition Failed11:52
<acoburn>I like both of those better than 409
<ajs6f>They are more specific, but less common
that's always the way
I've got to run. I will check in later.11:53
* github-ff joins
[fcrepo4-vagrant] awoods deleted FCREPO-2157 at 6e24eed: https://git.io/vX5pf
* github-ff leaves
<ajs6f>I feel like I've done enough to confuse whikloj this morning. I feel confident that I have prevented him from making any sense of this stuff.
<whikloj>ajs6f: you have done well grasshopper
* ajs6f leaves11:54
<acoburn>awoods: I've noticed that lately, travis builds of Fedora will periodically fail with a VM crash11:56
awoods: I have seen this before in other projects, related to exhausting memory resources11:57
awoods: would you be opposed to doing something like this: https://gitlab.amherst.edu/acdc/repository-extension-services/blob/master/.travis.yml
awoods: it turns off a bunch of unused travis services to make more memory available to Fedora11:58
* coblej leaves11:59
<awoods>acoburn: sounds like a good idea... do you see any drawback to the .travis.yml update?12:03
<acoburn>awoods: not really12:04
* coblej joins
<awoods>acoburn: nothing obvious jumps out... let's give it shot
* github-ff joins12:05
[fcrepo-audit] awoods closed pull request #42: Update dependencies (master...fcrepo-2285) https://git.io/vX33D
* github-ff leaves
<whikloj>awoods/acoburn: thoughts? https://docs.google.com/document/d/1Ij4lFomcOJuOiWptZPyhP_wBRtxbqBP3_Rdw1eKmClM/edit12:06
<awoods>acoburn: which repos have you seen crash?
<acoburn>awoods: fcrepo
<awoods>acoburn: so maybe one PR would be fine for now... targeting fcrepo12:07
<acoburn>awoods: yes, I can get you one in just a sec
<awoods>acoburn: also, wrt the 4.7-maintenance branch...
acoburn: it has a few more commits on it than master
acoburn: we may already be in a state where moving master commits over is not perfectly clean.12:08
* github-ff joins12:09
[fcrepo4] acoburn opened pull request #1144: update travis configuration (master...travis_updates) https://git.io/vX5jg
* github-ff leaves
* coblej leaves
<acoburn>awoods: I see the maven release plugin commits
awoods: what commits are you referring to?
awoods: there's mikeAtUVa's commits related to the locking behavior12:10
<awoods>acoburn: https://github.com/fcrepo4/fcrepo4/commits/4.7.0-maintenance
<acoburn>awoods: that's what I'm looking at
<awoods>acoburn: yes, mikeAtUVa's
<acoburn>awoods: but those are also in master
awoods: personally, I don't understand why we have a 4.7-maintenance branch12:11
<awoods>acoburn: how do you see mikeAtUVa's commits being different than Elliot's?
<acoburn>awoods: once master diverges from the 4.7 series, then we should have a 4.7-mainteance branch
awoods: OR, we should cherry-pick _every_ non-breaking commit that goes into master12:12
awoods: AFAICT, master hasn't diverged from 4.7
<awoods>acoburn: that's right
<acoburn>awoods: then why do we have a 4.7-maintenance branch?12:13
<awoods>acoburn: how do you see mikeAtUVa's commits being different than Elliot's? ...you were concerned about pushing Elliot's commits to the 4.7-maintenance branch
<whikloj>acoburn: that's my fault. I created it when making 4.7.0.
acoburn/awoods: It could conceivable by turfed for now
<awoods>whikloj: wait
<whikloj>awoods: I'm not going to delete it, just saying it could be12:14
<acoburn>awoods: Mike's commits were part of the RC branch that went into the release
<awoods>acoburn: It sounds like we need reestablish our approach.
<acoburn>awoods: I think we haven't clearly documented what our approach is
<awoods>acoburn: the idea has been to create a maintenance branch when we release a major release
acoburn: and targeting master to the next major release12:15
<acoburn>awoods: my idea was to create a maintenance branch once master has breaking changes
<whikloj>acoburn/awoods: You are in agreement
<acoburn>awoods: as it is, I could cut a release today from master, creating a 4.7.1 release
awoods: by simply ignoring the 4.7-maintenance branch
awoods: once something goes into master such that it is no longer backwards compatible, _then_ we need a 4.7-maintenance branch12:16
awoods: alternately, we create the 4.7-maintenance immediately after the 4.7.0 release and then cherry-pick every non-breaking change from master12:17
awoods: I don't like that because it means more work for a very small developer community
awoods: you will notice that fcrepo-camel-toolbox has been using 4.70-SNAPSHOT for some time, but I created a 4.6.2 release this week directly from master12:18
awoods: I could do that b/c there have been no breaking changes12:19
<awoods>acoburn: help me understand your concern with Elliot's PR going to 4.7-maintenance... is the issue that his PR is one bug fix, and if that PR goes to 4.7-maintenance then all other master commits should as well?12:20
<acoburn>awoods: my concern is this — we shouldn't have a 4.7-maintenance branch12:21
<awoods>acoburn: I get that
* dbernstein joins
<acoburn>awoods: so there shouldn't be a PR targeting that branch
<whikloj>awoods: So we are adding to the workload by maintaining 2 branches unnecessarily
<acoburn>awoods: what whikloj said
awoods: I am certainly not going to backport non-breaking changes from master to the 4.7-maintenance branch12:22
awoods: changes that _should_ go into a 4.7.1 release
awoods: changes that I was _expecting_ would go into a 4.7.1 release
<whikloj>My only concern is we need to understand what a breaking change it _before_ it is committed to master, or we have to do extra work to remove it from the maintenance branch
* dwilcox joins12:23
<acoburn>whikloj: easy — if there's a breaking change the commit gets reverted in the RC branch
<awoods>acoburn: and if there is no branch, create it?
<acoburn>whikljo: and developers make an effort not to make breaking changes
<whikloj>acoburn: fair enough
<acoburn>awoods: there is _always_ an RC branch
acoburn: not during development
acoburn: RC branches happen during release
<acoburn>awoods: but during release: https://github.com/fcrepo4/fcrepo4/releases/tag/fcrepo-4.6.1-RC-2
awoods: then you make one
<whikloj>acoburn/awoods: So at the point of a breaking change or release we cut a new maintenance branch _if and only if_ the release is a major one12:25
or it is a breaking change, which usually means we do a release too
<dbernstein>acoburn: what’s the status on the translator refactorings? Just curious - I have a hybox meeting shortly and wanted to report where things stand.12:26
<awoods>acoburn: this all sounds fine... but noting the fact that the topic of maintenance branches originally came up because our RCs had 4.8.0-SNAPSHOT versions, which confused the community.
<acoburn>dbernstein: I'm down to only 42 failing tests in fcrepo-http-api
dbernstein: yesterday I had 123 failing tests12:27
dbernstein: and the day before, I had failing unit tests
dbernstein: before that, it didn't compile
dbernstein: it is a HUGE change to the codebase
dbernstein: and it is taking time
<whikloj>awoods: where are the snapshots published too?
<dbernstein>acoburn: so it sounds like it’s moving right along - thanks for the update.12:28
<awoods>whikloj: for example: https://oss.sonatype.org/content/repositories/snapshots/org/fcrepo/fcrepo-http-commons/
whikloj: https://wiki.duraspace.org/display/FF/Fedora+Release+Process#FedoraReleaseProcess-Optional-DeploySnapshotArtifacts
<acoburn>awoods: actually, the release was for 4.6.0, but the snapshots were for 4.5.2-SNAPSHOT
<whikloj>awoods++ #Doh
<dbernstein>acoburn: and it goes almost without saying that I really appreciate your willingness to push on that.
<awoods>acoburn: the point is the same, that the RCs have a confusing version, no?12:29
<acoburn>awoods: that's pretty easy to handle with the maven release plugin — you just set the "release" version to be 4.x.x-RC
awoods: that's up to the release manager
awoods: if I were releasing 4.7.1, I'd push a snapshot to 4.7.1-RC, not 4.8.0-SNAPSHOT12:30
awoods: and the new development branch goes back to 4.8.0-SNAPSHOT
* dwilcox leaves12:31
<awoods>acoburn: you mean in your RC branch you would add a commit that changes the version number to 4.7.1-SNAPSHOT from 4.8.0-SNAPSHOT
<acoburn>awoods: no — it would have a commit that changes 4.8.0-SNAPSHOT to 4.7.1-RC112:32
awoods: there's be a tag set at that point in the repo
awoods: if there are further changes, a branch starts from that tag
<awoods>acoburn: I think maven would complain about the version not being -SNAPSHOT
<acoburn>awoods: are you sure?
awoods: plus, it's the "release", not the snapshot12:33
<awoods>acoburn: I think the release plugin acts on -SNAPSHOT
acoburn: although the naming of the "snapshot" version is not the main point...12:34
<acoburn>awoods: then make it 4.7.1-SNAPSHOT
<awoods>acoburn: the point is that you are suggesting the confusion be addressed by updating the version as the first act after creating the RC branch.
<acoburn>awoods: yes12:35
<awoods>acoburn: The only challenge I see here is that Fedora committers need to know to create a -maintenance branch when a breaking commit is proposed.12:36
<acoburn>awoods: shouldn't it be clear when there is a breaking change?12:37
<awoods>acoburn: usually
<acoburn>awoods: and if it turns out that something is a breaking change, it can either be reverted for the patch release or the next version can be a new minor revision12:38
awoods: it's not like we're actually using semantic versioning now12:39
<awoods>acoburn: All that said, it sounds like we can safely delete the 4.7.0-maintenance branches from the various modules.12:40
<acoburn>awoods: yes, that would be great12:41
<awoods>whikloj: I assume you agree?
<whikloj>awoods: I think so... we are proposing that master will sit with version of the next major version and if the release is a patch, then adjust on the RC branch12:43
<awoods>whikloj: yes, and if a breaking change is needed, then create a -maintenance branch.12:44
<whikloj>awoods: But the maintenance branch would be created after the release, no?12:45
<awoods>whikloj: ..prior to committing the breaking change
<acoburn>awoods: I'd add that my interest in this is _only_ about making sure that development isn't frozen during the 3+ weeks of release testing
awoods: and the previous DEV branch shenanigans were confusing
awoods: I'm not sure that this is _less_ confusing, but this is what other projects do12:46
<whikloj>awoods: assuming you know it is a breaking change, otherwise we will have to revert as acoburn said
<awoods>whikloj: based on your comment: "But the maintenance branch would be created after the release, no?", I am not sure we are on the same page.12:47
<whikloj>awoods: I am going on the expectation that before we added a breaking change we would cut a release, but you are making the case for including a breaking change in the middle of a dev cycle and just cutting a maintenance branch.12:48
awoods: But that maintenance branch could therefore have more commits than the last release from that major version
4.7.1 -> X commits -> cut maintenance branch -> commit breaking change -> stuff happens -> major release12:49
<acoburn>my preference would be that we identify breaking changes _before_ development happens (i.e. in Jira)12:50
and that we are clear when breaking changes go into master
<whikloj>awoods/acoburn: Agreed, and I would suggest performing a release as close to (but before) the implementation of that change
<awoods>whikloj: you raise a good point... thanks for clarifying your scenario.
<acoburn>whikloj: yes, exactly.12:51
<whikloj>awoods/acoburn: Ok, I think we are in agreement
<acoburn>whikloj: this is exactly why the MODE5 update happened quite soon after the 4.6.0 RC was cut
whikloj: at that point it was clear that master was now on a different trajectory than the 4.6 series12:52
* dwilcox joins
<whikloj>acoburn: right, and had there been no issue with MODE we may never have needed a 4.6.1
<acoburn>whikloj: yes
* dwilcox leaves12:53
<acoburn>awoods: w/r/t the travis updates — hold off on that PR — maven central seems to be having trouble with it's SSL cert, and so _all_ travis builds are failing
awoods: if you go to https://repo.maven.apache.org/, you should get an SSL cert error12:54
whikloj: and after the 4.6 release, we also knew that we needed a 4.6-maintenance branch b/c master had diverged from that series12:55
whikloj: with the 4.7 release, we haven't had that divergence
whikloj: in fact, I would hope that we'd have _no more_ breaking changes until the specifications are complete
<whikloj>acoburn: I totally agree at this point the 4.7-maintenance branch has no practical purpose12:56
<acoburn>whikloj: that is, we shouldn't change the API at all until we know what we're changing it to
* peichman leaves
<whikloj>acoburn: right
* peichman joins12:58
* ajs6f joins
<awoods>acoburn/whikloj: I think we are one
<acoburn>awoods++ whikloj++
<whikloj>awoods++ acoburn++
<awoods>acoburn/whikloj: now to capture that in the "Release Process" wiki12:59
<acoburn>awoods: I think that's my cue to go have lunch
<ajs6f>acoburn: when you get backhttps://docs.travis-ci.com/user/ci-environment/13:00
acoburn: Using sudo is _not_ without cost.
Boot Time 1-6s 20-52s
for non-sudo vs sudo
* coblej joins13:04
<ajs6f>whikloj: if a butcher is 6' 2", what does he weigh?
<ajs6f>awoods: I DID NOT ASK YOU.
* ajs6f glares
<awoods>I mean... welcome back, ajs6f13:06
<ajs6f>I no longer like acoburn's idea of using a link header to identify an atomic op.13:14
That seems like… not a link.
I think we should think more about a simple, very human-readable header.13:15
* dwilcox joins13:16
<ajs6f>how does this sound: Start-Atomic, Abort-Atomic, Commit-Atomic, and in between: With-Atomic. All of them would take an ID.13:22
<whikloj>ajs6f: We are making up a lot of headers here
<ajs6f>whikloj: Yes. I admit that. For the URI-based approach, we instead make up a bunch of predicates.
whikloj: And special endpoints with special semantics.
whikloj: We have to put those special semantics somewhere. The wquestion is where.13:23
<whikloj>ajs6f: And the response ID would be?
Atomic-ID ?
* github-ff joins
[fcrepo4] emetsger closed pull request #1142: Insure 304 responses do not contain an entity body. (4.7.0-maint) (4.7.0-maintenance...2313-4.7.0-maint) https://git.io/vX7P9
* github-ff leaves
<ajs6f>whikloj: In the same space are our resources? or in the metaspace of headers?
whikloj: Response ID?
whikloj: You mean how the server tells the client what the id is going to be?13:24
<whikloj>ajs6f: You PUT with Start-Atomic, impl responds with the Atomic ID
ajs6f: yes
<ajs6f>whikloj: With-Atomic
whikloj: works both ways
<whikloj>ajs6f: oh ok
<ajs6f>With-Atomic means "this message is being exchanged in the context of thus-and-such an atomic op"
and the response to Start-Atomic is the second message in that context.13:25
<whikloj>ajs6f: I have updated most of the document, I can add those headers in place of the placeholders.
<whikloj>ajs6f: don't++ until you read it
<ajs6f>we roar ahead like Sandford and Son's pickup truck
cough, cough
<whikloj>awoods: I have pushed all the 4.6.2-SNAPSHOT artifacts...at least I think I got them all13:26
<awoods>whikloj: travis will tell us... thanks.
<whikloj>ajs6f: So we would need X- prefixes to those headers right? X-Start-Atomic, etc13:27
<ajs6f>whikloj: Nope.
whikloj: See awoods' comment to this point above
<whikloj>ajs6f: gotcha13:28
<awoods>whikloj: for your reference: https://tools.ietf.org/html/rfc6648
<whikloj>awoods++ # I dug back through the logs13:29
<awoods>whikloj: lots of logs today
<whikloj>awoods: yes, yes there is. It's causing ruebot's brain to ache13:30
<ajs6f>If anything, all of the _other_ HTTP headers are going to have to put X- in front of _their_ names.
* apb18 leaves
<whikloj>ajs6f: what about "The With-Atomic header MAY be dereferenceable."? I had included that before, but unsure now.
also not sure dereferenceable is a word13:31
<ajs6f>whikloj: 1) I think we can leave that as MAY. Or you can just say nothing.13:32
<whikloj>ajs6f: lastly Atomic-Expires or Expires-Atomic?
<ajs6f>2) Dereferencable is now a word. THAT'S FEDORA.
whikloj: Hm. I think Atomic-Expires makes more sense...
<whikloj>ajs6f: I think so to, but its the reverse of all the other. Just don't want to confuse anyone13:33
<ajs6f>Well, Expires-Atomic seems to me to mean "expires at this time, in an atomic way", which is not what we mean and I don't know what that means.13:34
* dwilcox leaves
<whikloj>ajs6f: I read it as Expire my Atomic at this time, like it was a request header13:36
<ajs6f>whikloj: Well, that's also not what we mean. I also worry about the similarity between Expires and Expires-Atomic. Atomic-Expires just seems more clear to me.13:37
but maybe that's just me
"your atomic expires at this time"13:38
<whikloj>ajs6f: updated the doc. Review when you have time.
Thanks for rolling that joint so quickly. I'll smoke it as soon as I finish with this authz section, which should be soon.
<acoburn>ajs6f: re travis and sudo, I know that there's a cost, but the issue is that Fedora seems to be using up memory and leading to a VM crash. A simple fix is to enable sudo and you get more memory right off the bat (7.5GB compared to 4GB) and you can also turn off non-used services to free up more of that memory pool13:45
<ajs6f>acoburn: oay, although the fact that we can't build inside the (generous) virtual instance is troubling
<acoburn>ajs6f: I don't disagree13:46
ajs6f: re the Atomic ops and headers, would it be more clear if all of the header names started with "Atomic-"?
<ajs6f>acoburn: I do. I find the contention that a piece of software as complex and feature-rich as Fedora should be able to build in any environment whatsoever absurd.13:47
Of course it's going to need more space than some desktop app.
acoburn: i don't think so. i think that kind pseudo-namespacing is what the RFC tyhat awoods linked was frowning on13:50
threy had a specific example X-, but i think te point is more general
* mikeAtUVa joins13:51
<acoburn>ajs6f: ok, but the convention for existing headers suggests otherwise
<ajs6f>acoburn: The question is whether that's a generalizable rule or just historical. I think the latter.
* peichman leaves
<ajs6f>and anyway, atomic is not remotely as well-defined a prefix as content- or accept-
accept-* is each and every one the exact same thing with exactly one variable13:53
that's not true for start-atomic, with-atomic, etc.
<acoburn>ok, I'm certainly not going to press the point
<ajs6f>acoburn: You are welcome to. I'm not going to defend the position.13:54
<acoburn>ajs6f: well, I think they should all start with Atomic-, but I'm not going to say any more about it13:55
<ajs6f>We are a federation of indolence.
* peichman joins
<ajs6f>acoburn: if you want to do the work to edit the spec, you win.
<whikloj_AFK>acoburn: Atomic-With?14:19
<acoburn>whikloj_AFK: something like that14:20
<whikloj>acoburn/ajs6f: Or should we go back to Atomic-ID, both as response and request?14:23
<acoburn>whikloj: that would be simpler
<ajs6f>whikloj: I'm not against it. I _do_ like the semantics of "with", but whatever seems clearest.
<whikloj>ajs6f: I see your point, but I think acoburn also has a valid point about the consistency of Atomic-*. Atomic-ID is not perfect, but I think its clear14:24
<ajs6f>I still prefer Atomic-Burrito, but I'll go with whatever y'all want14:25
<whikloj>ajs6f: only if we batch all requests as one
The best part of the Fifties with the best part of the Seventies!
<whikloj>ajs6f: or as we call it "Rollin your own Atomic-Burrito"14:26
<acoburn>whikloj: even after this goes into the github repo, there will be plenty of opportunity for revision; other people may have better ideas for names
<ajs6f>Sure, like Sextremicus Funkadelica. That's a great name.
<acoburn>yes, that is an excellent example; perhaps we should use that for the name for the 4.6.1 release14:27
<acoburn>ajs6f: it seems that commons-rdf is approaching graduation from the apache incubator, and I would expect a 1.0 release will be quick to follow14:30
ajs6f: that would be a good time to look seriously at using commons-rdf in the core Fedora API
<acoburn>ajs6f: i.e. as part of the alignment of Fedora-as-software with Fedora-as-a-spec
<ajs6f>There are a number of problems
e.g. the use of SPARQL update
<acoburn>but that's part of impl code, which would probably be using jena anyway, no?14:32
<acoburn>ajs6f: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-api/src/main/java/org/fcrepo/kernel/api/models/FedoraResource.java#L130-L13214:33
ajs6f: we're just accepting a String for sparql-update
I guess we can evolve that, too. It could be a (String update, Language lang) kind of thing14:35
<acoburn>ajs6f: as far as I'm concerned, the entire fcrepo-kernel-api is up for review14:36
<ajs6f>acoburn: let's prefix all the method names with Atomic-
<acoburn>ajs6f: there's still some JCR concepts in there: FedoraResource::isFrozenResource14:37
<ajs6f>acoburn: the JCR versioning model left a trail of slime behind it14:38
<acoburn>ajs6f: to this day, I do not understand the JCR versioning model
ajs6f: the whole versioned sub-tree thing makes no sense to me
<ajs6f>acoburn: That's because you are working with an old version.14:39
Anyway, never fear, Memento is here!
<acoburn>ajs6f: that's what I said on the CLAW call yesterday: don't focus on JCR versioning; think about memento
<ajs6f>Herbert Van de Sompel will save us!
* kestlund1 joins14:41
* kestlund1 leaves
* kestlund leaves14:45
* coblej leaves
* coblej joins14:51
* acoburn1 joins15:02
* acoburn leaves15:03
<peichman>acoburn: wanted to update you about our discussion of binary indexing to Solr here at UMD15:07
acoburn: tldr is that it is not a priority for us right now, but we will probably want to revisit it in the future, especially if we have a batch of assets to ingest where we really need indexing of the binaries15:08
<acoburn1>peichman: thanks for the update
<peichman>acoburn: so, I am pretty confident we won't be needing that feature until some time next year at the earliest15:09
<acoburn1>peichman: it's not a huge priority for me either, but I'd also like it eventually
<peichman>acoburn: if you haven't already solved it by the time we need it, we'll be happy to pitch in15:10
release monsters
<awoods>ajs6f: the whole 4.7.0 leap has been a long time coming... it is nice to have it officially behind us.15:18
<ajs6f>awoods: Yes, it's like we've been sitting at a table taking shots all night, and we finally feel ready to pick up the gun and play Russian roulette.15:19
Good felling.
<awoods>I'll have to think about that
<awoods>whikloj: we may as well delete the 4.7.0-maintenance branches15:28
<whikloj>awoods: ok, I'll get rid of them
* github-ff joins15:29
[fcrepo4] whikloj deleted 4.7.0-maintenance at 486e481: https://git.io/vXd0P
* github-ff leaves
* github-ff joins
[fcrepo-module-auth-rbacl] whikloj deleted 4.7.0-maintenance at b473965: https://git.io/vXd0X
* github-ff leaves
* github-ff joins
[fcrepo-module-auth-xacml] whikloj deleted 4.7.0-maintenance at 0fad7da: https://git.io/vXd0D
* github-ff leaves
* github-ff joins
[fcrepo-module-auth-webac] whikloj deleted 4.7.0-maintenance at be2a2fe: https://git.io/vXd0y
* github-ff leaves
* github-ff joins15:30
[fcrepo-mint] whikloj deleted 4.7.0-maintenance at 3fa4af7: https://git.io/vXd0Q
* github-ff leaves
* github-ff joins
[fcrepo-audit] whikloj deleted DEV at 026ffce: https://git.io/vXd0b
* github-ff leaves
* github-ff joins
[fcrepo-webapp-plus] whikloj deleted 4.7.0-maintenance at 123bacb: https://git.io/vXdEv
* github-ff leaves
* github-ff joins15:31
[fcrepo4-vagrant] whikloj deleted 4.7.0-maintenance at 3c36b1a: https://git.io/vXGnI
* github-ff leaves
<f4jenkins>Project fcrepo-module-auth-rbacl build #1224: UNSTABLE in 3 min 30 sec: http://jenkins.fcrepo.org/job/fcrepo-module-auth-rbacl/1224/15:32
<ajs6f>Man, Christopher Walken. Just… man.15:36
* travis-ci joins15:38
fcrepo4/fcrepo4#4855 (master - 5173f6a : Elliot Metsger): The build was broken.
Change view : https://github.com/fcrepo4/fcrepo4/compare/e8e128cd04c1...5173f6aa5b18
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/177132317
* travis-ci leaves
* github-ff joins15:44
[fcrepo4] awoods pushed 1 new commit to 4.6-maintenance: https://git.io/vXdzg
fcrepo4/4.6-maintenance 65c806d Elliot Metsger: Insure that an entity body is not set on 304 responses, per RFC 2616 10.3.5. Addresses FCREPO-2313.
* github-ff leaves
* github-ff joins15:45
[fcrepo4] awoods closed pull request #1143: Insure 304 responses do not contain an entity body. (4.6.0-maint) (4.6-maintenance...2313-4.6.0-maint) https://git.io/vX7Pb
* github-ff leaves
* apb18 joins15:54
* travis-ci joins15:58
fcrepo4/fcrepo4#4856 (4.6-maintenance - 65c806d : Elliot Metsger): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/d1199d82fc7c...65c806d10e6d
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/177135188
* travis-ci leaves
* dhlamb leaves16:04
<f4jenkins>Yippee, build fixed!16:05
Project fcrepo-module-auth-rbacl build #1227: FIXED in 3 min 12 sec: http://jenkins.fcrepo.org/job/fcrepo-module-auth-rbacl/1227/
* manez leaves
<ajs6f>whikloj: What does a thesaurus eat for breakfast?16:14
awoods: not asking you.
<whikloj>I don't know ajs6f, what does a thesaurus eat for breakfast
* mikeAtUVa leaves
I like that one
Have a good weekend all, is thanksgiving 3 days again this year?16:16
<awoods>whikloj: It typically is one day... a Thursday16:17
whikloj: But things may be different in Manitoba
<whikloj>awoods: So Friday is a normal work day?
<ajs6f>They have more to be thankful for16:18
<whikloj>awoods: It is, we have our Thanksgiving in October
<awoods>whikloj: Friday is a holiday... Monday is not, Wednesday is not
<whikloj>awoods: then I'll see you all Monday
<awoods>whikloj: at least that is how it is for me
<awoods>whikloj: others may not have Friday off16:19
whikloj: in any case... be safe
<whikloj>awoods: right, have a good one.
ajs6f: add any comments to the atomic spec when you get a chance, unless its the weekend. In which case...don't16:20
* whikloj out
* whikloj leaves
<acoburn1>dbernstein: I'm now down to 21 integration test failures / 2 integration test failures16:23
2 integration test errors
dbernstein: I'll keep chipping away at this next week, but after I get the tests to pass, I'll need to clean up the mess of debugging code I've added throughout the codebase16:24
* mikeAtUVa joins16:30
* awoods bbl16:38
* ajs6f leaves16:56
* coblej leaves17:02
* github-ff joins17:03
[fcrepo-import-export] dbernstein opened pull request #44: Adds -h flag to display available options (master...fcrepo-2196) https://git.io/vXdXl
* github-ff leaves
* github-ff joins17:04
[fcrepo-import-export] dbernstein opened pull request #45: Removes -x (file extension) command line parameter. The extension is… (master...fcrepo-2200) https://git.io/vXdXB
* github-ff leaves
* acoburn1 leaves17:06
* dwilcox joins17:11
* dwilcox leaves17:20
* peichman leaves17:25
* jonathangee leaves18:16
* dwilcox joins18:17
* jonathangee joins
* dwilcox leaves18:25
<dbernstein>acoburn1: rock on.18:26
* apb18 leaves19:01
* apb18 joins19:11
* apb18 leaves19:19
* kefo leaves19:25
* dbernstein leaves20:37
* dbernstein joins20:40
* jonathangee leaves21:31
* jonathangee joins21:34
* dwilcox joins21:46
* dwilcox leaves22:11
* dwilcox joins22:33
* dbernstein leaves22:34
* dwilcox leaves22:41
* travis-ci joins22:47
fcrepo4/fcrepo4#4855 (master - 5173f6a : Elliot Metsger): The build was broken.
Change view : https://github.com/fcrepo4/fcrepo4/compare/e8e128cd04c1...5173f6aa5b18
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/177132317
* travis-ci leaves
* f4jenkins joins23:13