+1, given the current limitation with Travis CI. Thanks, Jerry

Hello JanusGraph developers, I'd like to request that the PR evaluation/approval process be updated to require successful local testing (mvn clean install) of all relevant test suites before merging

I just want to clarify the proposal, so we will just need the IGFS portion of Apache Ignite to add in-memory cache on top of HDFS ?

Hi, I'd be happy to help where I can. I'll read up a bit on Apache Ignite. Cheers Pieter

FYI, I created a milestone for the 0.1.0 release (since we're on 0.1.0-SNAPSHOT now): https://github.com/JanusGraph/janusgraph/milestone/1 Let's start adding all blockers to that milestone so that

+1 We are on the same page. The first release will be an introduction release. New face, updated dependencies as appropriate, on par with Titan 1.0/1.1 in term of testing and quality, with

Apache release process sounds good to me. Perhaps we can discuss what to include on this list and then mark the relevant issues in github with the 0.1 milestone. As far as what to include, I think it

I will be testing JanusGraph on ScyllaDB.

Hi Taylor, Definitely agree on this! And we've had a number of users ask for this explicitly as well. No strong feelings on this matter, the Apache release process sounds good to me. We can start

David Robinson presented The Many Faces of Apache Ignite (PDF) at Apache: Big Data NA 2016. He has since moved on from IBM, so his work on Genesis Graph was unfinished and unreleased. It predated the

I’d like to start a discussion to flesh out a list of tasks necessary to make an initial release. Having a downloadable binary release and associated maven artifacts, IMO would help in terms of

Hi, I have never heard of Apache Ignite and Kuppitz just introduced me to Apache Geode too. Crazy cool technologies. Personally, I think it would be great to try and build

Great write-up Dylan. I'm not familiar with Apache Ignite beyond name recognition so I'll be doing some more reading. Here's a few thoughts that popped into my head. * Transactions - what concurrency

Great input, thanks everyone. I think we're all pretty much on the same page. If you guys are okay with it, I'll put together a PR to add some candidate documentation around our policies. I'll hit

So it is (quite obviously and plainly stated at the bottom of every comment box, so I'm sorry for asking) possible to attach design docs to github issues. Doh. Also, if we do ever want to migrate to

I would recommend stick with Github issues for now until we find it is not enough for us to track changes and enhancement requests. Keep it simple.

I’d lean toward keeping it simple and starting out with GitHub issues, especially since the community is still small. If we outgrow or discover difficulty with GitHub, we can always change

Should also have linked to the thread on the gremlin-users list - here you go: https://groups.google.com/forum/#!topic/gremlin-users/GNFgkaKjnFc

A couple of points to consider: +1 policy for commits: A lot of Apache projects have guidelines for how long a pull request must be open before it can be merged. Guidelines typically range from

So I've been toying with this idea for a while, but I want to make it concrete here so we can shoot it down, mutate, or build it up as needed: I think that we should on-board an additional backend for