Date   

Re: To Contribute Our Code Enhancement Back to JanusGraph-FoundationDB Storage Plugin

"jacks...@gmail.com" <jackson.ch...@...>
 

These all are welcome contributions, thanks so much for taking the time to share these with the community it's greatly appreciated! 


On Sunday, October 4, 2020 at 10:11:39 AM UTC-4 Jun Li wrote:

Hello,

In eBay, we now have JanusGraph deployed in production, with FoundationDB being the backend store. The details on the design, deployment and the eBay use cases can be found in last year’s FoundationDB Summit (https://www.youtube.com/watch?v=EtB1BPG00PE). We took the earlier version of JanusGraph-FoundationDB plugin developed by Ted Wilmes in February 2019, and have made bug fixing and improvement over the last two years.  Now we would like to contribute our code back to the open source community, with the following improved features:

(1)Some bug fixing for the current JanusGraph FoundationDB plugin, and support of Async. Iterator. With Asynchronous Iterator, we can greatly leverage FoundationDB’s Asynchronous Iterator in terms of on-demand data stream pulling, better memory efficiency, better parallelism for MultiQuery support. We introduce “iterator” mode, along with the current mode that we call “list” mode.

(2)Enable Prefetching on Global Read Version of FoundationDB. This allows read-only query to use a slightly delayed GRV for snap-shot read (configurable, say 100 ms delayed), but save the GRV fetching time from the Primary DC. In the cross-datacenter production environment, the saving can be as large as > 50 ms due to this GRV pre-fetching.

(3) Support Read-Only GraphDB from the specified environment variables at GraphDB engine start-up.

(4)Context propagation that allows the Client Application to express “read-only” optimization support from Feature 2 mentioned above, to the FoundationDB storage plugin. So that write-involved queries will not be optimized. Furthermore, we can allow transaction reset with “read-commit-write” mode to be per-transaction, and only for the “read-only” queries, further optimization for “read-only” queries.The write-involved queries will still follow "serializable" mode for strong consistency.

(5)Enable TLS that is supported by FoundationDB. Security is important in the production environment.

(6)Enable Prometheus Metrics Monitoring. So that we can have good visibility across multiple datacenter deployment in the production environment. From the metrics collected, dashboards and alerts can be further developed easily. We can share our Grafana dashboards JSON configuration files and Prometheus alert rules used in our production environment  to the open-source community also. 

The first PR on Feature 1 above can be found at: https://github.com/JanusGraph/janusgraph-foundationdb/pull/50

Regards,

Jun Li and Hieu Nguyen




Re: To Contribute Our Code Enhancement Back to JanusGraph-FoundationDB Storage Plugin

Jason Plurad <plu...@...>
 

+1 thank you both for the enhancements. Looking forward to getting these contributions integrated into the project!


On Sunday, October 4, 2020 at 10:11:39 AM UTC-4 Jun Li wrote:

Hello,

In eBay, we now have JanusGraph deployed in production, with FoundationDB being the backend store. The details on the design, deployment and the eBay use cases can be found in last year’s FoundationDB Summit (https://www.youtube.com/watch?v=EtB1BPG00PE). We took the earlier version of JanusGraph-FoundationDB plugin developed by Ted Wilmes in February 2019, and have made bug fixing and improvement over the last two years.  Now we would like to contribute our code back to the open source community, with the following improved features:

(1)Some bug fixing for the current JanusGraph FoundationDB plugin, and support of Async. Iterator. With Asynchronous Iterator, we can greatly leverage FoundationDB’s Asynchronous Iterator in terms of on-demand data stream pulling, better memory efficiency, better parallelism for MultiQuery support. We introduce “iterator” mode, along with the current mode that we call “list” mode.

(2)Enable Prefetching on Global Read Version of FoundationDB. This allows read-only query to use a slightly delayed GRV for snap-shot read (configurable, say 100 ms delayed), but save the GRV fetching time from the Primary DC. In the cross-datacenter production environment, the saving can be as large as > 50 ms due to this GRV pre-fetching.

(3) Support Read-Only GraphDB from the specified environment variables at GraphDB engine start-up.

(4)Context propagation that allows the Client Application to express “read-only” optimization support from Feature 2 mentioned above, to the FoundationDB storage plugin. So that write-involved queries will not be optimized. Furthermore, we can allow transaction reset with “read-commit-write” mode to be per-transaction, and only for the “read-only” queries, further optimization for “read-only” queries.The write-involved queries will still follow "serializable" mode for strong consistency.

(5)Enable TLS that is supported by FoundationDB. Security is important in the production environment.

(6)Enable Prometheus Metrics Monitoring. So that we can have good visibility across multiple datacenter deployment in the production environment. From the metrics collected, dashboards and alerts can be further developed easily. We can share our Grafana dashboards JSON configuration files and Prometheus alert rules used in our production environment  to the open-source community also. 

The first PR on Feature 1 above can be found at: https://github.com/JanusGraph/janusgraph-foundationdb/pull/50

Regards,

Jun Li and Hieu Nguyen




To Contribute Our Code Enhancement Back to JanusGraph-FoundationDB Storage Plugin

Jun Li <jltz9...@...>
 

Hello,

In eBay, we now have JanusGraph deployed in production, with FoundationDB being the backend store. The details on the design, deployment and the eBay use cases can be found in last year’s FoundationDB Summit (https://www.youtube.com/watch?v=EtB1BPG00PE). We took the earlier version of JanusGraph-FoundationDB plugin developed by Ted Wilmes in February 2019, and have made bug fixing and improvement over the last two years.  Now we would like to contribute our code back to the open source community, with the following improved features:

(1)Some bug fixing for the current JanusGraph FoundationDB plugin, and support of Async. Iterator. With Asynchronous Iterator, we can greatly leverage FoundationDB’s Asynchronous Iterator in terms of on-demand data stream pulling, better memory efficiency, better parallelism for MultiQuery support. We introduce “iterator” mode, along with the current mode that we call “list” mode.

(2)Enable Prefetching on Global Read Version of FoundationDB. This allows read-only query to use a slightly delayed GRV for snap-shot read (configurable, say 100 ms delayed), but save the GRV fetching time from the Primary DC. In the cross-datacenter production environment, the saving can be as large as > 50 ms due to this GRV pre-fetching.

(3) Support Read-Only GraphDB from the specified environment variables at GraphDB engine start-up.

(4)Context propagation that allows the Client Application to express “read-only” optimization support from Feature 2 mentioned above, to the FoundationDB storage plugin. So that write-involved queries will not be optimized. Furthermore, we can allow transaction reset with “read-commit-write” mode to be per-transaction, and only for the “read-only” queries, further optimization for “read-only” queries.The write-involved queries will still follow "serializable" mode for strong consistency.

(5)Enable TLS that is supported by FoundationDB. Security is important in the production environment.

(6)Enable Prometheus Metrics Monitoring. So that we can have good visibility across multiple datacenter deployment in the production environment. From the metrics collected, dashboards and alerts can be further developed easily. We can share our Grafana dashboards JSON configuration files and Prometheus alert rules used in our production environment  to the open-source community also. 

The first PR on Feature 1 above can be found at: https://github.com/JanusGraph/janusgraph-foundationdb/pull/50

Regards,

Jun Li and Hieu Nguyen




Re: JanusGraph Community Meetup - September 30, 2020

Ted Wilmes <twi...@...>
 

Hello,
Quick FYI, the date for this meetup has been moved to October 7th at 1 PM Central. Sign ups can still be made here: https://www.experoinc.com/get/janusgraph-user-group

Thanks,
Ted

On Wed, Sep 23, 2020 at 12:55 PM Ted Wilmes <twi...@...> wrote:
Hello,
Expero Inc. will be hosting a JanusGraph community meetup one week from today on Wednesday, September 30th at 11 AM Central time. If you are interested in attending, you can sign up here: https://www.experoinc.com/get/janusgraph-user-group.

There will be two speakers discussing JanusGraph query optimization and how to manage multiple graphs from a single JanusGraph install along with a roundtable Q&A where we'll field JanusGraph questions from attendees.

Thanks,
Ted


Janus User Group Date Change

Scott Heath <scott...@...>
 

Hello fellow JanusGraph'rs
The date and time for the upcoming user group meeting has changed.  Please join us on the new date and time


Regards

Scott Heath | 

Expero Inc | www.experoinc.com
 | P+1 512.368.6080 | E: scott...@... |


JanusGraph Community Meetup - September 30, 2020

Ted Wilmes <twi...@...>
 

Hello,
Expero Inc. will be hosting a JanusGraph community meetup one week from today on Wednesday, September 30th at 11 AM Central time. If you are interested in attending, you can sign up here: https://www.experoinc.com/get/janusgraph-user-group.

There will be two speakers discussing JanusGraph query optimization and how to manage multiple graphs from a single JanusGraph install along with a roundtable Q&A where we'll field JanusGraph questions from attendees.

Thanks,
Ted


New committer: Boxuan Li

Oleksandr Porunov <alexand...@...>
 

On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome a new committer on the project!

Boxuan Li has been a solid contributor. He already contributed many performance improvements, bug fixes and provided many PR reviews.


Congratulations, Boxuan Li!


New committer: Florian Grieskamp

Oleksandr Porunov <alexand...@...>
 

On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome a new committer on the project!

Florian Grieskamp has been a solid contributor. He already contributed many performance improvements, contributions to janusgraph-foundationdb and provided many PR reviews.


Congratulations, Florian Grieskamp!


Re: Add support to AWS Keyspaces (or DynamoDB) as storage backend #2154

Mick Delaney <mi...@...>
 

Yes, seems compelling given the pricing of Keyspaces


On Thursday, July 2, 2020 at 2:42:02 PM UTC+1 nic...@... wrote:

Hi all, 

I'm reporting here a feature request that i added as issue on the Janusgraph github project.

Describe the feature:
Add the possibility to use AWS Keyspaces as storage backend since it is a SaaS service and compatible with Cassandra. Or add the possibility to use AWS DynamoDB as storage backend using the old connector made by AWS Labs.
These could be good feature since developers could use managed services and avoid the difficulty in manage an "important storage like Cassandra"

Describe a specific use case for the feature:
In a completely SaaS architecture is common to have DBs and other technologies provided as a service. Have the possibility to connect Janus to an already existing (for other purposes) Keyspaces cluster or DynamoDB endpoint gives the possibility to have all data in a single service.



Is it something that could be feasable? Or something that someone else could use or need?? 

What do you think about it?


Cheers, 


Nicolò


How to find if a vertex has at least 1 relationship/edge to a thousands of vertex with specific property

alvinl...@...
 

Let say I have this sample data

Vertex[type: Person, name: Foo] ---hasPet---> Vertex[type: Dog, name: Dog1]
Vertex[type: Person, name: Bar] ---hasPet---> Vertex[type: Cat, name: Cat1]
Vertex[type: Person, name: Bazz] ---hasPet---> Vertex[type: Dog, name: Dog2]
Vertex[type: Person, name: Bazz] ---hasPet---> Vertex[type: Dog, name: Dog3]

Then I wanted to find any Person-type vertex who has at least has pet which is a dog.

How could find all those Person-type vertices without traversing all the non-person type vertices?

I tried this query, but still it is traversing all pets of Bazz, I wanted to stop the traversal as soon as I found any matches since Bazz might have thousand other pets.

My query:

g.traversal().V().has("type", "Person").repeat(out("hasPet").simplePath()).until(has("type", "Dog")).simplePath().in().valueMap("name")

And this is the result:

[Foo]
[Bazz]
[Bazz]

What I like is:

[Foo]
[Bazz]


janusgraph same instance id already exist.force shutdown required exception

srinu....@...
 

Hi,

                   iam facing error janusgraph same instance id already exist.force shutdown required exception  when i dont close session from gremlin console
                   and if i restart janusgraph server.


                  i added graph.replace-instance-if-exists=true to janusgraph.properties.still facing same issue.
                 iam using cassandra 3 node cluster as backend storage.
                
                Any Help is Appreciated.


 Thanks,
 RLA.


Re: [janusgraph-foundationdb] - Repository cleanup questions

Misha Brukman <mbru...@...>
 

FYI, looks like there's already a PR to move files and update the packages. Additionally, Jan Jansen volunteered to work on the Travis CI config after the PR to add testcontainers is merged.


On Thu, Jul 16, 2020 at 1:07 AM Christopher Jackson <jackson.ch...@...> wrote:
Thanks so much for the guidance Misha and for creating the work items. I will start working on these and request you as a reviewer. 

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/42449c06-0460-4e19-bc1b-71acfdced7a8o%40googlegroups.com.


Re: [janusgraph-foundationdb] - Repository cleanup questions

Christopher Jackson <jackson.ch...@...>
 

Thanks so much for the guidance Misha and for creating the work items. I will start working on these and request you as a reviewer. 


Re: [DISCUSS] Revamp JanusGraph Management

"fa...@googlemail.com" <faro...@...>
 

Hi Oleksandr,

I started to work on a https://github.com/farodin91/janusgraph-grpc client/server for JanusGraph to management all parts of JanusGraph on of cause would be schema. Other parts are for example CFG, or index management.
My next step is integrate a basic gRPC client JanusGraph which allows us to get some basic information of running JanusGraph server. I will start to extend it by schema function step by step. The gRPC protocol can be later used to provide a tool to import and export the schema as JSON.

Greetings,
Jan

On Wednesday, July 15, 2020 at 12:23:44 PM UTC+2 Oleksandr Porunov wrote:
Hi,
As a follow up to this thread I also think it would be great if we could use DDL for schema definition.
I don't know yet the format which we should use (whether it should be gremlin query or some json / xml or something else).
Is there any updates regarding Schema Management?
Just to not do double work for Schema Management, I would like to know if someone was working on making DDL for schema. If so, were there any troubles? What format is better to use for schema definition?
Currently I am thinking about JSON format, something like:
[
  {
    type: vertexLabel,
    name: myVertexLabel
  },
  {
    type: edgeLabel,
    name: myEdgeLabel
    multiplicity: MANY2ONE
  },
  {
      type: propertyKey,
      dataType: String.class
      name: myProperty,
      cardinality: LIST
   },
   {
      type: compositeIndex,
      indexOnly: myVertexLabel,
      keys: [
         {
             name: myProperty
          }
      ]
   },
   {
      type: mixedIndex,
      keys: [
         {
             name: myProperty,
             parameters: [
                {
                     key: parameterKey,
                     value: parameterValue
                }
             ]
          }
      ]
    }
]

I didn't think much about schema definition, so I might miss some points. If you have any thoughts / suggestions on the format or how should this feature be implemented, it would be great. Also, I didn't work with GraphQL, so will check a little bit later if that format might be used as well.

Best regards,
Oleksandr

On Friday, February 28, 2020 at 8:30:21 PM UTC+2 fa...@... wrote:

An HTTP API would have the benefit of making the schema management available to users of the Gremlin server without the mentioned problems for making it accessible via Gremlin. As it would just expose the underlying Java API (current or a new one), it would be 

nice if the web service would be optional if JG is used embedded.


+1

One of my major concerns is to make JanusGraph more modular.


Re: [DISCUSS] Revamp JanusGraph Management

Oleksandr Porunov <alexand...@...>
 

Hi,
As a follow up to this thread I also think it would be great if we could use DDL for schema definition.
I don't know yet the format which we should use (whether it should be gremlin query or some json / xml or something else).
Is there any updates regarding Schema Management?
Just to not do double work for Schema Management, I would like to know if someone was working on making DDL for schema. If so, were there any troubles? What format is better to use for schema definition?
Currently I am thinking about JSON format, something like:
[
  {
    type: vertexLabel,
    name: myVertexLabel
  },
  {
    type: edgeLabel,
    name: myEdgeLabel
    multiplicity: MANY2ONE
  },
  {
      type: propertyKey,
      dataType: String.class
      name: myProperty,
      cardinality: LIST
   },
   {
      type: compositeIndex,
      indexOnly: myVertexLabel,
      keys: [
         {
             name: myProperty
          }
      ]
   },
   {
      type: mixedIndex,
      keys: [
         {
             name: myProperty,
             parameters: [
                {
                     key: parameterKey,
                     value: parameterValue
                }
             ]
          }
      ]
    }
]

I didn't think much about schema definition, so I might miss some points. If you have any thoughts / suggestions on the format or how should this feature be implemented, it would be great. Also, I didn't work with GraphQL, so will check a little bit later if that format might be used as well.

Best regards,
Oleksandr


On Friday, February 28, 2020 at 8:30:21 PM UTC+2 fa...@... wrote:

An HTTP API would have the benefit of making the schema management available to users of the Gremlin server without the mentioned problems for making it accessible via Gremlin. As it would just expose the underlying Java API (current or a new one), it would be 

nice if the web service would be optional if JG is used embedded.


+1

One of my major concerns is to make JanusGraph more modular.


Re: [janusgraph-foundationdb] - Repository cleanup questions

Misha Brukman <mbru...@...>
 

I went ahead and created individual issues for each of the tasks in case anyone wants to jump in and help with the cleanup process:
Please let me know if you have any questions; feel free to add me as a reviewer on PRs addressing any of these issues.

Misha


On Tue, Jul 14, 2020 at 6:42 PM Misha Brukman <mbru...@...> wrote:
I support the proposal to change the package names/paths to match JanusGraph style since it was moved from Expero to the JanusGraph org. The changes I think you want to make are:
  • move directories from com/experoinc/janusgraph --> org/janusgraph
  • update package names accordingly
  • update copyright line from Expero Inc. -> JanusGraph Authors
  • create AUTHORS.txt, add Expero Inc there
  • create CONTRIBUTORS.txt, add Ted Wilmes there (and anyone else in the Git history so far, but see below for details on copyright)
What's the difference between these two and why do we need both of them?
  • AUTHORS.txt are the copyright holders aka copyright owners of the code — these are either people (if they're individuals and they own the copyright of their contributions) or companies (if they own the copyright of their employees' contributions)
  • CONTRIBUTORS.txt — these are the people that did the actual work, who don't own the copyright themselves (if they do, they're already in AUTHORS.txt)
For all of us whose companies own the copyright of our contributions to JanusGraph (as evidenced by the fact that we're on our companies' Corporate CLAs), our company name would go into AUTHORS.txt and our own name would go into CONTRIBUTORS.txt.

However, before we do any changes to the code, as a first PR, can we please add a .travis.yml file to the repo so that we start building and testing each change? Otherwise, we'll be in the situation we were in with the JanusGraph repo (before Travis CI was setup), where PR reviewers had to manually patch the PR to verify that it builds and tests pass before approving them, and that was painful. The 2 big cleanups where PR #1 and #2, and Travis CI config was only added in PR #3, and Henry Saputra was very patient in doing this manually, but let's not repeat that again. :-)

Back to the original topic: I did the initial cleanup on the JanusGraph repo after importing from thinkaurelius/titan; you can see my changes in:
Specifically, for PR #2 (which consists of 2 commits), you can see the scripts and the changes that were done in the individual commits:
Please feel free to reuse & adapt the scripts as needed for this update and include them in the commit message, as they may be useful in the future, should someone else donate another large subproject to JanusGraph!

Re: @author tags: I think we kept a bunch of them for historical reasons to give credit to the original Aurelius folks (even though we also kept the full Git history, so everyone can see who the original author was). https://github.com/JanusGraph/janusgraph/search?q=%22%40author%22 shows 607 appearances of `author@` in the codebase.

We also kept <developer> and <contributor> tags in pom.xml files, e.g., see https://github.com/JanusGraph/janusgraph/blob/c433f54e01887245f02189cceac83dafdec94514/pom.xml#L19-L46 — I don't think there's a particular need or desire to remove either @author lines or the <developer> / <contributor> tags. If we want to make a large-scale change to remove ALL of them, we should discuss this with a vote on janusgraph-dev@ but I'm not sure whether it's worth it, and as I mentioned above, we owe a lot of gratitude to the original authors of Titan from which JanusGraph came, so I would feel bad removing them all in one fell swoop.

Hope this helps!

I'm happy to help with these changes, or if you'd like to make them, I'm happy to review them.

Misha

On Tue, Jul 14, 2020 at 5:47 PM Jason Plurad <plu...@...> wrote:
I didn't work on initial fork from thinkaurelius/titan, so it'd be great if those folks chimed in on this thread.

From what I recall of that fork process, all of the author tags were removed from the source files, and the AUTHORS.txt + CONTRIBUTORS.txt were created in its place. We could go ahead and create an AUTHORS.txt and put Expero Inc in it. I don't think a CONTRIBUTORS.txt file is required. All JanusGraph contributors have to sign a CLA to contribute, and once signed, they are covered by "JanusGraph Authors" (twilmes is already covered by that also).

For copyright, I think we'd need a NOTICE.txt (https://github.com/JanusGraph/janusgraph/blob/master/NOTICE.txt) which can describe that the code was contributed by Expero Inc to JanusGraph. Then update the copyright in the source files to "JanusGraph Authors". Check out the Apache License (https://www.apache.org/licenses/LICENSE-2.0) under Redistribution of Derivative Works.

On Friday, July 10, 2020 at 5:54:50 PM UTC-4 jacks...@... wrote:
Hi Folks,

I wanted to get started on making some contributions to the foundationdb adapter now that the initial repo is established, first and foremost by cleaning up the repo. IE. making it conform to the standards/conventions used by the rest of the janusgraph projects/repositories. While working on https://github.com/JanusGraph/janusgraph-foundationdb/issues/10 I also wanted to tackle other cleanup type items. In particular I'm curious to what should be done (if anything) about lines like these:
https://github.com/JanusGraph/janusgraph-foundationdb/blob/master/src/main/java/com/experoinc/janusgraph/diskstorage/foundationdb/FoundationDBConfigOptions.java#L1
https://github.com/JanusGraph/janusgraph-foundationdb/blob/master/src/main/java/com/experoinc/janusgraph/diskstorage/foundationdb/FoundationDBConfigOptions.java#L26

Should the copyright tags and author tags still be present? And in general how do `@author` tags work in the janusgraph open source project? I know that the main repository has files:
https://github.com/JanusGraph/janusgraph/blob/master/AUTHORS.txt
https://github.com/JanusGraph/janusgraph/blob/master/CONTRIBUTORS.txt
which I believe cover both these points, should we create analogous files in this repository and remove author tags and copyright statements from each individual source file?

Again I don't know what proper etiquette is in this regard so looking for input from others before making any changes.

Regards,
Christopher Jackson

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/c11b7d10-7ab9-4f56-bcce-3ebdc22889acn%40googlegroups.com.


Re: [janusgraph-foundationdb] - Repository cleanup questions

Misha Brukman <mbru...@...>
 

I support the proposal to change the package names/paths to match JanusGraph style since it was moved from Expero to the JanusGraph org. The changes I think you want to make are:
  • move directories from com/experoinc/janusgraph --> org/janusgraph
  • update package names accordingly
  • update copyright line from Expero Inc. -> JanusGraph Authors
  • create AUTHORS.txt, add Expero Inc there
  • create CONTRIBUTORS.txt, add Ted Wilmes there (and anyone else in the Git history so far, but see below for details on copyright)
What's the difference between these two and why do we need both of them?
  • AUTHORS.txt are the copyright holders aka copyright owners of the code — these are either people (if they're individuals and they own the copyright of their contributions) or companies (if they own the copyright of their employees' contributions)
  • CONTRIBUTORS.txt — these are the people that did the actual work, who don't own the copyright themselves (if they do, they're already in AUTHORS.txt)
For all of us whose companies own the copyright of our contributions to JanusGraph (as evidenced by the fact that we're on our companies' Corporate CLAs), our company name would go into AUTHORS.txt and our own name would go into CONTRIBUTORS.txt.

However, before we do any changes to the code, as a first PR, can we please add a .travis.yml file to the repo so that we start building and testing each change? Otherwise, we'll be in the situation we were in with the JanusGraph repo (before Travis CI was setup), where PR reviewers had to manually patch the PR to verify that it builds and tests pass before approving them, and that was painful. The 2 big cleanups where PR #1 and #2, and Travis CI config was only added in PR #3, and Henry Saputra was very patient in doing this manually, but let's not repeat that again. :-)

Back to the original topic: I did the initial cleanup on the JanusGraph repo after importing from thinkaurelius/titan; you can see my changes in:
Specifically, for PR #2 (which consists of 2 commits), you can see the scripts and the changes that were done in the individual commits:
Please feel free to reuse & adapt the scripts as needed for this update and include them in the commit message, as they may be useful in the future, should someone else donate another large subproject to JanusGraph!

Re: @author tags: I think we kept a bunch of them for historical reasons to give credit to the original Aurelius folks (even though we also kept the full Git history, so everyone can see who the original author was). https://github.com/JanusGraph/janusgraph/search?q=%22%40author%22 shows 607 appearances of `author@` in the codebase.

We also kept <developer> and <contributor> tags in pom.xml files, e.g., see https://github.com/JanusGraph/janusgraph/blob/c433f54e01887245f02189cceac83dafdec94514/pom.xml#L19-L46 — I don't think there's a particular need or desire to remove either @author lines or the <developer> / <contributor> tags. If we want to make a large-scale change to remove ALL of them, we should discuss this with a vote on janusgraph-dev@ but I'm not sure whether it's worth it, and as I mentioned above, we owe a lot of gratitude to the original authors of Titan from which JanusGraph came, so I would feel bad removing them all in one fell swoop.

Hope this helps!

I'm happy to help with these changes, or if you'd like to make them, I'm happy to review them.

Misha

On Tue, Jul 14, 2020 at 5:47 PM Jason Plurad <plu...@...> wrote:
I didn't work on initial fork from thinkaurelius/titan, so it'd be great if those folks chimed in on this thread.

From what I recall of that fork process, all of the author tags were removed from the source files, and the AUTHORS.txt + CONTRIBUTORS.txt were created in its place. We could go ahead and create an AUTHORS.txt and put Expero Inc in it. I don't think a CONTRIBUTORS.txt file is required. All JanusGraph contributors have to sign a CLA to contribute, and once signed, they are covered by "JanusGraph Authors" (twilmes is already covered by that also).

For copyright, I think we'd need a NOTICE.txt (https://github.com/JanusGraph/janusgraph/blob/master/NOTICE.txt) which can describe that the code was contributed by Expero Inc to JanusGraph. Then update the copyright in the source files to "JanusGraph Authors". Check out the Apache License (https://www.apache.org/licenses/LICENSE-2.0) under Redistribution of Derivative Works.

On Friday, July 10, 2020 at 5:54:50 PM UTC-4 jacks...@... wrote:
Hi Folks,

I wanted to get started on making some contributions to the foundationdb adapter now that the initial repo is established, first and foremost by cleaning up the repo. IE. making it conform to the standards/conventions used by the rest of the janusgraph projects/repositories. While working on https://github.com/JanusGraph/janusgraph-foundationdb/issues/10 I also wanted to tackle other cleanup type items. In particular I'm curious to what should be done (if anything) about lines like these:
https://github.com/JanusGraph/janusgraph-foundationdb/blob/master/src/main/java/com/experoinc/janusgraph/diskstorage/foundationdb/FoundationDBConfigOptions.java#L1
https://github.com/JanusGraph/janusgraph-foundationdb/blob/master/src/main/java/com/experoinc/janusgraph/diskstorage/foundationdb/FoundationDBConfigOptions.java#L26

Should the copyright tags and author tags still be present? And in general how do `@author` tags work in the janusgraph open source project? I know that the main repository has files:
https://github.com/JanusGraph/janusgraph/blob/master/AUTHORS.txt
https://github.com/JanusGraph/janusgraph/blob/master/CONTRIBUTORS.txt
which I believe cover both these points, should we create analogous files in this repository and remove author tags and copyright statements from each individual source file?

Again I don't know what proper etiquette is in this regard so looking for input from others before making any changes.

Regards,
Christopher Jackson

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/c11b7d10-7ab9-4f56-bcce-3ebdc22889acn%40googlegroups.com.


Re: [janusgraph-foundationdb] - Repository cleanup questions

Jason Plurad <plu...@...>
 

I didn't work on initial fork from thinkaurelius/titan, so it'd be great if those folks chimed in on this thread.

From what I recall of that fork process, all of the author tags were removed from the source files, and the AUTHORS.txt + CONTRIBUTORS.txt were created in its place. We could go ahead and create an AUTHORS.txt and put Expero Inc in it. I don't think a CONTRIBUTORS.txt file is required. All JanusGraph contributors have to sign a CLA to contribute, and once signed, they are covered by "JanusGraph Authors" (twilmes is already covered by that also).

For copyright, I think we'd need a NOTICE.txt (https://github.com/JanusGraph/janusgraph/blob/master/NOTICE.txt) which can describe that the code was contributed by Expero Inc to JanusGraph. Then update the copyright in the source files to "JanusGraph Authors". Check out the Apache License (https://www.apache.org/licenses/LICENSE-2.0) under Redistribution of Derivative Works.


On Friday, July 10, 2020 at 5:54:50 PM UTC-4 jacks...@... wrote:
Hi Folks,

I wanted to get started on making some contributions to the foundationdb adapter now that the initial repo is established, first and foremost by cleaning up the repo. IE. making it conform to the standards/conventions used by the rest of the janusgraph projects/repositories. While working on https://github.com/JanusGraph/janusgraph-foundationdb/issues/10 I also wanted to tackle other cleanup type items. In particular I'm curious to what should be done (if anything) about lines like these:
https://github.com/JanusGraph/janusgraph-foundationdb/blob/master/src/main/java/com/experoinc/janusgraph/diskstorage/foundationdb/FoundationDBConfigOptions.java#L1
https://github.com/JanusGraph/janusgraph-foundationdb/blob/master/src/main/java/com/experoinc/janusgraph/diskstorage/foundationdb/FoundationDBConfigOptions.java#L26

Should the copyright tags and author tags still be present? And in general how do `@author` tags work in the janusgraph open source project? I know that the main repository has files:
https://github.com/JanusGraph/janusgraph/blob/master/AUTHORS.txt
https://github.com/JanusGraph/janusgraph/blob/master/CONTRIBUTORS.txt
which I believe cover both these points, should we create analogous files in this repository and remove author tags and copyright statements from each individual source file?

Again I don't know what proper etiquette is in this regard so looking for input from others before making any changes.

Regards,
Christopher Jackson


[janusgraph-foundationdb] - Repository cleanup questions

Christopher Jackson <jackson.ch...@...>
 

Hi Folks,

I wanted to get started on making some contributions to the foundationdb adapter now that the initial repo is established, first and foremost by cleaning up the repo. IE. making it conform to the standards/conventions used by the rest of the janusgraph projects/repositories. While working on https://github.com/JanusGraph/janusgraph-foundationdb/issues/10 I also wanted to tackle other cleanup type items. In particular I'm curious to what should be done (if anything) about lines like these:
https://github.com/JanusGraph/janusgraph-foundationdb/blob/master/src/main/java/com/experoinc/janusgraph/diskstorage/foundationdb/FoundationDBConfigOptions.java#L1
https://github.com/JanusGraph/janusgraph-foundationdb/blob/master/src/main/java/com/experoinc/janusgraph/diskstorage/foundationdb/FoundationDBConfigOptions.java#L26

Should the copyright tags and author tags still be present? And in general how do `@author` tags work in the janusgraph open source project? I know that the main repository has files:
https://github.com/JanusGraph/janusgraph/blob/master/AUTHORS.txt
https://github.com/JanusGraph/janusgraph/blob/master/CONTRIBUTORS.txt
which I believe cover both these points, should we create analogous files in this repository and remove author tags and copyright statements from each individual source file?

Again I don't know what proper etiquette is in this regard so looking for input from others before making any changes.

Regards,
Christopher Jackson


Re: [janusgraph-foundationdb] initial fork options

Christopher Jackson <jackson.ch...@...>
 

Thanks Ted and Expero for contributing this code and migrating it to its new home so quickly!

81 - 100 of 1513