Open Pull Requests 2018-09-04This report contains a summary of the open pull requests in the JanusGraph project ecosystem. Everybody interested is encouraged to submit review comments and approvals,

Apologies for the slow response. Back from a long holiday weekend in the USA. My opinion is that we need to keep pushing forward on releases and actively encourage users to move up to the latest

I'm not against merging this into 0.2, but I'm actually not sure whether we want to do that. My understanding is that new features go mainly into master and that the 0.2 branch mostly gets bug fixes

@Jason: I created a initial PR#2 to merge my codebase into official JanusGraph-Python repo you created. While the PR was successful, I wasn't able to add any reviewers, you or Florian or Misha. I'll

Hi Florian, Thanks for the link to PR. Didn't know I had stumbled upon the same issue already. Oops :-P Anyways, quick questions, are there any plan to merge those changes to 0.2 branch? Reason I'm

Ok, I moved Mr. Pounds code over into my fork of the new repo and put a "scratch" PR in: https://github.com/JanusGraph/janusgraph-docker/pull/1 Let's move our discussion/feedback on approach over to

JanusGraph currently uses Coverity as a static code analysis tool. While this already led to some findings, it can unfortunately not be used to analyse code changes from pull requests. I wondered

The PR for this issue is here: https://github.com/JanusGraph/janusgraph/pull/1231 I would appropriate if someone could review it. Best regards, Alexandr

I think that makes sense as a starting point. I'm assuming there will be a fair amount of testing, discussions, and iterations before it gets pushed up as an official image.

I think I can get to that later this week. I could push Chris' work into a new branch on the new repo and then put a PR in so we could come to some consensus on if that's a good starting point?

One last question, mainly for Expero folks. Is anyone already intending to make the initial commit? I have a conference this week, but can work on this next week if not.

+1. I like CTR for upstream merges to help streamline the process. I personally really like getting a second set of eyes on my commits and enjoy the feedback. That being said I've gotten some great

https://github.com/JanusGraph/janusgraph-ambari is created

https://github.com/JanusGraph/janusgraph-docker is created

There hasn't been any negative responses on this thread. I will submit a PR today to update the PR docs to outline these updates in policy. 1. CTR is already part of our policy a. Committers are

JanusGraph simply lacks the required GraphSON serializers and deserializers for predicates. I created #1060 to track this issue and fixed it with PR #1061 which was merged into master and not into the

Yeah, a stack trace from Gremlin will us help to see what is going on. That should not be a dependency in that case. Thanks, Jerry

And, the following are serializers registered in my gremlin-server.yaml for JanusGraph 0.2.1 (I use the default packeged set of serializers): serializers: - { className:

Hi All, So as you all know I've been developing Client drivers for JanusGraph. I was able to test my initial version of library against JanusGraph 0.3.0 which uses TP 3.3.3. I now want to test the

Ah. I think we might be wrong in our understanding there. As I was trying to read the graph data from my underlaying backend (Cassandra) and not any Graph stored on HDFS using JanusGraph's