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

Using timezone: Eastern Standard Time
* dwilcox joins03:55
* dwilcox leaves03:58
* dwilcox joins04:02
* dwilcox leaves04:14
* dwilcox joins04:22
* dwilcox leaves04:35
* dwilcox joins04:36
* dwilcox leaves04:52
* dwilcox joins04:58
* dwilcox leaves05:07
* dwilcox joins05:15
* mohideen joins07:13
* mohideen leaves07:30
* mohideen joins07:31
* mohideen leaves07:48
* dwilcox leaves07:51
* awoods joins08:05
* github-ff joins08:08
[fcrepo4] awoods closed pull request #1225: Upgrade JQuery to 1.12.4 (4.7-maintenance...FCREPO-2578-maint) https://git.io/v5axh
* github-ff leaves
* travis-ci joins08:23
fcrepo4/fcrepo4#5216 (4.7-maintenance - bae9d36 : Aaron Birkland): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/a2eb41b87b91...bae9d36351b9
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/284175191
* travis-ci leaves
* benpennell joins08:45
* mohideen joins08:46
* dwilcox joins08:59
* apb18 joins09:11
* whikloj joins09:15
* bseeger joins09:18
* yamil_ joins09:19
* peichman joins09:21
* peichman leaves09:23
<whikloj>awoods/mohideen: Would it be crazy to modify the definition of an nt:file to include a second child?09:26
<awoods>good morning, whikloj
<whikloj>awoods: morning
* dhlamb joins09:27
<awoods>whikloj: We would want to dig into both the JCR spec and the Mode implementation to understand the possible consequences.
<whikloj>awoods: alternatively we could define our own version of the nt:file type with 2 children, the mandatory jcr:content and a possible fcr:versions09:29
* dwilcox leaves
<awoods>whikloj: could be worth a shot. One concern could be that Mode has implemented around an expectation of "requires a single child node called jcr:content"09:31
<mohideen>whikloj: I looked into the JCR spec yesterday. All it says is that nt:file requires a single jcr:content child. It does not seem to talk about having/nit having more child nodes: https://docs.adobe.com/docs/en/spec/jcr/1.0/
<awoods>whikloj: see https://docs.adobe.com/content/docs/en/spec/pdf/jcr-spec.pdf , section
<whikloj>awoods/mohideen: I'm gonna see if I can do that here09:33
<awoods>whikloj: it could be worth an experiment
whikloj/mohideen: Did you see lsitu's cut at this? https://jira.duraspace.org/browse/FCREPO-264409:48
<whikloj>awoods: yes, where he puts the LDPCv beside the Binary with the same name.09:49
<awoods>whikloj: something like that
* lsitu joins
* dwilcox joins09:50
* ylchen joins
<mohideen>whikloj: Yes, I had a question on that and posted it to the PR.
<whikloj>awoods: it means that Binary and Container act differently and I still worry about that possibility of orphan versions. But maybe I'm worrying too much
<awoods>whikloj: Go ahead with the "new nt:file" experiment09:53
<whikloj>awoods: Already am :)
* peichman joins09:58
<awoods>dhlamb/lsitu/mohideen/peichman/whikloj/ylchen: https://wiki.duraspace.org/display/FF/2017-10-06+Alignment+Sprint+02+Retrospective10:00
<dhlamb>awoods, be there in a minute
* dbernstein joins10:01
* rotated8 joins
<lsitu>awoods: I am there.
<awoods>dbernstein/rotated8: https://wiki.duraspace.org/display/FF/2017-10-06+Alignment+Sprint+02+Retrospective
* apb18 sittin' in on the sprint retrospective call10:04
<whikloj>who ever dropped solved the gurgle10:05
* apb18 is still here
awoods: I'll do it10:06
versioning is outstanding10:08
* dhlamb finally made it
i guess you can't hear me
hang on, i'll rejoin
<whikloj>dhlamb: nope
you are the wind beneath my wiiiiiiiiiiiiings10:29
<bseeger>whikloj: such a lovely voice!10:30
(i'm not on the call, just enjoying your irc singing)
<dhlamb>whikloj understating his presence, as always10:31
<whikloj>bseeger: thanks10:37
<awoods>whikloj: https://jira.duraspace.org/browse/FCREPO-264310:39
<whikloj>rotated8: bye10:41
<whikloj>eclipse haters10:52
I'm good enough, I'm smart enough and dog gone it people like me10:54
apb18++ # Good knowledge shared10:57
<lsitu>whikloj ++10:58
apd18 ++10:59
<dhlamb>i've got to run, but i'll continue working on 263211:02
<ylchen>I've got to run too. I will continue working on tickets from time to time. Nice to talk with you all.11:04
* ylchen leaves
<whikloj>awoods: https://jira.duraspace.org/browse/FCREPO-2589
<peichman>I need to drop off for now11:05
<whikloj>awoods: https://jira.duraspace.org/browse/FCREPO-2605
* peichman leaves11:06
<whikloj>project = FCREPO AND status in ("In Progress", Reopened) AND "Epic Link" = FCREPO-2582 ORDER BY assignee ASC, created DESC, updated ASC, priority DESC11:10
* benpennell leaves11:17
<whikloj>awoods: https://github.com/fcrepo4/fcrepo4/pull/1257/files#diff-38e44e1416448f2806cbed583ad24fb3R471
* bseeger leaves11:27
<whikloj>awoods: https://jira.duraspace.org/browse/FCREPO-2622 LDPCv respond to application/link-format header11:34
* benpennell joins11:46
* apb18 leaves11:57
<mohideen>whikloj/lsitu/dbernstein: I have appointments for the next couple of hours. I will be available on IRC after 1pm.12:03
* bseeger joins12:10
* apb18 joins12:31
* lsitu leaves12:51
* lsitu joins
* mohideen leaves13:00
* mohideen joins
* mohideen leaves
* mohideen joins13:01
* peichman joins13:37
* peichman leaves13:39
<whikloj>Ok so I made a nt:folder called TimeMap inside a File13:59
<whikloj>oh not so fast, I put up a binary, but I couldn't retrieve it with the HTML UI14:03
oh I screwed up making my binary in the first place. Which is good, cause that's why I couldn't retrieve it.14:08
So...it seems to work with existing tests and some simple messing around, I'll make a branch and you all can look at it.14:09
<dbernstein>whikloj: nice work.14:24
<whikloj>ok tombstones are a problem, but otherwise I think this could work
My tests
But we'd probably want to disallow anyone POSTing/PUTing stuff as a client, so we can handle the removal issues there.14:26
Here is how my changes compare to dbernstein's FCREPO-2624 PR.14:31
stepping away, brb14:32
<awoods>whikloj: that is a pretty small change. Nice.14:35
<whikloj>thanks, it was. I'm not even clear on whether I should have specified the fedora:TimeMap mixin there, as it is only a default (I think)14:44
* github-ff joins14:46
[fcrepo4] awoods closed pull request #1256: Enable Versioning on a new LDPR (memento-versioning...fcrepo-2624) https://git.io/vdR1S
* github-ff leaves
<awoods>whikloj: are you imagining the use of fcr:version for the actual timemap, or rather hiding the timemap node and channeling requests to fcr:versions to it?14:52
<whikloj>awoods: I think probably hiding the node and channeling requests. Otherwise, you can really stick anything you want inside the TimeMap child14:53
<awoods>whikloj: that sounds good.
<whikloj>awoods: I'm still not sure whether this could cause problems, I can't think of any off the top of my head14:55
<awoods>whikloj: are you referring to turning nt:file into something with a child?
<whikloj>awoods: yeah14:56
<awoods>whikloj: we will want to disallow this: https://gist.github.com/whikloj/a7a337001253a3d41a8bb8945dc25a62#file-gistfile1-txt-L10314:57
<whikloj>awoods: yes and this
<awoods>whikloj: yes14:58
whikloj: I guess we could intercept requests to /TimeMap...
whikloj: but our policy has been to limit reserved words to 'fcr:/*'14:59
<whikloj>awoods: we could change the "name" of those node to fcr:versions. We just need to pick a URL to map to fcr in the CND file
I'm testing using fcr:versions right now15:03
<awoods>I'm brushing up on CND options
* travis-ci joins
fcrepo4/fcrepo4#5219 (memento-versioning - 335b5f9 : dbernstein): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/e7028eb97051...335b5f9473b0
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/284342810
* travis-ci leaves
* github-ff joins15:14
[fcrepo4] awoods closed pull request #1243: Sets proper actor values for emitted messages. (master...fcrepo-2603) https://git.io/vdIcW
* github-ff leaves
<whikloj>If I define fcr: in the CND file a bunch of RDF tests explode with "Invalid fcr namespace properties...."
I think leaving the node name in the default namespace is better, but we could make it a more unique name if we like?15:16
<awoods>whikloj: ok... or name it "fedora:timemap"
whikloj: and still channel requests through /fcr:versions15:17
<whikloj>awoods: ok, testing15:18
awoods: ok, do I have to use the full URL for the node name? Cause I get the exact same error message15:22
awoods: oh wait, I left fcr defined in the CND file, probably need to remove that
* awoods fingers crossed15:23
* github-ff joins15:26
[ontology] awoods closed pull request #44: Added fcrepo:VersionedResource to ontology. (master...FCREPO-2640) https://git.io/vdRl8
* github-ff leaves
* mohideen leaves15:34
* mohideen joins15:35
<whikloj>ok fedora:timemap works15:37
<whikloj>Should I open a PR for this?15:38
<awoods>whikloj: yes please... attached to: https://jira.duraspace.org/browse/FCREPO-264415:39
* rotated8 leaves15:50
* dwilcox leaves15:52
<awoods>mohideen: are you interested in a webac bug? ...or are you on the way out the door?16:00
<mohideen>awoods: I am still working on https://jira.duraspace.org/browse/FCREPO-261716:01
* github-ff joins16:08
[fcrepo4] whikloj opened pull request #1258: Create new versionFile nodeType with nt:folder inside (memento-versioning...fcrepo-2644) https://git.io/vdEbV
* github-ff leaves
* travis-ci joins16:15
ualbertalib/fcrepo4-oaiprovider#118 (OAI_ORE_support_v2_1.0 - 70e9038 : Jeffery Antoniuk): The build passed.
Change view : https://github.com/ualbertalib/fcrepo4-oaiprovider/compare/OAI_ORE_support_v2_1.0
Build details : https://travis-ci.org/ualbertalib/fcrepo4-oaiprovider/builds/284380236
* travis-ci leaves
* travis-ci joins16:16
ualbertalib/fcrepo4-oaiprovider#119 (fcrepo4-oaiprovider-4.2.5 - 70e9038 : Jeffery Antoniuk): The build passed.
Change view : https://github.com/ualbertalib/fcrepo4-oaiprovider/compare/fcrepo4-oaiprovider-4.2.5
Build details : https://travis-ci.org/ualbertalib/fcrepo4-oaiprovider/builds/284380713
* travis-ci leaves
* dwilcox joins16:17
* github-ff joins16:23
[fcrepo4] awoods pushed 1 new commit to master: https://git.io/vdEA7
fcrepo4/master bb78ca2 Peter Eichman: Change groups from acl:agentClass to acl:agentGroup (#1245)...
* github-ff leaves
* rotated8 joins16:31
* github-ff joins16:33
[fcrepo4] dbernstein opened pull request #1259: Adds versioning response headers to LDPRv HEAD/GET responses w/o Acce… (memento-versioning...fcrepo-2612) https://git.io/vdExx
* github-ff leaves
<awoods>whikloj: what is your understanding of the meaning of "=fedora:TimeMap" in: https://github.com/fcrepo4/fcrepo4/pull/1258/files#diff-f793c1dd76ef43f9673963a55a86fd8cR4016:35
<whikloj>awoods: So that seems to be the default "type" assigned. I'm not sure if that was node type or mixin type. Also I'm not sure I used that correctly, so we can remove it if you'd like16:36
<awoods>whikloj: agreed, regarding 'default type'16:37
<whikloj>awoods: Default Primary Node Type - http://jackrabbit.apache.org/jcr/node-type-notation.html
<awoods>whikloj: here as well: https://docs.jboss.org/author/display/MODE50/Defining+custom+node+types#Definingcustomnodetypes-CNDexample
whikloj: Since no such type exists (fedora:TimeMap), I am surprised it does not puke.16:38
<whikloj>awoods: So I guess I'm not clear what the Required Primary Node Type is compared to the Default Primary Node Type16:39
<awoods>whikloj: I had the same question16:40
<whikloj>awoods: yeah the documentation around CND format is not great. Lots of lingo to describe other lingo
awoods: we can remove it, or mention it in the Tech call maybe someone out there has more understanding16:41
<awoods>whikloj: Removing it probably makes sense... I am testing now.
<whikloj>awoods: it definitely works, because I tested without it and then thought maybe it was good practice to define it.16:42
<awoods>whikloj: actually... fedora:TimeMap does exist as a type.16:43
* dwilcox leaves
<whikloj>awoods: or right its the mixin
<awoods>whikloj: we should create a ticket to intercept requests to /fedora:timemap16:44
<whikloj>awoods: I'll do that now
awoods: We are allowing DELETE of Mementos correct?16:47
individual Mementos I mean
<awoods>whikloj: yes16:48
whikloj: that should still likely come through /fcr:versions, no?
whikloj: and the links that we expose to users, for example in the TimeMap, should all have /fcr:versions/116:49
or whatever the memento name is
<whikloj>awoods: oh I get it, sorry I'm switching fcr:versions for fedora:timemap in my brain. Gotcha, what do we return for a request to fedora:timemap 403 Unauthorized?16:50
whikloj: let me see what we currently do...
<whikloj>405 Method Not Allowed is good too16:51
<awoods>400 Bad Request16:52
whikloj: we don't need to let them know that they actually hit a real resource16:53
<whikloj>awoods: The fedora namespace is restricted right, is there a ..."you can't use that name" type error
<awoods>whikloj: I just tested...16:54
whikloj: surprisingly, I can create a /fedora:Resource container
whikloj: we could probably restrict the entire namespace.16:55
<whikloj>awoods: might just be properties we restrict
<awoods>whikloj: yes, it appears that the fedora namespace prefix is only protected for properties.16:56
whikloj: it may be reasonable to restrict that namespace more generally
<whikloj>awoods: where/how do we restrict the properties?
<awoods>whikloj: lots of places...16:58
whikloj: mostly based on the usage of: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-api/src/main/java/org/fcrepo/kernel/api/RdfLexicon.java#L26816:59
* benpennell leaves
<whikloj>awoods: cool
awoods: So we can reuse that hasFedoraNamespace predicate17:00
awoods: So should this ticket not be intercept fedora:timemap, but rather be disallow interaction with fedora:* URIs?17:01
<awoods>whikloj: "disallow interaction with fedora:* URIs" should be good
<whikloj>awoods: response code?17:03
<awoods>whikloj: 400 Bad Request, or 409 Conflict
whikloj: maybe 409?
<whikloj>awoods: what is the conflict?17:04
<awoods>whikloj: that is what we use for both:17:05
<whikloj>how about 451 Unavailable For Legal Reasons
<whikloj>awoods: ok 409 it is.
<awoods>whikloj: I think 409 is consistent with our historic approach
<whikloj>awoods: https://jira.duraspace.org/browse/FCREPO-264517:06
* github-ff joins17:10
[fcrepo4] awoods closed pull request #1257: Create TimeMap LDPCv for binary resource. (memento-versioning...feature/ldpcv_binary) https://git.io/vd0TL
* github-ff leaves
<awoods>mohideen: you may need to coordinate with whikloj on design of: https://jira.duraspace.org/browse/FCREPO-261717:13
mohideen:... now that timemaps are available once travis passes
mohideen: are you working all of your user interactions through /fcr:versions endpoints?17:14
* apb18 leaves17:15
* github-ff joins17:16
[fcrepo4] awoods pushed 1 new commit to memento-versioning: https://git.io/vduJZ
fcrepo4/memento-versioning c235a06 Jared Whiklo: Create new versionFile nodeType with nt:folder inside (#1258)...
* github-ff leaves
<mohideen>awoods: ok, I will check with whikloj. I am just starting to look at the user interactions side. I have been working on the kernel implementation.17:18
<awoods>mohideen: great. I think the idea is that clients should not know the name of the timemap directly or the mementos.17:19
mohideen: requests to the timemap should be /some/path/fcr:versions17:20
mohideen: and requests to a memento should be /some/path/fcr:versions/<memento-name>
mohideen/whikloj: have we decided on a naming convention for mementos? datetime?17:21
<whikloj>awoods: we haven't do we need a special one? I'd just use the normal POST. Most people should get the location returned due to datetime negotiation.17:22
<awoods>whikloj: we should also prevent messages from being emitted about timemaps or mementos
<awoods>whikloj: normal POST should do the trick.
<whikloj>awoods: yeah, that's what I was thinking.17:23
<awoods>whikloj: we could actually hide the pairtree portion of the mementos... since we are filtering requests through /fcr:versions
something to think about17:24
<whikloj>awoods: ok, that'd be a "nice to have" but not required for API
* bseeger leaves17:25
* github-ff joins17:29
[fcrepo4] lsitu opened pull request #1260: Delete a LDPCv (TimeMap ). (memento-versioning...feature/delete_ldpcv) https://git.io/vduU8
* github-ff leaves
<mohideen>whikloj/awoods: I leaving from work now. I will continue my work later tonight from home.17:34
<awoods>mohideen: thank you!
* mohideen leaves17:35
<awoods>lsitu: I may be confused with: https://jira.duraspace.org/browse/FCREPO-262817:36
<whikloj>awoods: do I need to add another exception and exceptionhandler for fedora: namespaces in URIs?17:37
<awoods>lsitu: With your PR, FedoraEvent now has a getUserID() and a getUserURI()... but no getUserAgent()
<lsitu>awoods: Yes. That’s correct as suggested by Danny.17:38
<awoods>whikloj: would it make sense to reuse: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-http-commons/src/main/java/org/fcrepo/http/commons/exceptionhandlers/ServerManagedTypeExceptionMapper.java
dbernstein: are you around?
<lsitu>awoods: https://github.com/fcrepo4/fcrepo4/pull/1247#pullrequestreview-6622145617:40
<awoods>lsitu: I am also looking at escowles comment on 25/Sep/17: https://jira.duraspace.org/browse/FCREPO-2628
lsitu: It seems like there are two entities that we are trying track: the person and the software.17:41
lsitu: my understanding was that the userID (or userURI) was the person, and the userAgent was the software.17:42
lsitu: if we are only using userID and userURI, which is the person and which is the software?
<dbernstein>hi back.17:43
<lsitu>awoods: Both are person. One is the user name and another is the user URI.
<awoods>dbernstein: conversation starting at 17:36:31
<dbernstein>just review now.
* rotated8 leaves17:44
<dbernstein>Not sure if this is helpful but we want to use the user-agent (as in software) in the event info in the json-ld message. The confusion is the WebAC uses “userAgent” to mean “person” thus the term is overloaded. In order to make it clear in the fedora layer, we are changing the FedoraSession.userAgent and FedoraEvent.userAgent to userURI.17:48
<awoods>dbernstein: how are we tracking the software?17:49
dbernstein: in the FedoraSession and FedoraEvent?
<whikloj>So the reason we block fedora: in RDF and not paths is because we are actually blocking "http://fedora.info/definitions/v4/repository#", do we have the namespace prefix defined in the code?17:50
<dbernstein>I believe the User-Agent value is passed from the request to the FedoraEvent.info.17:51
Shall I give lsitu’s PR a review?
<lsitu>dbernstein: Sure thing.17:52
<awoods>dbernstein: that would be great17:53
dbernstein/lsitu: also noting that USER_AGENT_BASE_URI_PROPERTY is defined in two places:
<dbernstein>okay - I’ll look into that .
<awoods>WebACRolesProvider.java and FedoraSessionUserUtil.java
whikloj: yes, RdfLexicon:4117:54
<whikloj>awoods: right but in the path we want to match on "fedora:" correct?17:55
<lsitu>awoods: I can add another commit for sharing the variable in WebACRolesProvider.java.17:56
whikloj: The fcr:versions endpoint is engaging with getTimeMap() in FedoraTimeMap/FedoraTimeMapImpl now: https://github.com/fcrepo4/fcrepo4/pull/1260
<awoods>whikloj: FedoraTypes.java
lsitu: Do you think the constant is more logical in WebACRolesProvider or FedoraSessionUserUtil?17:57
<whikloj>awoods: ok so am I blocking any URI with "fedora:" in it, or any URI with a name that matches a FedoraTypes type?17:58
like is fedora:Sandwich allowed but fedora:Resource is not?
or fedora:* is a non-starter
<awoods>whikloj: I would say block fedora:*
<whikloj>awoods: ok, I'm heading out. Will no be back on tonight, but will spend some time tomorrow evening working through this.17:59
<lsitu>awoods: From bottom up. So I think it should be in FedoraSessionUserUtil or somewhere else in the Fedora Kernel API.
<awoods>lsitu: FedoraSessionUserUtil should work18:00
<lsitu>awoods ++
* whikloj leaves
* yamil_ leaves18:12
<lsitu>awoods: USER_AGENT_BASE_URI_PROPERTY is shared: https://github.com/fcrepo4/fcrepo4/pull/1247/commits/f7b9796ab90a97d471c9415792ad5e769e2dd0aa
<awoods>lsitu: thanks. I am going to make a quick bite. maybe until 6:35 ET18:14
<lsitu>awoods: Enjoy. :)18:15
* dhlamb leaves18:26
<dbernstein>lsitu - sorry for the confusing “approve” followed by “not approved” on https://github.com/fcrepo4/fcrepo4/pull/1247#pullrequestreview-67807029
<lsitu>dbernstein: That’s fine. I am correcting the test basing on your comments now.18:27
<dbernstein>okay - awesome.18:28
dbernstein/lsitu: where are we landing?18:30
dbernstein/lsitu: Are we tracking the software with one of the properties?
<lsitu>awoods: No. I am just correcting a test case that dbernstein found to be UserAgent.18:32
<awoods>lsitu: ok, that sounds like progress. I would be interested to hear dbernstein's thoughts on which property should be used for the person and which for the software.18:33
<lsitu>awoods: I am curious about it too. I can’t find any signatures for the software UserAgent.18:39
<awoods>lsitu: maybe when dbernstein returns, he will have thoughts.18:40
<dbernstein>My opinion: UserAgent should be the software, UserURI should be the userId as a URI and userId should be the username.18:41
<awoods>dbernstein: that makes sense to me.18:44
<dbernstein>So to recap: previously FedoraSession had the userAgent property. that is now UserURI. User-Agent is used as a property of event.info map [“USER-AGENT”]
the event.info key will stay the same.
we good?18:45
<awoods>dbernstein: do we actually need the userID?
<dbernstein>I’m not sure. I know there was some chatter about how it might be useful for clients to see the username of the caller.18:46
clients = consumers of the event messages.
<awoods>dbernstein: answering my own question: maybe not. userId appears to be only used in one place: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/FedoraSessionImpl.java#L14318:47
dbernstein/lsitu: FedoraSession.getUserID() does not appear to be needed. FedoraEvent.getUserID() is used.18:48
<dbernstein>ah - okay. Sure - let’s get rid of it.18:49
<lsitu>awoods/dbernstein:Do you want me to remove it now?18:50
<awoods>lsitu: sure, FedoraSession.getUserID() does not appear to be needed.
lsitu/dbernstein: I am trying to determine how FedoraEvent.getUserID() is used.18:51
* dwilcox joins18:53
<awoods>dbernstein: Are we required to include the username (not the user-URI) in event messages?
lsitu/dbernstein: It appears that we extract the userId from the JCR Event so that it can be used in messages that we produce.18:55
lsitu/dbernstein: I suppose we can keep userId for now... but it seems like it may be cruft.18:56
lsitu: In any case, please continue with your updates
<lsitu>awoods: Do you mean keep getUserID() in FedoraSessionas well?18:57
<awoods>lsitu: no, you can safely remove FedoraSession.getUserID()18:58
<dbernstein>awoods: I don’t think we’re required to give the username in event messages - but let me verify with ActivityStreams…19:02
<awoods>dbernstein: it looks like we have the option to either use the username or uri19:03
<dbernstein>I say let’s roll with what we have and add a new JIRA to remove FedoraEvent.getUserId().19:04
I need to jump. the effort today was inspiring.19:05
* dwilcox leaves
<dbernstein>have a great weekend folks!
<awoods>thanks: dbernstein... sounds like a plan19:09
<lsitu>awoods/dbernstein: It’s already done in https://github.com/fcrepo4/fcrepo4/pull/1247/commits/0cd1ecd29677a98e87dcf6172060f7f9805e4973
<awoods>lsitu: I will give it a review in just a moment. Thanks!19:10
* github-ff joins19:27
[fcrepo4] awoods closed pull request #1247: Rename signature UserAgent to UserURI in FedoraSession and FedoraEvent. (master...feature/useruri) https://git.io/vd33y
* github-ff leaves
* travis-ci joins19:43
fcrepo4/fcrepo4#5233 (master - 6034a73 : lsitu): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/bb78ca255215...6034a73c0b3a
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/284455660
* travis-ci leaves
* dbernstein leaves20:01
* apb18 joins20:46
* apb18 leaves
* mohideen joins21:28
* mohideen leaves21:33
* benpennell joins22:05
* mohideen joins22:15
* lsitu leaves22:26
* mohideen leaves22:42
* benpennell leaves22:55
* benpennell joins22:56
* whikloj joins23:20
* whikloj leaves23:27
* benpennell leaves23:43

Generated by Sualtam