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

Using timezone: Eastern Standard Time
* ksclarke leaves01:47
* nbanks joins01:57
* nbanks leaves02:13
* nbanks joins02:41
* kaarefc joins02:42
* kaarefc leaves03:04
* nbanks leaves03:05
* nbanks joins03:53
* nbanks leaves03:58
* nbanks joins04:10
* nbanks leaves06:39
* nbanks joins06:42
Any one around?06:56
* eddies leaves07:33
* eddies joins07:44
* eddies leaves
* eddies joins
* eddies leaves07:54
<pivotal-bot___>Esme Cowles added comment: "I think the full discussion of what the namespace URIs should be, which is also related to where they are pu..." https://www.pivotaltracker.com/story/show/5089596908:00
Esme Cowles finished "Use good predicates and document them in futures/ontology" https://www.pivotaltracker.com/story/show/50895969
* jay joins08:17
* ajs6f joins08:44
<awoods>nbanks: here09:16
<pivotal-bot___>Yuqing Jiang added comment: "can get object and see the label(defualt label) and owner.09:17
* github-ff joins09:28
[fcrepo-kitchen-sink] awoods pushed 1 new commit to master: http://git.io/5rIN5Q
fcrepo-kitchen-sink/master 3d10cfa Andrew Woods: Reinstate integration tests
* github-ff leaves
<pivotal-bot___>https://github.com/yqjiang/islandora/tree/7.x-f..." https://www.pivotaltracker.com/story/show/5503855409:29
Andrew Woods started "Re-enable ITs on fcrepo-kitchen-sink" https://www.pivotaltracker.com/story/show/54967722
Andrew Woods finished "Re-enable ITs on fcrepo-kitchen-sink" https://www.pivotaltracker.com/story/show/54967722
Andrew Woods added comment: "Resolved with http://git.io/5rIN5Q" https://www.pivotaltracker.com/story/show/54967722
Andrew Woods accepted "Re-enable ITs on fcrepo-kitchen-sink" https://www.pivotaltracker.com/story/show/54967722
* kaarefc joins09:32
<nbanks>awoods: Hi09:33
<awoods>hello, nbanks.
* gregjansen joins
<nbanks>awoods: Do you know if there is an upload size limit for fedora4?
<awoods>I do not know of such a limit. I would imagine that the HTTP upload is probably limited by the bandwidth tcp connection reliability.09:34
<bljenkins>Project fcrepo-kitchen-sink build #497: SUCCESS in 6 min 31 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-kitchen-sink/497/09:35
<awoods>nbanks, what do you have in mind?
<nbanks>awoods: I just ask cause I wanted to attempt adding a 2 GB file from the web interface to see the amount of time it would take, seems to fail right away though as 'cancelled'. Oddly enought the web interface uses a GET request rather than post. I'll probably have better luck with curl.09:37
<awoods>If indeed the web ui uses GET, that is a bug.
<nbanks>awoods: I've done some profiling and it seems that the modeshape filesystem federation plugin is to blame, it generates a hash from each file it finds on the file system and uses that hash to generate an unique id for the node.09:38
<awoods>nbanks: You are saying that "instance ingest" of large content by means of a FileSystemConnector is currently not practical?09:40
"instant ingest"
<nbanks>Doesn't seem to be, looks like we'll have to handle that on our own09:41
<awoods>nbanks: That hurts. We have been banking on that strategy.09:42
nbanks: Maybe some investigation into what tweaks we can make to the FileSystemConnector is in order.
nbanks: Sounds like two tickets:09:43
- web ui GET on upload
<nbanks>Ingesting an object of equivent size is almost instantaneous via the rest api, I think we could probably lift most of the FileSystemConnector code and change the algorithm for ID generation.
<awoods>- FileSystemConnector tweaking09:44
<nbanks>yup
<awoods>nbanks: you on it?
<nbanks>Sure
<awoods>nbanks, ticket generation, that is.
<nbanks>yup
<awoods>thanks, nbanks.09:45
* ajs6f leaves
<pivotal-bot___>Nigel Banks added "Change web interface to upload Data-streams via POST instead of GET" https://www.pivotaltracker.com/story/show/5522724009:47
* ajs6f joins09:48
<nbanks>awoods: Sorry to keep bugging ya, but I wanted to go back to what I was trying to sort yesturday with deploying jar files. I'll explain my set up a little more. I have one folder that is a fcrepo4 repository and another folder that contains my customized filesystem connection. Compiling the filesystem connector seems to work fine. After compiling it I copied the jar into fcrepo4/fcrepo-webapp/target/fcrepo-webapp-4.0.0-alpha-2-SNAPSHOT/WEB-INF/lib/ think09:51
<awoods>nbanks: There are a couple of ways that could work...09:53
nbanks: to use the filesystemconnector, you will need to modify your repository.json09:54
nbanks: Then, with your new jar in the WEB-INF/lib dir (assuming all of the filesystemconnecter dependency jars are also in the lib dir) you could cycle your application server... and see what happens.09:55
<pivotal-bot___>Nigel Banks added comment: "I profiled it with a few files (one over 2GB) and I found that most of the time was spent in this function S..." https://www.pivotaltracker.com/story/show/5500391009:59
Nigel Banks added comment: "Here is the snapshot https://www.dropbox.com/s/y20k92y8sx0bfmz/Launcher-2013-08-15-1.snapshot" https://www.pivotaltracker.com/story/show/55003910
<nbanks>awoods: That's what I did, I changed the class that repository.json refered to, to be the one created in my connector. I'll do it again and copy the error message here.10:00
<awoods>nbanks: What is the Launcher-snapshot in https://www.pivotaltracker.com/s/projects/684825/stories/55003910 ?10:01
<nbanks>It's a link to my dropbox where I uploaded the cpu profile snapshot from yourkit.10:02
<awoods>nbanks: ok, although for anyone to actually look at the results we may just want a screen shot or two on the wiki.10:04
<nbanks>oh ok, I can do that
Should I stick it here? https://wiki.duraspace.org/display/FF/Design+-+Large+Files10:05
* ksclarke joins
<awoods>nbanks: That would be a great initial landing spot. We can move it later if needed.10:07
<nbanks>k10:08
* kaarefc leaves10:13
* kaarefc joins
* kaarefc leaves
<pivotal-bot___>Andrew Woods added comment: "Once this minor change is make, this looks good to go.10:19
https://github.com/osmandin/fcrepo4/commit/0a5de5b51..." https://www.pivotaltracker.com/story/show/54197412
Andrew Woods added comment: "Once this minor change is made, this looks good to go.10:20
https://github.com/osmandin/fcrepo4/commit/0a5de5b51..." https://www.pivotaltracker.com/story/show/54197412
* ajs6f leaves10:22
<nbanks>awoods: I was looking at the wrong error before, I am getting a class not found error now upon startup.10:27
<awoods>nbanks: Is it a dependency class from the filesystemconnector?10:28
<nbanks>no the class itself: java.lang.ClassNotFoundException: org.fcrepo.federation.filesystem.FileSystemConnector
awoods: I'm gonna do a commit, perhaps you could take a quick look at my pom.xml file and tell me if I'm out to lunch.10:29
<awoods>nbanks: glad to10:30
<nbanks>awoods: https://github.com/nigelgbanks/fcrepo-filesystem-modeshape-federation-connector/blob/master/pom.xml
<awoods>nbanks: maybe gist your repository.json as well
<nbanks>awoods: k10:31
https://gist.github.com/nigelgbanks/624128410:32
awoods: I'm not super family with maven I just more or less copied from other pom files.10:33
<awoods>nbanks: You will be super family one day.
* ajs6f joins10:34
<awoods>nbanks: pom.xml looks reasonable... and it builds a good looking jar.10:35
<nbanks>lol
* ajs6f leaves10:36
<awoods>nbanks: I am giving it a quick spin...
* ajs6f joins
<nbanks>awoods: Thanks!10:37
* tecoripa joins10:40
* tecoripa leaves10:46
* osmandin joins10:50
<nbanks>awoods: Whats the number we call for the meeting?10:59
<awoods>https://wiki.duraspace.org/display/FCREPO/2013-08-15+-+Fedora+Committer+Meeting
<nbanks>awoods: thanks!
<awoods>escowles: meeting?11:02
<escowles>coming soon -- problems getting skype running...11:03
* edInCo joins11:04
* tecoripa joins11:27
* jongibson joins11:40
* jongibson leaves
* kaarefc joins11:54
<awoods>nbanks: I was able to get your filesystemconnector by updating the fcrepo-webapp/pom.xml (per gist) and adding your repository.json to the fcrepo-jcr project, rebuilding and redeploying. The drop-in technique would not appear to be as simple as it sounds at this point.12:30
https://gist.github.com/awoods/6242264
<osmandin>awoods: I added a reply to your comment this morning.12:36
<awoods>osmandin: I see that. It looks like updating the component-scan was causing trouble.12:37
osmandin: Let me post the notes from the committers meeting, then I will give it a spin on my side.12:38
<nbanks>awoods: :) many thanks! I didn't know I had to add it to the webapp pom.xml as well!12:43
<awoods>nbanks: Let me know if it works for you12:44
<pivotal-bot___>Andrew Woods delivered "Add transactions support to Tuque" https://www.pivotaltracker.com/story/show/4901079712:45
<awoods>nbanks: Also, please review and "Accept/Reject": https://www.pivotaltracker.com/story/show/49010797
<pivotal-bot___>feature: Add transactions support to Tuque (delivered) / owner: Yuqing Jiang
* osmandin leaves12:47
* tecoripa leaves12:51
<awoods>nbanks: For simplicity, I dropped your repository.json over the config/single/repository.json (since that is the file used by default)12:57
<nbanks>awoods: That's what I was doing as well
in the fedora-jcr module
<awoods>nbanks: right12:58
<nbanks>awoods: I can now find the class but it isn't intializing correctly due to directoryPath member variable not be set in the intialization function or some such, I should be able to take it from here though, thanks again for the help!13:00
<awoods>nbanks: great... and please review the tracker item mentioned above.13:01
<nbanks>awoods: Sure thing.
<awoods>escowles: for the sparql server, are you thinking of running Fuseki in its default, standalone jetty? or are you thinking about doing the work to embed the Fuseki server into the fcrepo-webapp as a new JAXRS endpoint?13:06
<escowles>ideally, i'd like to have it be embedded -- though i'm not sure that's possible with fuseki. i'm looking at sesame right now to see if there is a war version that can be deployed in jetty more easily13:08
<ajs6f>awoods/escowles: For a first draft, I don't think it would be crazy for the SPARQL endpoint to live alongside the repo. After all, the triplestore itself won't be in the same artifact.13:09
<escowles>that would certainly be a lot easier to setup...
<ajs6f>Divide and conquer.13:10
<awoods>ajs6f/escowles: I was imagining the sparql endpoint would be in its own module, akin to fcrepo-transform.13:11
<ajs6f>awoods: I disagree. fcrepo-transform depends entirely on the repo. SPARQL requires a triplestore, which is _not_ part of the repo.
Unless you want to write a SPARQL <-> JCR query language thingy.
<awoods>ajs6f: What were you imagining?13:12
Rather, the question is, escowles, what were you imagining?
<escowles>well, we wrote and use a SPARQL <-> SQL translator....
but i was imagining a production install would have a separate triplestore installed13:13
but for ease of testing and simple out-of-the-box experience, it would be nice to have an embedded triplestore
<ajs6f>I vote that if we use a triplestore , we make a separate codebase, separate app, deployable separately. If we makea translator, that's different. That sounds more like an extension module.
NO EMBEDDED TRIPLESTORE. That was a bad mistake for Fedora 2/3. Easy to use / simple to set up triplestore? Sure. We could even make a13:14
n alternative packaging with the triplestore
prepackaged alongside a repo.
<cbeer>(but we probably don't want to do translation.. or people will start using it in production, and then want reification and reasoning and stuff)
<ajs6f>Oooh, gawd.
<escowles>cbeer: agree 100%
<awoods>escowles: So there are two questions: 1. where does the sparql endpoint live? 2. where does the triplestore live?
<ajs6f>OWL FULL IN XPATH.
1. There may be more than one kind of SPARQL endpoint, and the answer to your question depends on which one.13:15
If the kind based on a triplestore, then see 2).
2) Outside the repo.
<escowles>awoods: external triplestore with its own SPARQL endpoint13:16
<ajs6f>+1
<awoods>escowles: So sparql queries will go to http://host/fuseki/query
or something like that
<ajs6f>awoods: We can mung URLs.
We can cohere them into a single tree, if that's a concern.13:17
But I don't know that anyone is gong to care very much.
<escowles>yes, i think it's fine to have them to to a separate base URL, and we can setup a standard HTTP proxy/rewrite to put them in the same tree if that's a concern
<ajs6f>+113:18
I really the idea of the triplestore being default-seperate.
<awoods>escowles/ajs6f: Sounds reasonable
<ajs6f>That wold have saved a lot of people with Fedora 2/3 a lot of scaling headaches.
awoods: Sure, it all _sounds_ reasonable. Fedora always _sounds_ reasonable.
<escowles>so if the triplestore isn't embedded, then we need to configure the SPARQL endpoint base URL somewhere
and then the indexer can use that to figure out where to push updates to13:19
<awoods>escowles: hmmm
<ajs6f>escowles: Gonna need some indexer config no matter what. This just feels like another piece of that, like how GSearch needs to know where Solr lives.
<awoods>escowles: I was thinking the the message-consumer would be on the triplestore side.13:20
escowles: So the question is, where does the indexer/message-consumer live.
<ajs6f>awoods: There's the repo, the index, and the triplestore. They aren't necessarily the same.
The indexer and triplestore, that is.13:21
<awoods>ajs6f, agreed
<ajs6f>So the indexer has to somehow know where the triplestore is (that's right, escowles?).
<escowles>right -- the indexer could be completely separate from both the repo and the triplestore
<awoods>escowles/ajs6f: I am just curious where we plan on planting the indexer/message-consumer13:22
<ajs6f>That's an app. We could provide WAR packaging so that
it could live alongside the repo.
Or standalone app packaging so that it can run as a process itself.
Or whatever
That's Maven wizardy, and eddies will take care of that.13:23
He loves that stuff.
<escowles>i'm glad someone loves it
<awoods>what did you have in mind, escowles?
<escowles>pretty much what ajs6f outlined: standalone app that could be deployed wherever, plus a webapp wrapper so it could be bundled into a deployment13:24
<awoods>escowles/ajs6f, yet another war seems a bit heavy: fcrepo, triplestore, indexer13:26
<ajs6f>awoods: We should start with the utmost seperation and use machinery to combine
So start with three separate guys and provide a container artifact that has them all.13:27
<awoods>ajs6f: I do not disagree with separation
<ajs6f>awoods: I have a use case for it now— I want to take RI indexing off the main repo machines. I can't.
Why are you stopping me from fulfiling my dreams?13:28
Seriously, I think we need to keep modules smaller than we have in the past.
We can use good build machinery to offer deployable packages with sensible complements of functionality.
I want to separate "buckets of functionality" from "buckets of code".13:29
If we start with fine-grained artifacts and build up, I think we'll be much happier in the end.
<awoods>ajs6f: All of that is good, and I agree. I am just here pondering how we can also make deployment manageable.
<ajs6f>monolithic--
I think we should be considering profiles. Not Maven profiles, the more abstract idea of aggregations of functionlaity that meet common desires.13:30
E.g.
bare bones repo (no triplestore, no indexing)
sparql-enabled (comes packaged with triplestore and sparql engine)
etc..
If we write (e.g.) the triplestore code as a module that (as escowles suggested) is then wrapped for deployment in particular ways,13:31
it shouldn't be difficult to wrap several modules together.
It would be much, much easier if we had a module framework (cough-OSGi-cough). And we could allow integrators and deployers to define their own profiles.13:32
But we don't.
So we're stuck using build machinery as a half-assed version of a module framework. It's amazing, the shapes you can bend Maven into.13:33
<awoods>escowles/ajs6f: I think we have a starting point, and thanks for discussing: message-consumer/indexer is its own project. Triplestore is its own project (or maybe it is just a standalone Fuseki server that is just run, no fedora4-specific project needed).13:34
<ajs6f>We win!13:35
<awoods>ajs6f: that is the goal
<escowles>awoods: does that change anything about where the indexer lives -- still a separate dir in the fcrepo4 repo, or should it be a completely separate repo?
<ajs6f>We win ever day we spend with Fedora.
Seperate repo +113:36
Even barmintor agrees we should have more git repos than we do, and this is a classic example.
here's a possible rule of thumb: if two codebases could be running in separate POSIX processes, they might ought to be seperate git repos.13:37
<escowles>ok, sounds reasonable -- and the indexer could definitely be running on a separate machine13:38
<ajs6f>A fortiori.
<awoods>escowles: If we are planning on integrating via jms, then separate repo sounds like the direction. If we are planning on integrating via EventBus, then fcrepo/project sounds like the direction.13:39
<escowles>this is definitely sounding like a JMS consumer to me
<ajs6f>+1
<awoods>likewise
<ajs6f>The internal eventbus suffers from one great weakness:
it's all in memory.
The kinds of loads we expect from projects like SCAPE would push the limits.13:40
<escowles>so doing something crazy like stuffing the entire record into the eventbus messages would be very bad
<ajs6f>I hadn't thought of that at this morning's conversation, but you're 300% right.13:41
But what loads the internal bus
tends to be the JCR events, which are not defined by us and will never include much beyond the bare bones.
But we do reload events.
And we could "enhance" them with properties, etc.
And we could sure as heck blow out heap on any normal node by cramming huge amounts of what amounts to RDF into the bus.13:42
<awoods>ajs6f: How long does the EventBus hold onto any given event?
<ajs6f>Until all subscribers who are listening for it have received it.
cbeer found a persistent reimpl of the google eventbus (which we use).13:43
But we haven't bothered to start using it.
<awoods>ajs6f: which is not very long.
<ajs6f>awoods: Shouldn't be, and for our code, isn't.
I could imagine a task that seems easy being made synchronous with event consumption by a well-meaning dev.13:44
It turns out to be more time-consuming than expected, because it binds against CPU or disk.
And then backs up a huge glut of events onto the bus.
Like I-495 around DC. Happens twice a day, every day.
<awoods>ajs6f: If we have concerns around SCAPE-scale repos stressing the EventBus, that seems like that is a separate concern from whether an (asynchronous) indexer is listening on the bus.13:45
<ajs6f>Yes. I was just double-confirming what escowles said. It's yet another reason _not_ to publish messages that get much richer than they absolutely must.13:46
<awoods>ajs6f: absolutely, which is a different question than if the indexer should be listening on the bus.13:48
ajs6f: Not to say that jms is not a cleaner solution anyways.
<ajs6f>Yes, exactly.
And offers more flexibility for deployment.13:49
<awoods>definitely
less coupling
<ajs6f>I would love to move full-text, structural, and every other kind of indexing onto its own hardware.
Keep it away from the nodes that are serving requests from end-users.13:50
<awoods>I would love to have a way of marking our fcrepo git repositories as ones that are production and should be included in releases, and ones that are experimental.
<ajs6f>You can put extensible metadata on Git repos, right?13:51
cbeer: didn't you once explain this to me? Maybe beer was involved.
<awoods>ajs6f: Would that show up in the top-level browse of our git repo set?
<ajs6f>You know as much as I.13:52
<awoods>ajs6f: Anyways, it would be a treat.
<ajs6f>"as me"? I can never remembver.
How about a big green Mr. Yuck face on all the experimental repos?13:53
<awoods>+1
<ajs6f>Sorry, Wikipedia tells me that should have been _Mr. Yuk_. Also, no can do— he's trademarked.
<awoods>ajs6f: Or at least a naming convention.
* nbanks leaves13:55
<ajs6f>I don't know of any widely-used convention.
Maybe we take up a new futures-experimental account?
futures-X?
Anything with "X" in it is cool. I learnt that in the 1990s.
<awoods>ajs6f: Maybe fcrepo-whatever has been vetted.13:57
<gregjansen>what about a convention for release tags..
<ajs6f>That could work. "If you don't see the six-character seal of Fedora quality, don't bother taking out your wallet."
gregjansen: What about just the versions?13:58
<gregjansen>"Don't trust anything else"
<awoods>gregjansen: We should definitely have a convention for release tags.
<gregjansen>ajs6f: I generally use the version numbering here..
<ajs6f>afk bbi2014:04
<pivotal-bot___>Andrew Woods added comment: "If you are done with this one, @osmandin, please select "Finish"." https://www.pivotaltracker.com/story/show/49059799
* ajs6f leaves
<pivotal-bot___>Andrew Woods added comment: "If you are done with this one, @osmandin, please select "Finish". Your component-scan configuration is actu..." https://www.pivotaltracker.com/story/show/5419741214:05
* ajs6f joins14:11
gregjansen: "here"?
<gregjansen>ajs6f: at UNC
<pivotal-bot___>Osman Din finished "Update policy driven storage to move configuration from Spring into the JCR tree." https://www.pivotaltracker.com/story/show/4905979914:12
Osman Din finished "Create policies with REST-API" https://www.pivotaltracker.com/story/show/54197412
<ajs6f>k. Is there any reason not to just use the versioning?
I know we have "alpha" and "beta" in play, but...
* jongibson joins14:13
<gregjansen>seems adequate for conveying production vs. incubation, could do like Spring or Mode and append .Final or .RELEASE, but that seems heavy handed14:14
<ajs6f>Agreed. I'm not even sure we need to incorporate "α" or "β" in the versions at all. I am sure that if we do, we should use the Greek letters exclusively.14:16
<gregjansen>they should refer to functions that yield a range of versions14:17
<ajs6f>Excellent. And when people ask us why we would do such a thing, we should say, "The proper study of Fedora is the homomorphisms _between_ versions."14:18
<gregjansen>That sounds like a Travis integration right there14:19
<awoods>freaks14:20
<ajs6f>Welcome to the club.14:21
<awoods>cool freaks, of course.14:22
<gregjansen>jury is out14:23
<pivotal-bot___>Andrew Woods edited "Change web interface to upload Data-streams via POST instead of GET" https://www.pivotaltracker.com/story/show/5522724014:24
<ajs6f>Have y'all seen this:
http://fedora.fiz-karlsruhe.de/docs/
?
<pivotal-bot___>Andrew Woods edited "Change web interface to upload Data-streams via POST instead of GET" https://www.pivotaltracker.com/story/show/55227240
<ajs6f>I didn't they had done that.
didn't know, that is.
We should get them together with those crazy Czech dudes who came to this past OR.14:25
<awoods>This page (revision-5) was last changed on 17-Jul-2012
<ajs6f>Yeah, but there's still a lot of useful info there for 3-series users.14:28
To be blunt, the 3-series just hasn't changed that much since that time.
I mean, barmintor did a lot of tweaking and improvement.
But most of what they're documenting is still valid.
* jay leaves14:55
<ajs6f>bbl15:12
* ajs6f leaves
* nbanks joins15:22
* jay joins15:26
<pivotal-bot___>Andrew Woods started "Upgrade to Modeshape 3.4" https://www.pivotaltracker.com/story/show/5516974615:35
Andrew Woods added "Update policy-driven storage documentation" https://www.pivotaltracker.com/story/show/5525431015:39
Andrew Woods edited "Update policy-driven storage documentation" https://www.pivotaltracker.com/story/show/55254310
* gregjansen leaves15:54
* nbanks leaves15:55
* edInCo leaves16:15
* kaarefc leaves16:38
* github-ff joins16:49
[fcrepo4] awoods closed pull request #107: Updating namespaces to match new ontology with HTTP URIs (master...namespace-reorg) http://git.io/MianJA
* github-ff leaves
<awoods>escowles: Do you want to squash the commits in this pull request, or shall I? https://github.com/futures/ontology/pull/216:50
<escowles>awoods: can you do it please?16:51
<awoods>escowles: I'm on it.
* jay leaves16:54
* travis-ci joins17:05
[travis-ci] futures/fcrepo4#961 (master - b2ebc22 : Andrew Woods): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/d1d16a101cf3...b2ebc221cf26
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/10255865
* travis-ci leaves
<bljenkins>Project fcrepo-fixity-corrupter build #231: SUCCESS in 1 min 4 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-fixity-corrupter/231/17:08
* awoods leaves17:11
<bljenkins>Project fcrepo-kitchen-sink build #498: SUCCESS in 4 min 29 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-kitchen-sink/498/17:14
* github-ff joins17:27
[ontology] awoods pushed 1 new commit to master: http://git.io/_FFpyA
ontology/master 9c5b40b Esmé Cowles: Reconcile ontologies from Fedora3, hardcoded in baseline, and this Ontology repository...
* github-ff leaves
* awoods joins
* jongibson leaves17:28
<pivotal-bot___>Andrew Woods added comment: "Resolved with: ""17:35
https://github.com/futures/ontology/pull/2 and
https://github.com/futures/ontology/commit/9c..." https://www.pivotaltracker.com/story/show/50895969
Andrew Woods accepted "Use good predicates and document them in futures/ontology" https://www.pivotaltracker.com/story/show/50895969
* github-ff joins18:47
[fcrepo4] awoods pushed 1 new commit to master: http://git.io/p8Xd_Q
fcrepo4/master 2972371 osmandin: Update policy-driven-storage for runtime configuration...
* github-ff leaves
<pivotal-bot___>Andrew Woods added comment: "Resolved with: http://git.io/p8Xd_Q18:49
Also include #54197412" https://www.pivotaltracker.com/story/show/49059799
Andrew Woods accepted "Update policy driven storage to move configuration from Spring into the JCR tree." https://www.pivotaltracker.com/story/show/49059799
Andrew Woods added comment: "Resolved with: http://git.io/p8Xd_Q
Also includes #49059799" https://www.pivotaltracker.com/story/show/54197412
Andrew Woods accepted "Create policies with REST-API" https://www.pivotaltracker.com/story/show/54197412
* travis-ci joins19:01
[travis-ci] futures/fcrepo4#962 (master - 2972371 : osmandin): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/b2ebc221cf26...2972371cfc2b
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/10259647
* travis-ci leaves
<bljenkins>Project fcrepo-fixity-corrupter build #232: SUCCESS in 1 min 24 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-fixity-corrupter/232/19:06
Project fcrepo-legacy-api build #40: UNSTABLE in 3 min 14 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-legacy-api/40/19:08
Yippie, build fixed!19:29
Project fcrepo-legacy-api build #41: FIXED in 2 min 19 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-legacy-api/41/
awoods: Update pom.xml to include fcrepo-storage-policy:test
Project fcrepo-kitchen-sink build #499: UNSTABLE in 2 min 47 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-kitchen-sink/499/19:32
* github-ff joins19:54
[fcrepo-kitchen-sink] awoods pushed 1 new commit to master: http://git.io/8QiBkw
fcrepo-kitchen-sink/master 46ca9d2 Andrew Woods: Minor update of cache configuration
* github-ff leaves
<bljenkins>Project fcrepo-kitchen-sink build #500: STILL UNSTABLE in 2 min 1 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-kitchen-sink/500/19:56
* github-ff joins20:25
[fcrepo-kitchen-sink] awoods pushed 1 new commit to master: http://git.io/R3m-hQ
fcrepo-kitchen-sink/master bbf5c3b Andrew Woods: Remove policy-driven-storage xml
* github-ff leaves
* ksclarke leaves20:27
<bljenkins>Yippie, build fixed!20:31
Project fcrepo-kitchen-sink build #501: FIXED in 6 min 17 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-kitchen-sink/501/
* ksclarke joins21:09
* github-ff joins23:20
[fcrepo4] awoods pushed 1 new commit to master: http://git.io/QAxSFg
fcrepo4/master 74f3b2b Andrew Woods: Upgrade to Modeshape version 3.4.0...
* github-ff leaves
<pivotal-bot___>Andrew Woods added comment: "Resolved with http://git.io/QAxSFg" https://www.pivotaltracker.com/story/show/5516974623:21
Andrew Woods accepted "Upgrade to Modeshape 3.4" https://www.pivotaltracker.com/story/show/55169746
* travis-ci joins23:34
[travis-ci] futures/fcrepo4#963 (master - 74f3b2b : Andrew Woods): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/2972371cfc2b...74f3b2b88431
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/10265216
* travis-ci leaves

Generated by Sualtam