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

Using timezone: Eastern Standard Time
* manez joins04:19
* manez leaves04:24
* manez joins05:20
* manez leaves05:24
* manez joins06:20
* manez leaves06:25
* manez joins07:21
* manez leaves07:25
* manez joins08:00
* manez leaves08:04
* manez joins08:17
* coblej joins08:29
* whikloj joins08:52
* yamil joins09:19
* peichman joins09:29
* coblej leaves10:14
* coblej joins10:34
* bseeger1 joins11:28
* bseeger1 leaves11:30
* bseeger joins11:31
* coblej leaves11:47
* coblej joins12:06
* coblej leaves12:18
* dwilcox leaves12:22
* bseeger leaves12:23
* bseeger joins12:29
* coblej joins12:54
* manez leaves13:17
* github-ff joins13:24
[fcrepo-specification] awoods pushed 1 new commit to master: https://git.io/vQKtL
fcrepo-specification/master a8c30f6 Adam Wead: Correcting minor grammar and spelling errors (#150)
* github-ff leaves
* dbernstein joins13:29
<awoods>hi dbernstein13:30
<dbernstein>awoods: wassup!
<awoods>dbernstein: I had questions about both 4.7.4 and fcrepo-java-client
<awoods>dbernstein: first, where did the fcrepo-java-client release land?
<dbernstein>I believe I finished that. let me double check. The problem I was running into was due to the fact that I had removed a github key from my account.13:31
<awoods>dbernstein: ah yes... it looks good: https://github.com/fcrepo4-exts/fcrepo-java-client/releases/tag/fcrepo-java-client-0.3.013:32
<dbernstein>looks like it has not been merged into master yet.13:33
oh wait.13:34
<awoods>dbernstein: yes, you need to merge the 0.3.0-RC branch into master, then delete that branch13:35
dbernstein: once you do that, would you be interested in sending a notice to the community along the lines of:13:36
<dbernstein>yes - I will do both.
<awoods>dbernstein: great13:37
<dbernstein>question awoods: should I merge the branch via a pull request?
<awoods>dbernstein: sure
dbernstein: I'm ready for it
* github-ff joins13:40
[fcrepo-java-client] dbernstein opened pull request #31: merges 0.3.0-RC into master (master...0.3.0-RC) https://git.io/vQKqh
* github-ff leaves
<awoods>dbernstein: I'll just wait for travis
dbernstein: as for 4.7.4...13:41
<dbernstein>test page coming shortly.
<awoods>dbernstein: I am looking for a 4.7.4-RC branch...
dbernstein: did you cherry-pick the master PRs directly onto the 4.7-maintenance branch?13:42
<dbernstein>right - this was a point of confusion. This is what I did initially.
<awoods>dbernstein: did you subsequently do something different?
<dbernstein>No initially I created a 4.7.4-RC and cherry picked from master onto that branch.13:43
<awoods>dbernstein++ sounds right
dbernstein: then what?
dbernstein: assuming the 4.7.4-RC was branched from 4.7-maintenance
<dbernstein>But there was some issue which I can’t recall at the moment. I brought it up on the tech call (week before last) and whikloj suggested that I push the changes on 4.7.4-RC directly onto 4.7-maintenance. Then we’ll create the RC from there.13:45
Let me see if there is anything in the notes...
* dwilcox joins13:46
<dbernstein>awoods: the notes are not helpful unfortunately.
whikloj: can you remember what the issue was with 4.7.4-RC?13:47
<whikloj>awoods/dbernstein: In the tech call bseeger was wondering why we had done that (cherry-pick directly onto an RC branch) which would then need to be merged in to maintenance, instead of the other way around.
awoods/dbernstein: It made sense to me as well that we are altering the maintenance branch then generate a release candidate from there, instead of the reverse.13:48
awoods/dbernstein: But it really could be tomato tomahto
<dbernstein>whikloj: right - that was it. I didn’t have a good rebuttal so I went with it, being the freshman committer.13:49
<whikloj>awoods/dbernstein: yeah and it was really a trivial difference as there was no difference between 4.7.4-RC and 4.7-maintenance except those changes.13:50
<dbernstein>awoods: what was the rational for cherry picking to 4.7.4-RC first rather than 4.7-maintainenance?
<bseeger>bseeger: yeah, I remember wondering why the RC came before putting it on maintenance.
<awoods>whikloj: got it. thanks.
<bseeger>heh, I'm talking to myself. ;)
<whikloj>bseeger: whikloj also wondered that13:51
<awoods>dbernstein: so it looks like the commits where cherry-picked on the 4.7-maintenance
dbernstein: so it looks like the commits were cherry-picked on the 4.7-maintenance
dbernstein: and then the process stopped?
dbernstein: I am not seeing a 4.7.4-RC branch
<dbernstein>that’s right. I removed the 4.7.4-RC branch in case more commits came in that we wanted to include in the release.13:52
In that case I would have cherrypicked them to the 4.7-maintenance and then when we’re truly ready to begin I would create the 4.7.4-RC branch.13:53
<awoods>bseeger/whikloj: The only reason I was thinking that the commits would be cherry-picked onto an RC branch first, is because there may be some gray area around whether a commit is indeed backwards-compatible
bseeger/whikloj: it is easier to roll out of an RC branch... once commits are on 4.7-maintenance, they are officially "in"13:54
dbernstein: that makes sense
<dbernstein>awoods: oh ok. so in this case the release process protocol changed slightly.
<awoods>dbernstein: yes13:55
<bseeger>awoods; were you thinking we'd testing the RC and then merge back to maintenance?
<whikloj>awoods/bseeger/dbernstein: So I think that reveals an issue with the process of determining backwards compatible commits. Otherwise, we are conceivably using 4.7.4-RC as a testing ground to see if it breaks stuff, instead of knowing ahead of that process
<awoods>bseeger: yes13:56
whikloj: not exactly
<whikloj>awoods: perhaps I need you to define "gray area" then :)
<awoods>whikloj: I was not going to "test" each commit, but rather review the associated JIRAs and commits... they may not have all be properly flagged as "breaking-change"13:57
* peichman leaves
<awoods>whikloj: basically, I asked dbernstein to cherry-pick the non-breaking-changes from master, based on the associated JIRA tickets being flagged13:58
whikloj: the gray area is where unflagged breaking changes lurk
whikloj: I expect there are non
whikloj: I expect there are none
<bseeger>awoods: perhaps it's the name of the branch that threw me - it doesn't sound like it would have been the actual RC. Sounds like we would have tested that RC branch, merged to 4.7 maintenance and then cut and RC?13:59
* peichman joins
<whikloj>awoods: right but then if something goes wrong we still have to dig through all the cherry-picked commits. So my point is perhaps the cherry-picking process needs to be more intensive to ensure the JIRA ticket is correct
<awoods>whikloj: That sounds reasonable.
whikloj: Do you have thoughts on "more intensive" cherry-picking?14:00
* awoods noting that we may be in a similar situation in the future14:01
<whikloj>awoods: Perhaps if we are going to do these "feature" releases on older versions then we should broadcast the need for pre-release testers...or we can go with your initial plan but we should be clear to people that we are unclear about the "non-breaking"-ness of the upgrade14:02
^^ during the testing phase I mean
<awoods>whikloj: We have been unclear on breaking-changes many times... as evidenced in several recent releases.14:03
<whikloj>awoods: hahaha
<awoods>whikloj/bseeger/dbernstein: At this point, we need a 4.7.4-RC... and can go from there.14:04
whikloj/bseeger/dbernstein: I suspect all is well14:05
whikloj/bseeger/dbernstein: ...and backwards-compatible
<whikloj>awoods: alright so your concern is keeping 4.7-maintenance clean, but still pulling commits backwards that might not end up there. I am fine with using your original plan, we just need to ensure that the process accounts for merging RC back into maintenance.
<awoods>whikloj: merging RC back into maintenance ++ for sure14:06
<bseeger>awoods, whikloj: So in the original plan we would have tested the RC branch and release that and then merged back? or tested the RC, merged back, tested again and then released?
awoods, whikloj: just trying to follow…14:07
<whikloj>bseeger/awoods: I think if we tested RC and RC was created from maintenance then merging it back would be exactly the same as re-testing RC
<awoods>bseeger: test the RC, release from there, merge it into 4.7-maintenance
<awoods>whikloj: as discussed on a tech call a month or so ago, we can choose to cherry-pick at release time, or merge into maintenance branches as we go.
<dbernstein>awoods, whikloj, bseeger: in any case I will create a new RC branch.
<bseeger>whikloj: right — of course (face-palm!)
dbernstein — sorry for the run around!14:09
* github-ff joins14:10
[fcrepo4] dbernstein created 4.7.4-RC from 4.7-maintenance (+0 new commits): https://git.io/vQJXp
* github-ff leaves
<awoods>dbernstein/bseeger/whikloj: I think the point is that there are many ways of doing this... all potentially correct.
dbernstein/bseeger/whikloj: I was just looking for an RC branch ;)14:11
<bseeger>dbernstein is most efficient in creating them. :)
<awoods>bseeger: I see that
<dbernstein>bseeger, whikloj: no apologies necessary. It is clear as daylight that you had the best interests of the code in mind.
<awoods>bseeger/whikloj: that means, "very clear"14:12
<whikloj>awoods: agreed, I'd still like to figure out a better way of having people assess the breaking-ness of their changes. I probably have no idea if what I am doing could crush a repo
<awoods>whikloj: agreed... that is its own topic, outside of the release process14:13
<whikloj>awoods: agreed
<awoods>whikloj: At a minimum, it would be good to have a dataset created from the previous release that could be used with the current code14:14
<whikloj>awoods: yeah, do we have a way to cut a subset of a repo out? Then perhaps we could have people volunteer some data
<awoods>whikloj: what do you mean by, "cut a subset of the repo out"?14:15
<dbernstein>whikloj,awoods,bseeger: fwiw, I looked at each commit and asked myself “is breaking change?” whether they were labeled as such or not.
<dbernstein>dbernstein: dbernstein++
<whikloj>awoods: We need a way to get a portion of a potentially large repo, some way to slice a piece from the pie but still get the context of the data.14:16
dbernstein: dbernstein++ dbernstein++
awoods: I don't know how, and I know that won't account for external systems, but it might help with pure data related issues.14:17
<awoods>whikloj: like using the import/export tool to export a hierarchy of resources? or a set of resource connected by a specific predicate?
<dbernstein>awoods,whikloj: What about the sample datasets we use for import/export?
<whikloj>awoods: Oooo yeah, can it do that. I can't remember the options
* github-ff joins14:18
[fcrepo-java-client] awoods pushed 2 new commits to master: https://git.io/vQKZw
fcrepo-java-client/master 50a4436 Daniel Bernstein: [maven-release-plugin] prepare release fcrepo-java-client-0.3.0
fcrepo-java-client/master 6bb47f5 Daniel Bernstein: [maven-release-plugin] prepare for next development iteration
* github-ff leaves
<whikloj>dbernstein: Those are good, but our users all do different things with their data so it might be good to get more examples like those
<awoods>whikloj: indeed
whikloj: there are two ways of pulling in a set of related resources
whikloj: --inbound or --predicate14:19
whikloj: --inbound exports the resource and all resources that reference the target resource
<dbernstein>whikloj: I see. So sounds like you’re talking about adding a new sample dataset to rule them all.
<awoods>whikloj: --predicate allows the user to provide one or more predicates to following in addition to or instead of ldp:contains14:20
whikloj: --predicate allows the user to provide one or more predicates to follow in addition to or instead of ldp:contains
<whikloj>awoods: so maybe we just need to focus on getting that upcoming release of import/export out to help people export a set from their current repo and test import it into a release candidate14:21
* travis-ci joins
fcrepo4-exts/fcrepo-java-client#115 (master - 6bb47f5 : Daniel Bernstein): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-java-client/compare/bf9346c3663d...6bb47f518bb3
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-java-client/builds/251259952
* travis-ci leaves
<whikloj>dbernstein: no one to rule them all, just more alternatives
<awoods>dbernstein: I'm going in...14:23
<dbernstein>whikloj: on that note if each dataset exemplified a particular use case what do you think about creating a script that would simply import/export a set of datasets for the purposes of vetting an RC?14:25
Or I suppose we could ensure that the rc is tested with each dataset separately.
awoods: you’re all clear kid.14:26
* travis-ci joins
fcrepo4/fcrepo4#5056 (4.7.4-RC - 0063969 : B. Seeger): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/4.7.4-RC
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/251256312
* travis-ci leaves
<whikloj>dbernstein: yeah see the problem really is that no matter how much you test, it depends on what people are doing outside Fedora too. My thought was just we could have some more test datasets.
dbernstein: But now I think that getting the import/export tool working and show people how to use it test easily test a portion of their existing repo will lower the bar to testing and hopefully reveal any issues by getting more people to do it14:27
<awoods>whikloj: Exactly. We can offer recipes for community members to use on their own for local testing.
whikloj: Import/Export recipes14:28
<whikloj>awoods: right and then they can test supporting machinery as well, not that that is our problem but its a nice to have to encourage testing14:29
<awoods>whikloj: let's make it so14:30
<dbernstein>awoods et all: https://wiki.duraspace.org/display/FF/Release+Testing+4.7.414:46
Do we want to highlight the new tickets in the release for individual testing?14:47
<awoods>dbernstein: If you have a set of tickets in mind, that could be a nice addition. At a minimum, including such tickets in the announcement would be helpful:14:51
https://wiki.duraspace.org/display/FF/Policy+-+Release+Candidates (see: Initial Release Candidate Template)14:52
<dbernstein>awoods: okay. btw what is the planned release date for 4.7.4?14:54
<awoods>dbernstein: optimistically, 3 weeks after we announce the RC... which should be this coming Monday or Tuesday14:55
<dbernstein>okay good to know.14:56
<awoods>whikloj: after some reflection, the import/export tool won't necessarily help with identifying issues of backwards-compatibility related to dropping a new war into deployment over existing data.15:01
<whikloj>awoods: true
* peichman leaves15:07
* manez joins15:10
<dbernstein>awoods: so I notice that 4.7-maintenance does not contain the 3 reversions that comprised 4.7.3. Why?15:14
Shoudln’t 4.7-maintenance be headed by the latest 4.7 release, ie 4.7.3?15:15
* mcritchlow joins15:16
* coblej leaves
* peichman joins15:22
* coblej joins15:33
<awoods>dbernstein: yes, 4.7.3-RC have been merged back into 4.7-maintenance15:34
dbernstein: yes, 4.7.3-RC should have been merged back into 4.7-maintenance15:35
<dbernstein>awoods: so to fix this problem what do you say we do the following: 1) remove all commits after 4.7.2 from maintainence. 2) merge in 4.7.3 into 4.7-maintaince. 3) rebase 4.7.4-RC from 4.7-maintenance.15:40
<awoods>dbernstein: actually, it looks like we need ruebot's local 4.7.3 commits15:43
dbernstein: I am not seeing a commit that bumps the pom.xml version to 4.7.4-SNAPSHOT... which would have been the next development version15:44
dbernstein: although, we could forgo tracking down that commit.15:45
dbernstein: what do you mean by "remove all commits after 4.7.2 from maintenance"?15:46
dbernstein: the 4.7-maintenance branch is effectively like a "master" branch and should not be force-pushed upon.15:47
dbernstein: I may see the problem15:49
dbernstein: The following branch was mistakenly created: https://github.com/fcrepo4/fcrepo4/commits/4.7.3-maintenance
* dbernstein_ joins15:52
<awoods>dbernstein and dbernstein_ : did you see my above comments?15:55
* dbernstein_ leaves15:59
<dbernstein>awoods: yes - I’m here. Just stepped away. Read your comments.
<awoods>dbernstein: Unfortunately, under the circumstances, I think we should move (rename) 4.7.3-maintenance to 4.7-maintenance, then create the 4.7.4-RC from there, cherry-pick onto the RC.16:00
dbernstein: scratch that suggestion.16:02
<dbernstein>awoods - why scratch that?
because it is basically the same as doing a force-push16:03
<awoods>dbernstein: the force-push fact is the reason for "Unfortunately"16:04
dbernstein: I am looking at the commits between 4.7-m and 4.7.3-m
dbernstein: no, it should be ok16:07
<dbernstein>so don’t scratch that?
<awoods>dbernstein: right16:08
<dbernstein>okay - so rename 4.7.3-maintenance to 4.7-maintenance?
<awoods>dbernstein: before doing so, we should ensure that you have a local branch with the cherry-picks... so they can be rebased on the new 4.7-m16:09
<dbernstein>awoods: good point. yes I do.16:10
<awoods>dbernstein: me too. Are you good to go? or should we have a chat?16:11
<dbernstein>it might be useful to talk it through to head off the possibility of my royally botching it. :)16:12
* github-ff joins16:32
[fcrepo4] awoods force-pushed 4.7-maintenance from 0063969 to 23d983c: https://git.io/vQKwx
* github-ff leaves
* manez leaves16:36
* nateg joins16:39
* nateg leaves16:42
* travis-ci joins16:46
fcrepo4/fcrepo4#5057 (4.7-maintenance - 23d983c : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/0063969d8bc0...23d983cb0453
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/251300276
* travis-ci leaves
* github-ff joins16:52
[fcrepo4] awoods force-pushed 4.7-maintenance from 23d983c to 1f83a4a: https://git.io/vQKwx
* github-ff leaves
* dwilcox leaves16:58
* coblej leaves17:02
* github-ff joins17:03
[fcrepo4] dbernstein opened pull request #1207: 4.7 maintenance repair (4.7-maintenance...4.7-maintenance-repair) https://git.io/vQKif
* github-ff leaves
* whikloj leaves17:04
* travis-ci joins17:06
fcrepo4/fcrepo4#5058 (4.7-maintenance - 1f83a4a : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/23d983cb0453...1f83a4a2dec6
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/251306071
* travis-ci leaves
* github-ff joins17:18
[fcrepo4] awoods pushed 5 new commits to 4.7-maintenance: https://git.io/vQKXt
fcrepo4/4.7-maintenance 0002362 Andrew Woods: Revert "Use a new prefix definition for info:fedoraconfig/"...
fcrepo4/4.7-maintenance eb0ca36 Andrew Woods: Revert "Add namespaces to the default CND configuration (#1109)"...
fcrepo4/4.7-maintenance d70c35b Andrew Woods: Revert "Remove test: namespace from the modeshape config; make fedoraconfig: non-resolvable (#1106)"...
* github-ff leaves
* peichman leaves17:24
* bseeger leaves
* travis-ci joins17:32
fcrepo4/fcrepo4#5060 (4.7-maintenance - 492e661 : nruest): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/1f83a4a2dec6...492e6619f28e
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/251315122
* travis-ci leaves
* github-ff joins17:35
[fcrepo4] dbernstein force-pushed 4.7.4-RC from 0063969 to 8d7cf59: https://git.io/vQJXp
fcrepo4/4.7.4-RC b4651d3 Esmé Cowles: Skolemizing blank nodes with hash URIs (#1187)...
fcrepo4/4.7.4-RC 29a0046 Daniel Bernstein: Adds configuration to toggle Hash-URI <-> /.well-known/genid...
fcrepo4/4.7.4-RC 4d3a757 dbernstein: Ensures that the object URIs within a SPARQL update are validated bef… (#1154)...
* github-ff leaves
* manez joins17:36
* manez leaves17:41
* mcritchlow leaves17:53
* mcritchlow joins17:56
* yamil leaves18:20
* charles-sdsc joins18:35
hello! Did I find the IRC for Fedora developers?18:36
<dbernstein>yes you did charles-sdsc18:37
* manez joins18:38
<charles-sdsc>thanks! I'm not sure if this is the appropriate place to ask a couple of related to the repo. Mind if I shoot them out?
* manez leaves18:42
<dbernstein>please do charles-sdsc18:45
this is *the* place where it all goes down.18:46
<charles-sdsc>I"m trying to deploy fedora commons on https://www.workbench.nationaldataservice.org/ as I'm work for NDS.18:54
And css, jquery libraries don't load correctly, because the urls being loaded are not secure.18:55
I think the solution is to make those links relative. For example...
should be...
* github-ff joins
[fcrepo4] dbernstein pushed 1 new commit to 4.7.4-RC: https://git.io/vQKdM
fcrepo4/4.7.4-RC 77da0e7 dbernstein: Adds PreconditionException type to replace WebapplicationException. (#1206)...
* github-ff leaves
<charles-sdsc> https://sgkbc7-fedoracommons.workbench.nationaldataservice.org/fcrepo/rest/fcr:assets/common.css
<dbernstein>which version of fedora are you using ? just curious18:59
<charles-sdsc>I cloned, and applied my fix and wanted to test it by creating my own .war file. And that's where I'm running into trouble.
<dbernstein>okay good.
So i'm curious what version of maven, java, and linux you use to create the .war file19:00
<dbernstein>personally I’m on java 1.8.0_111, maven 3.3.919:01
osx 10.10.5
<awoods>charles-sdsc: what is the nature of the trouble you are running into when trying to build the war?19:03
<charles-sdsc>The build seems to fail on the 'Deployable Web Applicaton' test, according to the Reactor Summary19:05
'Failed to execute goal org.apache.maven.plugins:maven-failsafe-plugin:2.18.1:verify'
<awoods>charles-sdsc: feel free to dump the output to a gist, and post a link to the gist here.19:06
* mcritchlow leaves19:11
* travis-ci joins19:13
fcrepo4/fcrepo4#5062 (4.7.4-RC - 77da0e7 : dbernstein): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/8d7cf5946e4b...77da0e7c1bd5
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/251342404
* travis-ci leaves
I realize this is 5oclock on a Friday, and can get back to you on Monday if this is inconvenient19:23
<awoods>charles-sdsc: you can perform a build without tests: 'mvn clean install -DskipTests', however, the failures likely indicate that your update causes '406 Not Acceptable' requests19:29
charles-sdsc: have you tried building the codebase without any local updates?
charles-sdsc: p.s. I will have this window closed. Please reference my handle to emit a notification.19:31
* manez joins19:39
* manez leaves19:43
* dbernstein leaves20:01
<charles-sdsc>i assume running DSkipTests and seeing Reactor reporting success on 'tests' doesn't indicate that the tests actually passed20:05
i'lll look into deploying it on monday. thanks for the tip.20:09
<awoods>charles-sdsc: success with "skipTests" means that it builds... but without running any tests.20:16
* github-ff joins20:19
[fcrepo4] awoods tagged fcrepo-4.7.4-RC-1 at eaf9d23: https://git.io/vQKpH
* github-ff leaves
* github-ff joins20:22
[fcrepo-module-auth-webac] awoods created 4.7.4-RC from 4.7-maintenance (+0 new commits): https://git.io/vQKph
* github-ff leaves
* github-ff joins20:23
[fcrepo-module-auth-webac] awoods tagged fcrepo-module-auth-webac-4.7.4-RC-1 at 106aa13: https://git.io/vQKpj
* github-ff leaves
* travis-ci joins20:24
fcrepo4/fcrepo-module-auth-webac#210 (4.7.4-RC - 1e05740 : nruest): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-webac/compare/4.7.4-RC
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-webac/builds/25136026320:25
* travis-ci leaves
* github-ff joins
[fcrepo-mint] awoods created 4.7.4-RC from 4.7-maintenance (+0 new commits): https://git.io/vQKhT
* github-ff leaves
* github-ff joins
[fcrepo-mint] awoods tagged fcrepo-mint-4.7.4-RC-1 at ec6e11d: https://git.io/vQKht
* github-ff leaves
* travis-ci joins
fcrepo4/fcrepo-module-auth-webac#211 (fcrepo-module-auth-webac-4.7.4-RC-1 - 1e05740 : nruest): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-webac/compare/fcrepo-module-auth-webac-4.7.4-RC-1
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-webac/builds/251360340
* travis-ci leaves
* travis-ci joins20:27
fcrepo4-exts/fcrepo-mint#71 (4.7.4-RC - 41bacc0 : nruest): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-mint/compare/4.7.4-RC
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-mint/builds/251360610
* travis-ci leaves
* github-ff joins20:28
[fcrepo-audit] awoods created 4.7.4-RC from 4.7-maintenance (+0 new commits): https://git.io/vQKhl
* github-ff leaves
* github-ff joins
[fcrepo-audit] awoods tagged fcrepo-audit-4.7.4-RC-1 at 6305ca2: https://git.io/vQKh8
* github-ff leaves
* travis-ci joins20:29
fcrepo4-exts/fcrepo-audit#167 (fcrepo-audit-4.7.4-RC-1 - e18a1ee : nruest): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-audit/compare/fcrepo-audit-4.7.4-RC-1
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-audit/builds/251361082
* travis-ci leaves
* github-ff joins20:32
[fcrepo-webapp-plus] awoods created 4.7.4-RC from 4.7-maintenance (+0 new commits): https://git.io/vQKho
* github-ff leaves
* github-ff joins
[fcrepo-webapp-plus] awoods tagged fcrepo-webapp-plus-4.7.4-RC-1 at 17598aa: https://git.io/vQKhi
* github-ff leaves
* travis-ci joins20:35
fcrepo4-exts/fcrepo-webapp-plus#220 (fcrepo-webapp-plus-4.7.4-RC-1 - 089ef48 : nruest): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-webapp-plus/compare/fcrepo-webapp-plus-4.7.4-RC-1
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-webapp-plus/builds/251361707
* travis-ci leaves
* travis-ci joins20:36
fcrepo4-exts/fcrepo-webapp-plus#221 (4.7.4-RC - 089ef48 : nruest): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-webapp-plus/compare/4.7.4-RC
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-webapp-plus/builds/251361738
* travis-ci leaves
* manez joins20:39
* manez leaves20:44
* manez joins21:40
* manez leaves21:45
* manez joins22:41
* manez leaves22:45
* manez joins23:42
* manez leaves23:46
* mcritchlow joins23:51
* mcritchlow leaves23:53
* manez joins00:42
* manez leaves00:47
* manez joins01:43
* manez leaves01:48
* manez joins02:44
* manez leaves02:49
* manez joins03:45
* manez leaves03:49