Date   

Re: Creating a Wikipedia page for JanusGraph

Alexandr Porunov <alexand...@...>
 

Thank you for additional information about the logo. I've updated this information on the Wikipedia page.

About JanusGrapg users. I think it depends on the reviewer. 

I see here that HBase included production deployments of notable enterprises and everything is OK:
https://en.wikipedia.org/wiki/Apache_HBase

Also, I see that Cassandra includes notable applications, but it has a warning:
https://en.wikipedia.org/wiki/Apache_Cassandra

MariaDB also lists its costumers and everything is OK:
https://en.wikipedia.org/wiki/MariaDB

Hard to tell if we should list users or not.

Personally, my opinion: we can include a list of projects powered by JanusGraph and costumers in production but we should add a reference which proves this fact for each project / costumer. If there is no a reference which really proves it than we should not add such projects / users into the Wikipedia page. Nevertheless, if the review is rejected, we can remove this section and ask for re-review.

Also, I think we can include this information in the Wiki page:
- "Visualization" section
- "Presentations" section
- "Papers" section to list papers where JanusGraph is mentioned.
- "Features" section
- "Schema and Data Modeling" section

What do you think?

On Friday, September 21, 2018 at 5:22:27 AM UTC+3, Misha Brukman wrote:
On Thu, Sep 20, 2018 at 4:07 AM, Alexandr Porunov <alex...@...> wrote:
I think it worth to create a Wikipedia page for JanusGraph and then add it into the list of notable graph databases.

Here is a draft page:

Is it worth mentioning some examples of software powered by JanusGraph:
or customers using JanusGraph in production:

What do you think? Also, what does Wikipedia think / require by policy? On the one hand, adding these will help improve the chances it'll be considered "notable" on the other hand, you don't want it to be marked as a "reads like a marketing page" due to the same information.

Here is a list of notable graph databases:

You can see that I've included a JanusGraph logo image into the page. I don't know who is the author of that logo. If you know, please correct this information here (right now the author is JanusGraph):

The copyright holder of the logos is Expero, Inc. (I don't actually know which graphics designer(s) at Expero did the work), who were gracious to provide the logos to the JanusGraph project under the CC-BY-4.0 license; you can find all the images here: https://github.com/janusgraph/logos

If you see any mistakes or would like to improve / add some information it would be great. 

Please, follow Wikipedia policy when editing the article so that the article review would not be rejected.

Best regards
Alexandr Porunov

--
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 janusgraph-de...@googlegroups.com.
To post to this group, send email to janusgr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/eca1d8cc-0295-495f-bc5d-5f99977b3cfe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Creating a Wikipedia page for JanusGraph

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

On Thu, Sep 20, 2018 at 4:07 AM, Alexandr Porunov <alexand...@...> wrote:
I think it worth to create a Wikipedia page for JanusGraph and then add it into the list of notable graph databases.

Here is a draft page:

Is it worth mentioning some examples of software powered by JanusGraph:
or customers using JanusGraph in production:

What do you think? Also, what does Wikipedia think / require by policy? On the one hand, adding these will help improve the chances it'll be considered "notable" on the other hand, you don't want it to be marked as a "reads like a marketing page" due to the same information.

Here is a list of notable graph databases:

You can see that I've included a JanusGraph logo image into the page. I don't know who is the author of that logo. If you know, please correct this information here (right now the author is JanusGraph):

The copyright holder of the logos is Expero, Inc. (I don't actually know which graphics designer(s) at Expero did the work), who were gracious to provide the logos to the JanusGraph project under the CC-BY-4.0 license; you can find all the images here: https://github.com/janusgraph/logos

If you see any mistakes or would like to improve / add some information it would be great. 

Please, follow Wikipedia policy when editing the article so that the article review would not be rejected.

Best regards
Alexandr Porunov

--
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 janusgraph-dev+unsubscribe@googlegroups.com.
To post to this group, send email to janusgraph-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/eca1d8cc-0295-495f-bc5d-5f99977b3cfe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[DISCUSS] JanusGraph 0.2.2 and 0.3.1 releases

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

A couple months ago, I set a rough target date for September 15 for these milestones in an effort to move towards more frequent releases. These would both be maintenance fix releases -- meaning no major changes in dependencies, no changes to the storage format, and zero/minimal upgrade steps required.

The PR queues (0.2.2 and 0.3.1) have been getting cleared, so I'd propose wrapping up these releases by closing out (or moving to the next milestone) any remaining PRs this week. I'll volunteer to be the release manager and spin up the release artifacts on Monday for vote. I'll assume lazy consensus for this, but please reply on this thread with any questions or concerns.

I'd target the next set of releases for November 15, and I'd expect these to have incremental bumps for TinkerPop.


Re: Improve JanusGraph main page

Alexandr Porunov <alexand...@...>
 

Hi Misha,

Awesome! Thanks for your work on these issues. I will add some comments on github.

Best regards,
Alexandr Porunov


On Thursday, September 20, 2018 at 12:04:16 PM UTC+3, Alexandr Porunov wrote:
As for me the main page of any product is important to make a good first impression. When I open the main page of JanusGraph it looks like the site was constructed in the 90s (sorry for criticism). I understand that the style was taken from TitanDB (http://titan.thinkaurelius.com) but I think it should be changed.

Another concern is that the main page uses http protocol still. I do understand that there is nothing to secure on the main page but I believe that https protocol will make a better impression. Notice that docs.janusgraph.org is using https protocol (Letsencrypt certificate). I believe it isn't hard to add an additional SSL certificate for the main page. Also, Letsencrypt supports wildcard certificates, it is possible to make a certificate for the entire *.janusgraph.org domain to cover all subdomains and use the same certificate on the main page and in the docs.

Best regards,
Alexandr Porunov


Re: Improve JanusGraph main page

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

Hi Alexandr,

Excellent points!

On Thu, Sep 20, 2018 at 5:04 AM, Alexandr Porunov <alexand...@...> wrote:
As for me the main page of any product is important to make a good first impression. When I open the main page of JanusGraph it looks like the site was constructed in the 90s (sorry for criticism). I understand that the style was taken from TitanDB (http://titan.thinkaurelius.com) but I think it should be changed.

Agreed (I've also gotten this feedback separately); I have a draft in-progress here: https://mbrukman.github.io/janusgraph.org/ and this is being tracked via https://github.com/JanusGraph/janusgraph.org/issues/52
 
Another concern is that the main page uses http protocol still. I do understand that there is nothing to secure on the main page but I believe that https protocol will make a better impression. Notice that docs.janusgraph.org is using https protocol (Letsencrypt certificate). I believe it isn't hard to add an additional SSL certificate for the main page. Also, Letsencrypt supports wildcard certificates, it is possible to make a certificate for the entire *.janusgraph.org domain to cover all subdomains and use the same certificate on the main page and in the docs.

Agreed as well on this point, but ince The Linux Foundation manages the domains and owns the DNS configuration for janusgraph.org, they need to update a certain part of config to enable GitHub to get us an SSL certificate via Let's Encrypt. I've reached out to my contact at The Linux Foundation to make this change but am still waiting to hear back. I'll follow-up on that.

Best,
Misha 


Improve JanusGraph main page

Alexandr Porunov <alexand...@...>
 

As for me the main page of any product is important to make a good first impression. When I open the main page of JanusGraph it looks like the site was constructed in the 90s (sorry for criticism). I understand that the style was taken from TitanDB (http://titan.thinkaurelius.com) but I think it should be changed.

Another concern is that the main page uses http protocol still. I do understand that there is nothing to secure on the main page but I believe that https protocol will make a better impression. Notice that docs.janusgraph.org is using https protocol (Letsencrypt certificate). I believe it isn't hard to add an additional SSL certificate for the main page. Also, Letsencrypt supports wildcard certificates, it is possible to make a certificate for the entire *.janusgraph.org domain to cover all subdomains and use the same certificate on the main page and in the docs.

Best regards,
Alexandr Porunov


Creating a Wikipedia page for JanusGraph

Alexandr Porunov <alexand...@...>
 

I think it worth to create a Wikipedia page for JanusGraph and then add it into the list of notable graph databases.

Here is a draft page:
https://en.wikipedia.org/wiki/Draft:JanusGraph

Here is a list of notable graph databases:
https://en.wikipedia.org/wiki/Graph_database#List_of_graph_databases

You can see that I've included a JanusGraph logo image into the page. I don't know who is the author of that logo. If you know, please correct this information here (right now the author is JanusGraph):
https://en.wikipedia.org/wiki/File:JanusGraph_Logo.png

If you see any mistakes or would like to improve / add some information it would be great. 

Please, follow Wikipedia policy when editing the article so that the article review would not be rejected.

Best regards
Alexandr Porunov


Re: [DISCUSS] Pull Request review and approval policy

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

Thanks Henry. The policy has been updated already. https://github.com/JanusGraph/janusgraph/blob/master/docs/development.adoc


On Wednesday, September 12, 2018 at 2:37:07 PM UTC-4, Henry Saputra wrote:
I am +1 for the suggestions to augment with RTC plus lazy consensus

I am sorry for lag of responses for the proposal.

- Henry



On Mon, Aug 27, 2018 at 7:55 AM Jason Plurad wrote:
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 trusted to decide when a PR can be Commit-Then-Review (CTR) vs Review-Then-Commit (RTC)
  b. Include merging PRs upstream as one of the CTR scenarios
  c. GitHub will not be used to enforce the policy (disable approval reviews) because it does not allow committers to approve their own PRs

2. Our RTC policy requires either
  a. 2 approval votes from committers
  b. 1 approval vote from a committer followed by a one week review period
  c. Committers are trusted to seek 2nd approval for complex changes that require more review



On Friday, August 24, 2018 at 11:35:51 AM UTC-4, Alexandr Porunov wrote:
Will there be a new review and approval policy?
I believe it should be implemented.

+1 for all discussed above.

On Thursday, August 9, 2018 at 7:57:16 PM UTC+3, Jason Plurad wrote:
Perhaps a weekly update on the PR queue posted on the dev mailing list would be a good idea.

Something like:

# 0.2.2 queue
PR a - needs one more approval
PR b - waiting on revisions
PR c - unreviewed for 16 days
PR d - new this week


On Thursday, August 9, 2018 at 1:17:40 AM UTC-4, Jerry He wrote:
Finding the right balance between more review/more approvals and being more efficient is what we aim for.  I have been in situations in my PRs where another pair of eyes caught some error I made.  I was also in situations where my PRs sitting there for a long time waiting for reviews.

I think I am ok with adopting 2-4 from the TinkerPop process. 
But adding some extra guard (e.g an extra reminder or ping before commit) or time (more time than a week to accommodate busy professionals?)  will make it easier to relieve concerns.

Thanks,

Jerry


On Wednesday, August 8, 2018 at 1:14:06 PM UTC-7, Alexandr Porunov wrote:
I am not a committer but here are my thoughts:

1. I think it is enough to maintain 2 active branches right now. Latest release + future release (master). There is plainly no enough committers to maintain more active branches.

2. I think it is worth adding steps 2-4 because there are some PRs with huge delays.

On Wednesday, August 8, 2018 at 6:25:49 AM UTC+3, Jason Plurad wrote:
I have a couple discussion topics to bring up based on our recent history of getting releases out.

1. Based on what we have written in the docs (Chapter 44. Pull Requests), we have a commit-then-review (CTR) policy, however it does not work in practice. GitHub does not allow a committer to approve their own PRs. This makes it impossible to merge PRs without at least 1 other approval, and this has caused delays on some PRs to get merged. For example, the master branch is not yet open for business because the PR is still waiting for approval. Another situation was when we needed to merge a fix from 0.2 upstream into master. The 0.2 PR got approved and merged, but either the committer didn't open a separate PR to merge to master or the committer opened the PR to merge to master but that PR stagnated on getting approval. If we end up in a situation where we are maintaining more than 2 active branches, there would be even more friction involved getting changes merged upstream.

Based on these docs, we can disable restriction checks for repository administrators. If we still want to allow CTR, it seems like this needs to be done and all committers would need to be in a repository administrator group.


2. Currently our policy is for 2 committer approvals to merge a PR. Toward the end of the release cycle, I had gotten in the habit of performing my review approval first and then requesting reviews from the JanusGraph/committers group via GitHub. This should send a notification to all the committers in the group. I have no idea how other committers manage their GitHub notifications, but it seemed like a better approach than spamming the dev list or backchanneling individuals every time a PR needed a second review.

TinkerPop recently introduced a new approach to their PR review process:
We seem to agree that in the future we will go with the following review-the-commit (RTC) process:

1. Each change to TinkerPop release branches requires 3 +1s from committers and no -1s OR
2. A single +1 from a committer and a 1 week review period for objections (i.e. "cool down period") at which point we will assume a lazy consensus
3. The single +1 may come from the committer who submitted the PR in the first place
4. Committers are trusted with their changes but are expected to request reviews for complex changes as necessary and not rely strictly on lazy consensus
5. commit-the-review (CTR) procedures remain unchanged
By adopting bullets 2-4 from TinkerPop's process, I think it would enable us to merge changes into the codebase more efficiently. If committers were concerned about what PRs might get merged, they would need to check the PR queue at least once a week.


Thoughts?

--
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 janusgraph-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/faf9fb95-dbd3-42d0-bb24-aa66e54ad06c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] Pull Request review and approval policy

Henry Saputra <henry....@...>
 

I am +1 for the suggestions to augment with RTC plus lazy consensus

I am sorry for lag of responses for the proposal.

- Henry



On Mon, Aug 27, 2018 at 7:55 AM Jason Plurad <plu...@...> wrote:
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 trusted to decide when a PR can be Commit-Then-Review (CTR) vs Review-Then-Commit (RTC)
  b. Include merging PRs upstream as one of the CTR scenarios
  c. GitHub will not be used to enforce the policy (disable approval reviews) because it does not allow committers to approve their own PRs

2. Our RTC policy requires either
  a. 2 approval votes from committers
  b. 1 approval vote from a committer followed by a one week review period
  c. Committers are trusted to seek 2nd approval for complex changes that require more review



On Friday, August 24, 2018 at 11:35:51 AM UTC-4, Alexandr Porunov wrote:
Will there be a new review and approval policy?
I believe it should be implemented.

+1 for all discussed above.

On Thursday, August 9, 2018 at 7:57:16 PM UTC+3, Jason Plurad wrote:
Perhaps a weekly update on the PR queue posted on the dev mailing list would be a good idea.

Something like:

# 0.2.2 queue
PR a - needs one more approval
PR b - waiting on revisions
PR c - unreviewed for 16 days
PR d - new this week


On Thursday, August 9, 2018 at 1:17:40 AM UTC-4, Jerry He wrote:
Finding the right balance between more review/more approvals and being more efficient is what we aim for.  I have been in situations in my PRs where another pair of eyes caught some error I made.  I was also in situations where my PRs sitting there for a long time waiting for reviews.

I think I am ok with adopting 2-4 from the TinkerPop process. 
But adding some extra guard (e.g an extra reminder or ping before commit) or time (more time than a week to accommodate busy professionals?)  will make it easier to relieve concerns.

Thanks,

Jerry


On Wednesday, August 8, 2018 at 1:14:06 PM UTC-7, Alexandr Porunov wrote:
I am not a committer but here are my thoughts:

1. I think it is enough to maintain 2 active branches right now. Latest release + future release (master). There is plainly no enough committers to maintain more active branches.

2. I think it is worth adding steps 2-4 because there are some PRs with huge delays.

On Wednesday, August 8, 2018 at 6:25:49 AM UTC+3, Jason Plurad wrote:
I have a couple discussion topics to bring up based on our recent history of getting releases out.

1. Based on what we have written in the docs (Chapter 44. Pull Requests), we have a commit-then-review (CTR) policy, however it does not work in practice. GitHub does not allow a committer to approve their own PRs. This makes it impossible to merge PRs without at least 1 other approval, and this has caused delays on some PRs to get merged. For example, the master branch is not yet open for business because the PR is still waiting for approval. Another situation was when we needed to merge a fix from 0.2 upstream into master. The 0.2 PR got approved and merged, but either the committer didn't open a separate PR to merge to master or the committer opened the PR to merge to master but that PR stagnated on getting approval. If we end up in a situation where we are maintaining more than 2 active branches, there would be even more friction involved getting changes merged upstream.

Based on these docs, we can disable restriction checks for repository administrators. If we still want to allow CTR, it seems like this needs to be done and all committers would need to be in a repository administrator group.


2. Currently our policy is for 2 committer approvals to merge a PR. Toward the end of the release cycle, I had gotten in the habit of performing my review approval first and then requesting reviews from the JanusGraph/committers group via GitHub. This should send a notification to all the committers in the group. I have no idea how other committers manage their GitHub notifications, but it seemed like a better approach than spamming the dev list or backchanneling individuals every time a PR needed a second review.

TinkerPop recently introduced a new approach to their PR review process:
We seem to agree that in the future we will go with the following review-the-commit (RTC) process:

1. Each change to TinkerPop release branches requires 3 +1s from committers and no -1s OR
2. A single +1 from a committer and a 1 week review period for objections (i.e. "cool down period") at which point we will assume a lazy consensus
3. The single +1 may come from the committer who submitted the PR in the first place
4. Committers are trusted with their changes but are expected to request reviews for complex changes as necessary and not rely strictly on lazy consensus
5. commit-the-review (CTR) procedures remain unchanged
By adopting bullets 2-4 from TinkerPop's process, I think it would enable us to merge changes into the codebase more efficiently. If committers were concerned about what PRs might get merged, they would need to check the PR queue at least once a week.


Thoughts?

--
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/faf9fb95-dbd3-42d0-bb24-aa66e54ad06c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: What's the relationship between JanusGraph and Gremlin?

Chris Hupman <chris...@...>
 

JanusGraph was built to use the TinkerPop APIs.

For storage backends if you think that TinkerPop has an abstract class with an in-memory graph JanusGraph adds more storage backends that extend that abstract class for HBase, Cassandra, etc. 

You can use a github search to see where tinkerpop classes are imported and used, which will also show you TinkerPop integration classes.  You might also want to look at the tinkerpop folder under graphdb in janusgraph-core if you want to connect the dots. 


On Monday, September 10, 2018 at 7:37:59 PM UTC-7, Raul Guo wrote:
Hi Chris,
Thank you very much for your reply. I am trying to join in the development of janusgraph, so I tried to understand the code architecture of janus. But I am confused about the what janusgraph did based on Tinkerpop and gremlin. It seems that janusgraph do with the storage backend, but the tinkerpop knows nothing about the storage, so how did janusgraph execute a query when the core engine(tinkerpop) knows nothing about the storage? I cannot understand the query process, so I hope the developers can help me on this, thanks.


在 2018年9月11日星期二 UTC+8上午9:36:38,Chris Hupman写道:
Hi Raul,

This is more of a question for the JanusGraph users google group. That being said, here are some links that help explain the relationship. 



Also here's a free book by Kelvin Lawrence on gremlin that also covers JanusGraph

On Monday, September 10, 2018 at 2:19:42 AM UTC-7, Raul Guo wrote:
I am a little confused about the relationship between JanusGraph and gremlin, the storage backend(HBase, Cassandra, .etc) is configured by JanusGraph, but and the core traversal strategy(GraphTraversal, GraphTraversalSource, .etc) are defined in gremlin, so how did janusgraph interact with the storage backend now that its core calculate engine(which is gremlin) knows nothing about the storage at all? Can you help me to know about what gremlin did in janusgraph, and what janusgraph did based on gremlin? Thanks in advance.


Re: What's the relationship between JanusGraph and Gremlin?

Raul Guo <zaixiagu...@...>
 

Hi Chris,
Thank you very much for your reply. I am trying to join in the development of janusgraph, so I tried to understand the code architecture of janus. But I am confused about the what janusgraph did based on Tinkerpop and gremlin. It seems that janusgraph do with the storage backend, but the tinkerpop knows nothing about the storage, so how did janusgraph execute a query when the core engine(tinkerpop) knows nothing about the storage? I cannot understand the query process, so I hope the developers can help me on this, thanks.


在 2018年9月11日星期二 UTC+8上午9:36:38,Chris Hupman写道:

Hi Raul,

This is more of a question for the JanusGraph users google group. That being said, here are some links that help explain the relationship. 



Also here's a free book by Kelvin Lawrence on gremlin that also covers JanusGraph

On Monday, September 10, 2018 at 2:19:42 AM UTC-7, Raul Guo wrote:
I am a little confused about the relationship between JanusGraph and gremlin, the storage backend(HBase, Cassandra, .etc) is configured by JanusGraph, but and the core traversal strategy(GraphTraversal, GraphTraversalSource, .etc) are defined in gremlin, so how did janusgraph interact with the storage backend now that its core calculate engine(which is gremlin) knows nothing about the storage at all? Can you help me to know about what gremlin did in janusgraph, and what janusgraph did based on gremlin? Thanks in advance.


Re: What's the relationship between JanusGraph and Gremlin?

Chris Hupman <chris...@...>
 

Hi Raul,

This is more of a question for the JanusGraph users google group. That being said, here are some links that help explain the relationship. 




On Monday, September 10, 2018 at 2:19:42 AM UTC-7, Raul Guo wrote:
I am a little confused about the relationship between JanusGraph and gremlin, the storage backend(HBase, Cassandra, .etc) is configured by JanusGraph, but and the core traversal strategy(GraphTraversal, GraphTraversalSource, .etc) are defined in gremlin, so how did janusgraph interact with the storage backend now that its core calculate engine(which is gremlin) knows nothing about the storage at all? Can you help me to know about what gremlin did in janusgraph, and what janusgraph did based on gremlin? Thanks in advance.


What's the relationship between JanusGraph and Gremlin?

Raul Guo <zaixiagu...@...>
 

I am a little confused about the relationship between JanusGraph and gremlin, the storage backend(HBase, Cassandra, .etc) is configured by JanusGraph, but and the core traversal strategy(GraphTraversal, GraphTraversalSource, .etc) are defined in gremlin, so how did janusgraph interact with the storage backend now that its core calculate engine(which is gremlin) knows nothing about the storage at all? Can you help me to know about what gremlin did in janusgraph, and what janusgraph did based on gremlin? Thanks in advance.


Where should I begin to understand the code?

郭震 <zaixiagu...@...>
 

Hi developers:
I am a newbie to the group, I have used JanusGraph for a period and now I want one step further to take part in the development of janus graph. I have wathed the source code for a few days but still confused by so many classes and interfaces. I am trying to understand how it execute gremlin query and add vertex or edge to HBase, but there are some classes that have little comment, which make it hard to find the clues to go on. Is there any project module architecture info or important code illustration that can help me to find the clues? Thanks for any help.


Re: [REPORT] Open Pull Requests 2018-09-04

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

No, not at the moment, but it really isn't that difficult to pull together.
Bringing attention to the PRs that need reviews is a much higher priority than automating this report.


On Tuesday, September 4, 2018 at 10:24:22 PM UTC-4, Chris Hupman wrote:
Please tell me compiling this is at least partially automated.

On Tuesday, September 4, 2018 at 11:58:05 AM UTC-7, Jason Plurad wrote:

Open Pull Requests 2018-09-04

This report contains a summary of the open pull requests in the JanusGraph project ecosystem. Everybody interested is encouraged to submit review comments and approvals, but only approvals from committers are considered binding for merge. Please refer to the pull request policy for details.


janusgraph


Release 0.2.2 (2 open)


PR-1118 Issue #1114: fix GremlinServer StackOverflowError

  • Opened 2018-06-14 (3 months ago) by boliza
  • Comments from chupman, sjudeng, pluradj
    • Missing unit test case
  • 0 approvals

PR-1237 Issue #1157: fix REINDEX delay on the newly created index in empty DB

  • Opened 2018-08-29 (6 days ago) by dengziming (First-time contributor)
  • 0 comments
  • 0 approvals

Release 0.3.1 (4 open)


PR-929 Bug Fix (issue #764) & LIST and SET support for Lucene (issue #670)

  • Opened 2018-02-13 (7 months ago) by Lakedaemon
  • 43 comments: analytically, davidclement90, pluradj, sjudeng, twilmes
  • 1 approval: analytically

PR-1152 Add projects built with JanusGraph

  • Opened 2018-07-07 (2 months ago) by mbrukman
  • 5 comments: amcp, hsaputra, jerryjch, pluradj
  • 1 approval: mbrukman

PR-1214 Create a HBase 2 profile #1213

  • Opened 2018-08-08 (26 days ago) by jerryjch
  • 6 comments: analytically, hsaputra
  • 1 approval: jerryjch

PR-1230 Add support for kerberized solr instance (#1138)

  • Opened 2018-08-23 (12 days ago) by blindenvy (First-time contributor)
  • 5 comments: jerryjch
  • 0 approvals

Release 0.4.0 (0 open)


0 pull requests


No Milestone (10 open)


10 pull requests


janusgraph-ambari (1 open)


PR-2 Plugin copied over from chupman/janusgraph-ambari-service

  • Opened 2018-08-27 (8 days ago) by chupman
  • 12 comments: pluradj
  • 1 approval: chupman

janusgraph-docker (1 open)


PR-1 [IN PROGRESS] Creating docker image build for JanusGraph 0.2.0

  • Opened 2018-08-30 (5 days ago) by twilmes
  • 24 comments: chrislbs, FlorianHockmann, sjudeng
  • 0 approvals

janusgraph-dotnet (1 open)


PR-1 Initial version of JanusGraph.Net

  • Opened 2018-08-16 (19 days ago) by FlorianHockmann
  • 33 comments: mbrukman, pluradj
  • 1 approval: FlorianHockmann

janusgraph-python (1 open)


PR-4 Initial version of JanusGraph Python client drivers

  • Opened 2018-09-04 (today) by debasishdebs
  • 0 comments
  • 0 approvals


Re: [REPORT] Open Pull Requests 2018-09-04

Chris Hupman <chris...@...>
 

Please tell me compiling this is at least partially automated.


On Tuesday, September 4, 2018 at 11:58:05 AM UTC-7, Jason Plurad wrote:

Open Pull Requests 2018-09-04

This report contains a summary of the open pull requests in the JanusGraph project ecosystem. Everybody interested is encouraged to submit review comments and approvals, but only approvals from committers are considered binding for merge. Please refer to the pull request policy for details.


janusgraph


Release 0.2.2 (2 open)


PR-1118 Issue #1114: fix GremlinServer StackOverflowError

  • Opened 2018-06-14 (3 months ago) by boliza
  • Comments from chupman, sjudeng, pluradj
    • Missing unit test case
  • 0 approvals

PR-1237 Issue #1157: fix REINDEX delay on the newly created index in empty DB

  • Opened 2018-08-29 (6 days ago) by dengziming (First-time contributor)
  • 0 comments
  • 0 approvals

Release 0.3.1 (4 open)


PR-929 Bug Fix (issue #764) & LIST and SET support for Lucene (issue #670)

  • Opened 2018-02-13 (7 months ago) by Lakedaemon
  • 43 comments: analytically, davidclement90, pluradj, sjudeng, twilmes
  • 1 approval: analytically

PR-1152 Add projects built with JanusGraph

  • Opened 2018-07-07 (2 months ago) by mbrukman
  • 5 comments: amcp, hsaputra, jerryjch, pluradj
  • 1 approval: mbrukman

PR-1214 Create a HBase 2 profile #1213

  • Opened 2018-08-08 (26 days ago) by jerryjch
  • 6 comments: analytically, hsaputra
  • 1 approval: jerryjch

PR-1230 Add support for kerberized solr instance (#1138)

  • Opened 2018-08-23 (12 days ago) by blindenvy (First-time contributor)
  • 5 comments: jerryjch
  • 0 approvals

Release 0.4.0 (0 open)


0 pull requests


No Milestone (10 open)


10 pull requests


janusgraph-ambari (1 open)


PR-2 Plugin copied over from chupman/janusgraph-ambari-service

  • Opened 2018-08-27 (8 days ago) by chupman
  • 12 comments: pluradj
  • 1 approval: chupman

janusgraph-docker (1 open)


PR-1 [IN PROGRESS] Creating docker image build for JanusGraph 0.2.0

  • Opened 2018-08-30 (5 days ago) by twilmes
  • 24 comments: chrislbs, FlorianHockmann, sjudeng
  • 0 approvals

janusgraph-dotnet (1 open)


PR-1 Initial version of JanusGraph.Net

  • Opened 2018-08-16 (19 days ago) by FlorianHockmann
  • 33 comments: mbrukman, pluradj
  • 1 approval: FlorianHockmann

janusgraph-python (1 open)


PR-4 Initial version of JanusGraph Python client drivers

  • Opened 2018-09-04 (today) by debasishdebs
  • 0 comments
  • 0 approvals


[REPORT] Open Pull Requests 2018-09-04

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

Open Pull Requests 2018-09-04

This report contains a summary of the open pull requests in the JanusGraph project ecosystem. Everybody interested is encouraged to submit review comments and approvals, but only approvals from committers are considered binding for merge. Please refer to the pull request policy for details.


janusgraph


Release 0.2.2 (2 open)


PR-1118 Issue #1114: fix GremlinServer StackOverflowError

  • Opened 2018-06-14 (3 months ago) by boliza
  • Comments from chupman, sjudeng, pluradj
    • Missing unit test case
  • 0 approvals

PR-1237 Issue #1157: fix REINDEX delay on the newly created index in empty DB

  • Opened 2018-08-29 (6 days ago) by dengziming (First-time contributor)
  • 0 comments
  • 0 approvals

Release 0.3.1 (4 open)


PR-929 Bug Fix (issue #764) & LIST and SET support for Lucene (issue #670)

  • Opened 2018-02-13 (7 months ago) by Lakedaemon
  • 43 comments: analytically, davidclement90, pluradj, sjudeng, twilmes
  • 1 approval: analytically

PR-1152 Add projects built with JanusGraph

  • Opened 2018-07-07 (2 months ago) by mbrukman
  • 5 comments: amcp, hsaputra, jerryjch, pluradj
  • 1 approval: mbrukman

PR-1214 Create a HBase 2 profile #1213

  • Opened 2018-08-08 (26 days ago) by jerryjch
  • 6 comments: analytically, hsaputra
  • 1 approval: jerryjch

PR-1230 Add support for kerberized solr instance (#1138)

  • Opened 2018-08-23 (12 days ago) by blindenvy (First-time contributor)
  • 5 comments: jerryjch
  • 0 approvals

Release 0.4.0 (0 open)


0 pull requests


No Milestone (10 open)


10 pull requests


janusgraph-ambari (1 open)


PR-2 Plugin copied over from chupman/janusgraph-ambari-service

  • Opened 2018-08-27 (8 days ago) by chupman
  • 12 comments: pluradj
  • 1 approval: chupman

janusgraph-docker (1 open)


PR-1 [IN PROGRESS] Creating docker image build for JanusGraph 0.2.0

  • Opened 2018-08-30 (5 days ago) by twilmes
  • 24 comments: chrislbs, FlorianHockmann, sjudeng
  • 0 approvals

janusgraph-dotnet (1 open)


PR-1 Initial version of JanusGraph.Net

  • Opened 2018-08-16 (19 days ago) by FlorianHockmann
  • 33 comments: mbrukman, pluradj
  • 1 approval: FlorianHockmann

janusgraph-python (1 open)


PR-4 Initial version of JanusGraph Python client drivers

  • Opened 2018-09-04 (today) by debasishdebs
  • 0 comments
  • 0 approvals


Re: TinkerPop 3.2 vs TinkerPop 3.3 Serialization difference for Predicate class

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

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 release. The JanusGraph policy has been for new features to go into the master branch only. If there are products out there in production on JanusGraph 0.2, they aren't using GLVs or are using the plain TinkerPop GLVs and decided that was good enough.

The new dotnet and python drivers are separate from the main repository, so it is possible that they could have a different approach to what JanusGraph releases they want to support. However, I'd suggest that we need to continue sticking with primarily supporting the latest release, especially since GLVs are still a relatively new idea in TinkerPop. Managing the dependency differences between the TinkerPop versions is not worth the extra effort, especially considering that TinkerPop 3.4 is on the horizon.

We haven't been assigning reviewers to specific PRs. As a primarily volunteer community, we rely on committers going to the queue and reviewing what is out there. We discussed the idea of the PR queue email to the mailing list previously, and I will get that started this week. It is especially important now that the PRs are spread across several repositories.

I created issue 1243 to update the docs on the PR workflow.


On Tuesday, September 4, 2018 at 4:52:49 AM UTC-4, Florian Hockmann wrote:
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 and small improvements.
Users should upgrade to 0.3.0 in my opinion when they want to use new features like JanusGraph predicates in languages like Python and C#.

Also I'll need a small walkthrough on what things need to be done for the same.

I'm actually not sure about the workflow myself. Usually, PRs are merged into a feature branch and then from there up into master and not the other way around. One solution is probably to simply cherry-pick the commit. Can someone else shed some light on this?

I was unable to add You, Jason, or Misha to reviewers. Maybe because I'm not committer?

Yes, commit permissions are necessary to add reviewers as far as I know. But I will try to find some time to review this.

Am Sonntag, 2. September 2018 11:41:34 UTC+2 schrieb Debasish Kanhar:
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 asking is because I feel a lot of users still haven't migrated to 0.3 series of JanusGraph, meaning that the drivers will still remain far from being usable. I did see your code changes in the PR, and they seem like few changes, which can be implemented. But wanted to know what are plans for merging it to 0.2 branch, and if no one else is working, I can take that up. Also I'll need a small walkthrough on what things need to be done for the same.

Also, I've create a PR #2 to push initial version of library to official repo. I was unable to add You, Jason, or Misha to reviewers. Maybe because I'm not committer? Can you check that out. We will need your comments to push that out.

On Monday, 27 August 2018 19:17:26 UTC+5:30, Florian Hockmann wrote:
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 0.2 branch and is therefore not present in version 0.2.1.

That is also why I decided to only support JanusGraph 0.3.0 with JanusGraph.Net.

Am Freitag, 24. August 2018 18:46:25 UTC+2 schrieb Debasish Kanhar:
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: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
 
- { className: org.apache.tinkerpop.gremlin.driver.ser.GryoLiteMessageSerializerV1d0, config: {ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
 
- { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1d0, config: { serializeResultToString: true }}
 
- { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistryV1d0] }}
 
- { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV2d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
 
- { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistryV1d0] }}




On Friday, 24 August 2018 22:10:52 UTC+5:30, Debasish Kanhar wrote:
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 same set of driver for JanusGraph 0.2.1 which used TP 3.2.9 but I feel I've hit a bump with respect to Serialization for Predicate class.

So, my existent features like Adding of GeoShapes, Querying GeoShape and RelationIdentifier serialization/deserialization works. But any of my features leveraging TinkerPop's Predicate (PSerializer) doesn't work. I feel like this is some sort of serialization issue.

So, when I've implemented TextContainsFuzzy, which was working against JG 0.3.0/TP 3.3.3 (Using GraphSON 3.0) but the same doesn't work on GraphSON 2.0.

The following is my serialized object being sent to Gremlin-Server (Gremlin-server logs specify this)

Using TextFuzzy:
Error message:

org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV2d0  - Request [PooledUnsafeDirectByteBuf(ridx: 303, widx: 303, cap: 337)] could not be deserialized by org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV2d0.
org
.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could not deserialize the JSON value as required. Nested exception: org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could not deserialize the JSON value as required. Nested exception: java.lang.IllegalStateException: org.apache.tinkerpop.gremlin.process.traversal.P.textContainsFuzzy([Ljava.lang.Object;)

And the serialized object being sent:

{
 
"requestId": {
   
"@type": "g:UUID",
   
"@value": "7328b342-2ed3-43a5-b589-f6688b264ee7"
 
},
 
"processor": "traversal",
 
"op": "bytecode",
 
"args": {
   
"gremlin": {
     
"@type": "g:Bytecode",
     
"@value": {
       
"step": [
         
[
           
"V"
         
],
         
[
           
"has",
           
"name",
           
{
             
"@type": "g:P",
             
"@value": {
               
"predicate": "textContainsFuzzy",
               
"value": "herculeas"
             
}
           
}
         
]
       
]
     
}
   
},
   
"aliases": {
     
"g": "gg"
   
}
 
}
}

The serialized object really looks good, like the way it is expected. Doesn't it? Or else I cant seem to dechiper what's wrong.

I'm also facing similar errors which using the same PSerializer class for extending Geo Predicates like geoWithin, but I guess both are tied to same problem, and if one gets solved, other will also :-)

If needed, I can attach the serialized object for geoWithin too. But any help in debugging this will be really helpful, as this is last piece of development I'm expecting before releasing version 1 of drivers with support for both GraphSON 2.0 and GraphSON 3.0

Thanks.


Re: TinkerPop 3.2 vs TinkerPop 3.3 Serialization difference for Predicate class

Florian Hockmann <f...@...>
 

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 and small improvements.
Users should upgrade to 0.3.0 in my opinion when they want to use new features like JanusGraph predicates in languages like Python and C#.

Also I'll need a small walkthrough on what things need to be done for the same.

I'm actually not sure about the workflow myself. Usually, PRs are merged into a feature branch and then from there up into master and not the other way around. One solution is probably to simply cherry-pick the commit. Can someone else shed some light on this?

I was unable to add You, Jason, or Misha to reviewers. Maybe because I'm not committer?

Yes, commit permissions are necessary to add reviewers as far as I know. But I will try to find some time to review this.

Am Sonntag, 2. September 2018 11:41:34 UTC+2 schrieb Debasish Kanhar:
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 asking is because I feel a lot of users still haven't migrated to 0.3 series of JanusGraph, meaning that the drivers will still remain far from being usable. I did see your code changes in the PR, and they seem like few changes, which can be implemented. But wanted to know what are plans for merging it to 0.2 branch, and if no one else is working, I can take that up. Also I'll need a small walkthrough on what things need to be done for the same.

Also, I've create a PR #2 to push initial version of library to official repo. I was unable to add You, Jason, or Misha to reviewers. Maybe because I'm not committer? Can you check that out. We will need your comments to push that out.

On Monday, 27 August 2018 19:17:26 UTC+5:30, Florian Hockmann wrote:
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 0.2 branch and is therefore not present in version 0.2.1.

That is also why I decided to only support JanusGraph 0.3.0 with JanusGraph.Net.

Am Freitag, 24. August 2018 18:46:25 UTC+2 schrieb Debasish Kanhar:
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: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
 
- { className: org.apache.tinkerpop.gremlin.driver.ser.GryoLiteMessageSerializerV1d0, config: {ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
 
- { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1d0, config: { serializeResultToString: true }}
 
- { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistryV1d0] }}
 
- { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV2d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
 
- { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistryV1d0] }}




On Friday, 24 August 2018 22:10:52 UTC+5:30, Debasish Kanhar wrote:
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 same set of driver for JanusGraph 0.2.1 which used TP 3.2.9 but I feel I've hit a bump with respect to Serialization for Predicate class.

So, my existent features like Adding of GeoShapes, Querying GeoShape and RelationIdentifier serialization/deserialization works. But any of my features leveraging TinkerPop's Predicate (PSerializer) doesn't work. I feel like this is some sort of serialization issue.

So, when I've implemented TextContainsFuzzy, which was working against JG 0.3.0/TP 3.3.3 (Using GraphSON 3.0) but the same doesn't work on GraphSON 2.0.

The following is my serialized object being sent to Gremlin-Server (Gremlin-server logs specify this)

Using TextFuzzy:
Error message:

org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV2d0  - Request [PooledUnsafeDirectByteBuf(ridx: 303, widx: 303, cap: 337)] could not be deserialized by org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV2d0.
org
.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could not deserialize the JSON value as required. Nested exception: org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could not deserialize the JSON value as required. Nested exception: java.lang.IllegalStateException: org.apache.tinkerpop.gremlin.process.traversal.P.textContainsFuzzy([Ljava.lang.Object;)

And the serialized object being sent:

{
 
"requestId": {
   
"@type": "g:UUID",
   
"@value": "7328b342-2ed3-43a5-b589-f6688b264ee7"
 
},
 
"processor": "traversal",
 
"op": "bytecode",
 
"args": {
   
"gremlin": {
     
"@type": "g:Bytecode",
     
"@value": {
       
"step": [
         
[
           
"V"
         
],
         
[
           
"has",
           
"name",
           
{
             
"@type": "g:P",
             
"@value": {
               
"predicate": "textContainsFuzzy",
               
"value": "herculeas"
             
}
           
}
         
]
       
]
     
}
   
},
   
"aliases": {
     
"g": "gg"
   
}
 
}
}

The serialized object really looks good, like the way it is expected. Doesn't it? Or else I cant seem to dechiper what's wrong.

I'm also facing similar errors which using the same PSerializer class for extending Geo Predicates like geoWithin, but I guess both are tied to same problem, and if one gets solved, other will also :-)

If needed, I can attach the serialized object for geoWithin too. But any help in debugging this will be really helpful, as this is last piece of development I'm expecting before releasing version 1 of drivers with support for both GraphSON 2.0 and GraphSON 3.0

Thanks.


Re: [PROPOSAL] new repository for .NET driver

Debasish Kanhar <d.k...@...>
 

@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 need your inputs regarding copyright statements, liscence texts and other legal/similar formalities as well as other comments.

Also, had a query regarding status of merging fix #1060 into 0.2 stream of branched for JanusGraph, and if needed, I can work on it as that is currently only merged into master and 0.3. The discussion here will need your comments too :-)

Thanks.

On Wednesday, 15 August 2018 04:15:27 UTC+5:30, Jason Plurad wrote:
Apologies for the delay, but I've created

* https://github.com/JanusGraph/janusgraph-dotnet
* https://github.com/JanusGraph/janusgraph-python

Committers and maintainers should have access to it.


On Sunday, August 5, 2018 at 9:25:48 AM UTC-4, Florian Hockmann wrote:
Looks like we have reached consensus here. I have already created a stand-alone version of the library in its own repo:


I can create a PR to transfer it to JanusGraph as soon as we have a repo ready to target the PR against.

Am Dienstag, 31. Juli 2018 20:47:11 UTC+2 schrieb Misha Brukman:
+1

Makes sense that client libraries should be in a separate repo than the server:
  • enables a separate release cadence
  • allows for a different set of maintainers, even in the same org
  • each client library will be written in a different language
Having said that, this means that we'll have to keep track of version compatibilities between client library versions + server versions. Hopefully, they will be mostly backwards-compatible until a major version change.

On Sat, Jul 28, 2018 at 11:06 AM, Jason Plurad <p...@...> wrote:
Florian Hockmann is ready to contribute a .NET driver for JanusGraph. The pull request is currently found  in the main janusgraph repo.

The driver extends the TinkerPop .NET driver with additional capability for JanusGraph types and predicates. In a previous dev list discussion thread, he and I discussed making a separate repository for this body of work. I propose the name janusgraph-dotnet for the repository.

Let's give it 72 hours for lazy consensus.

I'm +1 for this. Looking forward to getting better driver support as part of the broader project.

--
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 janusgraph-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/91f5a3bc-a220-45ff-a466-57c198f43506%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

801 - 820 of 1597