Re: [ANNOUNCE ] Apache Rya - the newest Top-Level Project at ASF

[Josh Elser]

Let me send a heart-felt congratulations to the community. Moving a 
software project through the ASF Incubator is no small feat.


You should all be extremely proud of what you have accomplished here, 
and remain ever-focused on growing and expanding the Rya community.


Well done. Go celebrate :)

On 9/24/19 11:21 AM, Adina Crainiceanu wrote:

[this announcement is available online at https://s.apache.org/0xc4g ]

The Apache Software Foundation Announces Apache® Rya™ as a Top-Level Project

Scalable Open Source Big Data database processes queries in milliseconds;
used in autonomous drones, federated situation-aware access control
systems, and petabyte-scale graphs modeling, among many other applications.

Wakefield, MA —24 September 2019— The Apache Software Foundation (ASF), the
all-volunteer developers, stewards, and incubators of more than 350 Open
Source projects and initiatives, announced today Apache® Rya™ as a
Top-Level Project (TLP).

Apache Rya (pronounced "ree-uh") is a Cloud-based Big Data triple store
(subject-predicate-object) database used to process queries in
milliseconds. The project was originally developed at the Laboratory for
Telecommunication Sciences, and was submitted to the Apache Incubator in
September 2015.

"We are very excited to reach this important milestone showing the maturity
of the project and of the community around it," said Dr. Adina Crainiceanu,
Vice President of Apache Rya and Associate Professor of Computer Science at
the U.S. Naval Academy. "RDF (Resource Description Framework) triple data
format is simple and flexible, making it easy to express diverse datasets
such as connections between users on social media, financial data and
transactions, medical data, and many others. Rya provides a scalable
solution to store and query such data. The publication of the first
research article about Rya garnered interest from industry, academia, and
several government agencies. Bringing the project to ASF allowed
collaboration and increased pace of development."

With its ability to store billions of linked information sets and return
answers to most computer-based questions in under a second, Rya's scalable
RDF data management system is built on top of Apache Accumulo® to support
SPARQL queries for RDF data. A MongoDB back-end is also implemented. Rya
uses novel storage methods, indexing schemes, and query processing
techniques that scale to billions of triples across multiple nodes.

Rya is in use at organizations such as Enlighten IT Consulting, Modus
Operandi, Parsons Corporation, Semantic Arts, Semantic Web Company, Sierra
Nevada Corporation, and U.S. Department of Defense agencies. Apache Rya is
recognized as one of the most advanced database projects in the United
States Department of the Navy, powering a new generation of drones,
advanced tactical communications through manned-unmanned teaming, and
supporting autonomous swarms of smaller robots, among numerous other
applications. In addition, Apache Rya is being used for artificial
intelligence projects involving semi-autonomous content production
operations.

"I would like to thank our mentors for their guidance and recognize the
Apache Rya founders for making their project available for all to use and
further extend," said Jennifer Brown, Project Manager for Semantic
Technologies at Parsons Corporation, and member of the Apache Rya Project
Management Committee. "In 2012 the founders introduced an RDF store backed
by Apache Accumulo that was capable of basic inferencing, scaling to
billions of triples, and providing millisecond query times. Our Semantic
Technologies team at Parsons Corporation has enjoyed the opportunity to
collaborate with the Apache Rya community to contribute new indexing
strategies, query planner optimizations, additional inference capabilities,
alerting extensions, native support for popular graph processing
frameworks, and more."

"It's great to see Apache Rya has matured into a Top-Level Project. Rya is
a very innovative and Open Source RDF data management system based on Big
Data technology," said Dr. Zhiyuan Chen, Associate Professor, Information
Systems Department, University of Maryland Baltimore County. "We have used
Apache Rya in a variety of research projects ranging from more efficient
query processing techniques over geographically distributed RDF data to
situation-aware access control in federated systems. We found Rya very easy
to use, easy to extend, and extremely efficient."

"Apache Rya has the potential to become one of the most scalable RDF data
management systems on the market," said Andreas Blumauer, Founder and CEO,
Semantic Web Company GmbH and Director, PoolParty Software Ltd.

"Our technology helps organizations discover the rare and hidden patterns
with applied semantics enhancements and AI/ML analytics, to develop Living
Intelligence in a data domain," said Kim Ziehlke, Principal Software
Engineer at Modus Operandi. "Patterns are used to predict potential
opportunities

Re: [VOTE] Recommend Apache Rya graduation to Top Level Project resolution to the Board

[Josh Elser]

+1

On 9/6/19 9:29 PM, Adina Crainiceanu wrote:

The Apache Rya (incubating) community is bringing the attached resolution
to graduate to a Top Level Project up for a formal IPMC VOTE.

-We completed all the tasks documented in the status file [1]
-The name Apache Rya was approved by the Brand Management Committee [2]
-We had four Apache releases with three different release managers
-Our community grew during incubation and we learned to function following
the Apache Way
-We discussed on the dev@ list about our readiness for graduation [3], we
voted [4], and the result of the vote was positive [5]
-We went through the process of assessing our project against the Apache
Maturity model [6] and we believe we are ready to graduate and continue to
grow as a Top Level Project.
-We worked on creating a graduation resolution and we selected a Chair [7].

Please take a minute to vote on whether or not the IPMC should recommend
the resolution below to the Board by responding with one of the following:

[ ] +1 Apache Rya should graduate
[ ]  0 No opinion
[ ] -1 Apache Rya should not graduate because...

The VOTE is open for a minimum of 72 hours.

Thank you,
Adina, on behalf of Apache Rya (incubating) community

[1] https://incubator.apache.org/projects/rya.html
[2] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-135
[3]
https://lists.apache.org/thread.html/dd09c2060a754e69e093404e0d57239a555ab5e7d702cf76fd02f820@%3Cdev.rya.apache.org%3E
[4]
https://lists.apache.org/thread.html/10f04a55e0f6d4c09d3ffeac487b0bf309eb8e5058f950778214faeb@%3Cdev.rya.apache.org%3E
[5]
https://lists.apache.org/thread.html/d1664b17d8a6bf3d3e4e5f28382bc360fe974f1db8f880c6d97ff278@%3Cdev.rya.apache.org%3E
[6]
https://cwiki.apache.org/confluence/display/RYA/Apache+Maturity+Evaluation+for+Rya
[7]
https://lists.apache.org/thread.html/3007163bc654df45109c38b4d9a53c7b2137ad0fef660429938a282b@%3Cprivate.rya.apache.org%3E

_
Proposed graduation resolution:

Establish the Apache Rya Project

WHEREAS, the Board of Directors deems it to be in the best interests of
the Foundation and consistent with the Foundation's purpose to establish
a Project Management Committee charged with the creation and maintenance
of open-source software, for distribution at no charge to the public,
related to scalable storage, retrieval, and analysis of RDF data.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
(PMC), to be known as the "Apache Rya Project", be and hereby is
established pursuant to Bylaws of the Foundation; and be it further

RESOLVED, that the Apache Rya Project be and hereby is responsible for
the creation and maintenance of software related to scalable storage,
retrieval, and analysis of RDF data; and be it further

RESOLVED, that the office of "Vice President, Apache Rya" be and hereby
is created, the person holding such office to serve at the direction of
the Board of Directors as the chair of the Apache Rya Project, and to
have primary responsibility for management of the projects within the
scope of responsibility of the Apache Rya Project; and be it further

RESOLVED, that the persons listed immediately below be and hereby are
appointed to serve as the initial members of the Apache Rya Project:

  * Aaron Mihalik 
  * Adina Crainiceanu 
  * Billie Rinaldi
  * Caleb Meier   
  * David Lotts   
  * David Rapp
  * Jennifer Brown
  * Josh Elser
  * Puja Valiyil  
  * Roshan Punnoose   
  * Steve R Wagner

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Adina Crainiceanu be
appointed to the office of Vice President, Apache Rya, to serve in
accordance with and subject to the direction of the Board of Directors
and the Bylaws of the Foundation until death, resignation, retirement,
removal or disqualification, or until a successor is appointed; and be
it further

RESOLVED, that the Apache Rya Project be and hereby is tasked with the
migration and rationalization of the Apache Incubator Rya podling; and
be it further

RESOLVED, that all responsibilities pertaining to the Apache Incubator
Rya podling encumbered upon the Apache Incubator PMC are hereafter
discharged.

Re: [DISCUSS] Graduate Apache Rya (incubating) as a TLP

[Josh Elser]

As one of their mentors, the community as been doing a great job of 
steering themselves for some time now (year+). I've prodded them a bit 
to start this process, and I'm super excited to see them working towards 
graduation now.


They have my +1

- Josh

On 8/31/19 7:16 PM, Adina Crainiceanu wrote:

The Apache Rya (incubating) community would like to start the discussion on
general@ about graduating to a top level project.

-We completed all the tasks documented in the status file [1]
-The name Apache Rya was approved by the Brand Management COmmittee [2]
-We had four Apache releases with three different release managers
-Our community grew during incubation and we learned to function following
the Apache Way
-We discussed on the dev@ list about our readiness for graduation [3], we
voted [4], and the result of the vote was positive [5]
-We went through the process of assessing our project against the Apache
Maturity model [6] and we believe we are ready to graduate and continue to
grow as a Top Level Project.
-We worked on creating a graduation resolution and we selected a Chair [7].
The draft resolution is appended below.

Please provide your opinion on whether Rya is ready to graduate to a top
level project.

Thank you,
Adina, on behalf of Apache Rya (incubating) community

[1] https://incubator.apache.org/projects/rya.html
[2] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-135
[3]
https://lists.apache.org/thread.html/dd09c2060a754e69e093404e0d57239a555ab5e7d702cf76fd02f820@%3Cdev.rya.apache.org%3E
[4]
https://lists.apache.org/thread.html/10f04a55e0f6d4c09d3ffeac487b0bf309eb8e5058f950778214faeb@%3Cdev.rya.apache.org%3E
[5]
https://lists.apache.org/thread.html/d1664b17d8a6bf3d3e4e5f28382bc360fe974f1db8f880c6d97ff278@%3Cdev.rya.apache.org%3E
[6]
https://cwiki.apache.org/confluence/display/RYA/Apache+Maturity+Evaluation+for+Rya
[7]
https://lists.apache.org/thread.html/3007163bc654df45109c38b4d9a53c7b2137ad0fef660429938a282b@%3Cprivate.rya.apache.org%3E

Proposed graduation resolution:

Establish the Apache Rya Project

WHEREAS, the Board of Directors deems it to be in the best interests of
the Foundation and consistent with the Foundation's purpose to establish
a Project Management Committee charged with the creation and maintenance
of open-source software, for distribution at no charge to the public,
related to scalable storage, retrieval, and analysis of RDF data.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
(PMC), to be known as the "Apache Rya Project", be and hereby is
established pursuant to Bylaws of the Foundation; and be it further

RESOLVED, that the Apache Rya Project be and hereby is responsible for
the creation and maintenance of software related to scalable storage,
retrieval, and analysis of RDF data; and be it further

RESOLVED, that the office of "Vice President, Apache Rya" be and hereby
is created, the person holding such office to serve at the direction of
the Board of Directors as the chair of the Apache Rya Project, and to
have primary responsibility for management of the projects within the
scope of responsibility of the Apache Rya Project; and be it further

RESOLVED, that the persons listed immediately below be and hereby are
appointed to serve as the initial members of the Apache Rya Project:

  * Aaron Mihalik 
  * Adina Crainiceanu 
  * Billie Rinaldi
  * Caleb Meier   
  * David Lotts   
  * David Rapp    
  * Jennifer Brown
  * Josh Elser
  * Puja Valiyil  
  * Roshan Punnoose   
  * Steve R Wagner

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Adina Crainiceanu be
appointed to the office of Vice President, Apache Rya, to serve in
accordance with and subject to the direction of the Board of Directors
and the Bylaws of the Foundation until death, resignation, retirement,
removal or disqualification, or until a successor is appointed; and be
it further

RESOLVED, that the Apache Rya Project be and hereby is tasked with the
migration and rationalization of the Apache Incubator Rya podling; and
be it further

RESOLVED, that all responsibilities pertaining to the Apache Incubator
Rya podling encumbered upon the Apache Incubator PMC are hereafter
discharged.

Re: [VOTE] Apache Rya (incubating) graduation to Top Level Project

[Josh Elser]

+1

On 8/27/19 11:48 AM, Adina Crainiceanu wrote:

Dear all,

Following our discussion on the dev mailing list [1] I would like to call a
vote for Apache Rya graduating to a top level project.

If this vote passes, the next step would be to submit the resolution below
to the Incubator PMC, who would vote on sending it on to the ASF Board.

Vote:
[ ] +1 - Recommend graduation of Apache Rya as a TLP
[] 0 - No opinion
[ ] -1 - Do not recommend graduation of Apache Rya because...

The VOTE is open for a minimum of 72 hours.

[1]
https://lists.apache.org/thread.html/dd09c2060a754e69e093404e0d57239a555ab5e7d702cf76fd02f820@%3Cdev.rya.apache.org%3E

---

Establish the Apache Rya Project

WHEREAS, the Board of Directors deems it to be in the best interests of
the Foundation and consistent with the Foundation's purpose to establish
a Project Management Committee charged with the creation and maintenance
of open-source software, for distribution at no charge to the public,
related to scalable storage, retrieval, and analysis of RDF data.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
(PMC), to be known as the "Apache Rya Project", be and hereby is
established pursuant to Bylaws of the Foundation; and be it further

RESOLVED, that the Apache Rya Project be and hereby is responsible for
the creation and maintenance of software related to scalable storage,
retrieval, and analysis of RDF data; and be it further

RESOLVED, that the office of "Vice President, Apache Rya" be and hereby
is created, the person holding such office to serve at the direction of
the Board of Directors as the chair of the Apache Rya Project, and to
have primary responsibility for management of the projects within the
scope of responsibility of the Apache Rya Project; and be it further

RESOLVED, that the persons listed immediately below be and hereby are
appointed to serve as the initial members of the Apache Rya Project:

  * Aaron Mihalik 
  * Adina Crainiceanu 
  * Billie Rinaldi
  * Caleb Meier   
  * David Lotts   
  * David Rapp
  * Jennifer Brown
  * Josh Elser
  * Puja Valiyil  
  * Roshan Punnoose   
  * Steve R Wagner

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Adina Crainiceanu be
appointed to the office of Vice President, Apache Rya, to serve in
accordance with and subject to the direction of the Board of Directors
and the Bylaws of the Foundation until death, resignation, retirement,
removal or disqualification, or until a successor is appointed; and be
it further

RESOLVED, that the Apache Rya Project be and hereby is tasked with the
migration and rationalization of the Apache Incubator Rya podling; and
be it further

RESOLVED, that all responsibilities pertaining to the Apache Incubator
Rya podling encumbered upon the Apache Incubator PMC are hereafter
discharged.

Re: [DISCUSS] Rya graduation to top level project

[Josh Elser]

Looks like http://incubator.apache.org/projects/rya.html is already done!

You have my +1!

On 8/8/19 4:12 PM, Adina Crainiceanu wrote:

Hi,

I would like to start talking again about graduation, After another
successful release, it is time (or past time) to discuss whether we are
ready to graduate.

Rya has entered the Incubator almost 4 years ago. During this time, the
community increased and diversified, and we became familiar with the Apache
way. We had four releases, done by three separate release managers. We
added two people as committers and PPMC members.
I think we can continue to grow the community, and increase the activity
level, but I think we can continue doing that as a TLP.
What do people think?

Thank you,
Adina

Re: Fwd: MODERATE for annou...@apache.org

[Josh Elser]

Thanks Adina!!

On 8/7/19 4:10 PM, Adina Crainiceanu wrote:

The documentation about how to make a release is on the Confluence wiki at
https://cwiki.apache.org/confluence/display/RYA/How+To+Release+Rya

I updated the notes to only generate sha512 checksums and updated the
relevant templates to only mention this checksum.
I created a Jira issue to update the website:
https://issues.apache.org/jira/browse/RYA-519

Thanks,
Adina

On Tue, Aug 6, 2019 at 4:33 PM Josh Elser  wrote:


Thanks, Craig. Moving you to bcc.

Aaron -- are the steps to making a release doc'ed somewhere where they
could be updated with Craig's suggestions?

Glancing through the website and the user manual, I don't see an obvious
page covering the steps.

On 7/29/19 5:48 PM, Private List Moderation wrote:

Hi,

I've approved this announcement, but I suggest a few improvements for

next time.


The download pages include links to md5 and sha1 checksums which are no

longer considered useful. I suggest removing these links and using the
sha512 that is already there.


Regards,

Craig


Begin forwarded message:

From: announce-reject-1564413731.53066.gfcdjfjimlelpbmoi...@apache.org
Subject: MODERATE for annou...@apache.org
Date: July 29, 2019 at 8:22:11 AM PDT
To: Recipient list not shown: ;
Cc: announce-allow-tc.1564413731.egfggeiclieaekeglcnb-mihalik=

apache@apache.org

Reply-To:

announce-accept-1564413731.53066.gfcdjfjimlelpbmoi...@apache.org



To approve:
announce-accept-1564413731.53066.gfcdjfjimlelpbmoi...@apache.org
To reject:
announce-reject-1564413731.53066.gfcdjfjimlelpbmoi...@apache.org
To give a reason to reject:
%%% Start comment
%%% End comment


From: "Aaron D. Mihalik" 
Subject: [ANNOUNCE] Apache Rya 4.0.0-incubating released
Date: July 29, 2019 at 8:21:59 AM PDT
To: annou...@apache.org


The Apache Rya (Incubating) team is happy to announce the release of

Apache Rya 4.0.0-incubating:


https://rya.incubator.apache.org/news/2019/07/27/release-4.0.0/ <

https://rya.incubator.apache.org/news/2019/07/27/release-4.0.0/>


Rya (pronounced "ree-uh" /rēə/) is a cloud-based RDF triple store that

supports SPARQL queries. Rya is a scalable RDF data management system built
on top of Apache Accumulo®. Rya uses novel storage methods, indexing
schemes, and query processing techniques that scale to billions of triples
across multiple nodes. Rya provides fast and easy access to the data
through SPARQL, a conventional query mechanism for RDF data.



Thanks,
The Apache Rya team

=

*Disclaimer*

Apache Rya (incubating) is an effort undergoing Incubation at The

Apache Software Foundation (ASF), sponsored by the Incubator. Incubation is
required of all newly accepted projects until a further review indicates
that the infrastructure, communications, and decision making process have
stabilized in a manner consistent with other successful ASF projects. While
incubation status is not necessarily a reflection of the completeness or
stability of the code, it does indicate that the project has yet to be
fully endorsed by the ASF.





Craig L Russell
Assistant Secretary, Apache Software Foundation
c...@apache.org <mailto:c...@apache.org> http://db.apache.org/jdo <

http://db.apache.org/jdo>

Re: Fwd: MODERATE for annou...@apache.org

[Josh Elser]

Thanks, Craig. Moving you to bcc.

Aaron -- are the steps to making a release doc'ed somewhere where they 
could be updated with Craig's suggestions?


Glancing through the website and the user manual, I don't see an obvious 
page covering the steps.


On 7/29/19 5:48 PM, Private List Moderation wrote:

Hi,

I've approved this announcement, but I suggest a few improvements for next time.

The download pages include links to md5 and sha1 checksums which are no longer 
considered useful. I suggest removing these links and using the sha512 that is 
already there.

Regards,

Craig


Begin forwarded message:

From: announce-reject-1564413731.53066.gfcdjfjimlelpbmoi...@apache.org
Subject: MODERATE for annou...@apache.org
Date: July 29, 2019 at 8:22:11 AM PDT
To: Recipient list not shown: ;
Cc: 
announce-allow-tc.1564413731.egfggeiclieaekeglcnb-mihalik=apache@apache.org
Reply-To: announce-accept-1564413731.53066.gfcdjfjimlelpbmoi...@apache.org


To approve:
   announce-accept-1564413731.53066.gfcdjfjimlelpbmoi...@apache.org
To reject:
   announce-reject-1564413731.53066.gfcdjfjimlelpbmoi...@apache.org
To give a reason to reject:
%%% Start comment
%%% End comment


From: "Aaron D. Mihalik" 
Subject: [ANNOUNCE] Apache Rya 4.0.0-incubating released
Date: July 29, 2019 at 8:21:59 AM PDT
To: annou...@apache.org


The Apache Rya (Incubating) team is happy to announce the release of Apache Rya 
4.0.0-incubating:
  
https://rya.incubator.apache.org/news/2019/07/27/release-4.0.0/ 


Rya (pronounced "ree-uh" /rēə/) is a cloud-based RDF triple store that supports 
SPARQL queries. Rya is a scalable RDF data management system built on top of Apache 
Accumulo®. Rya uses novel storage methods, indexing schemes, and query processing 
techniques that scale to billions of triples across multiple nodes. Rya provides fast and 
easy access to the data through SPARQL, a conventional query mechanism for RDF data.
  
  
Thanks,

The Apache Rya team
  
=
  
*Disclaimer*
  
Apache Rya (incubating) is an effort undergoing Incubation at The Apache Software Foundation (ASF), sponsored by the Incubator. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.





Craig L Russell
Assistant Secretary, Apache Software Foundation
c...@apache.org  http://db.apache.org/jdo 

Re: July podling report draft - please comment

[Josh Elser]

Roger that. Done.

On 7/3/19 10:13 AM, Adina Crainiceanu wrote:

Hi,

I submitted the report. Mentors signatures are due on July 09.

Thank you,
Adina

On Sun, Jun 30, 2019 at 10:10 AM Adina Crainiceanu  wrote:


Hi,

Below is the draft of the podling report due Wednesday. Any comments are
welcome.


Rya

Rya (pronounced "ree-uh" /rēə/) is a cloud-based RDF triple store that
supports SPARQL queries. Rya is a scalable RDF data management system
built
on top of Accumulo. Rya uses novel storage methods, indexing schemes, and
query
processing techniques that scale to billions of triples across multiple
nodes.
Rya provides fast and easy access to the data through SPARQL, a
conventional
query mechanism for RDF data.

Rya has been incubating since 2015-09-18.

Three most important issues to address in the move towards graduation:

   Working through the graduation procedure steps.

Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware
of?

   No

How has the community developed since the last report?

   * The community is moving towards graduation: name search completed,
   project status file updated, the Apache Project maturity model
evaluation
   almost done, PMC list being finalized
   * "SPARQL at Scale with Apache Rya" accepted for presentation at
ApacheCon Las Vegas, Sept 2019

How has the project developed since the last report?

   * working on a major release in the next few month

How would you assess the podling's maturity?
Please feel free to add your own commentary.

   [ ] Initial setup
   [ ] Working towards first release
   [ ] Community building
   [x] Nearing graduation
   [ ] Other:

Date of last release:

2018-03-04

When were the last committers or PPMC members elected?

   * PPMC member Caleb Meier elected on Jan 3rd, 2017

Have your mentors been helpful and responsive or are things falling
through the cracks? In the latter case, please list any open issues
that need to be addressed.

   Our two mentors are helpful and responsive.

Signed-off-by:

   [](rya) Josh Elser
  Comments:
   [](rya) Billie Rinaldi
  Comments:

IPMC/Shepherd notes:

--
Dr. Adina Crainiceanu
Associate Professor
Computer Science Department
United States Naval Academy
410-293-6822
ad...@usna.edu
http://www.usna.edu/Users/cs/adina/

Re: January podling report draft - please comment

[Josh Elser]

Overall, it looks OK. A few suggestions inline.

On Sat, Dec 29, 2018 at 4:28 PM Adina Crainiceanu  wrote:
>
> Rya community,
>
> We need to submit the ASF podling report by January 2nd. I've started the
> report below. Please let me know if you have any comments or additions.
>
> Best wishes for the new year!
> Adina
>
>
> Rya
>
> Rya (pronounced "ree-uh" /rēə/) is a cloud-based RDF triple store that
> supports SPARQL queries. Rya is a scalable RDF data management system built
> on
> top of Accumulo. Rya uses novel storage methods, indexing schemes, and query
> processing techniques that scale to billions of triples across multiple
> nodes.
> Rya provides fast and easy access to the data through SPARQL, a conventional
> query mechanism for RDF data.
>
> Rya has been incubating since 2015-09-18.
>
> Three most important issues to address in the move towards graduation:
>
>   1. Increase diversity of committers

I saw you were also doing the necessary paperwork for graduation.
Would be nice to mention.

> Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware
> of?
>
> No
>
> How has the community developed since the last report?
>
>  * The community is moving towards graduation: name search completed,
> project status file updated, started the Apache Project maurity model
> evaluation
>  * A CCLA from Semantic Web Company has been submitted

Would clarify that this is in relation to the next point (multiple new
contributors from the Semantic Web Company)

>  * We have several new users and contributors who interacted with the
> community
>
> How has the project developed since the last report?
>
>  * new upgraded SPARQL endpoint under review
>
> How would you assess the podling's maturity?
> Please feel free to add your own commentary.
>
>   [ ] Initial setup
>   [ ] Working towards first release
>   [ ] Community building
>   [x] Nearing graduation
>   [ ] Other:
>
> Date of last release:
>
>2018-03-04
>
> When were the last committers or PPMC members elected?
>
>  * PPMC member Caleb Meier elected on Jan 3rd, 2017
>
> Signed-off-by:
>
>   [ ](rya) Josh Elser
>  Comments:
>   [ ](rya) Billie Rinaldi
>  Comments:
>
> IPMC/Shepherd notes:
>
>
> --
> Dr. Adina Crainiceanu
> Associate Professor
> Computer Science Department
> United States Naval Academy
> 410-293-6822
> ad...@usna.edu
> http://www.usna.edu/Users/cs/adina/

Re: Mentors help needed - project status file

[Josh Elser]

No need to find the earliest date. You (or I) can just put the current 
date. The purpose is to just record the date that we're sure all of 
these things happened by.


I can vouch that all 3 are good. Let me know if you'd prefer that I 
update it.


Thanks for driving this home, Adina!

On 11/3/18 10:38 AM, Adina Crainiceanu wrote:

Hi,

I updated the project status file at
http://incubator.apache.org/projects/rya.html but I'm not sure about the
dates for the "Mentor-related responsibility/oversight" section. Mentors:
is there a way to figure those dates from whimsy or maybe old emails?
The JIRA issue for this is:
https://issues.apache.org/jira/browse/RYA-503

Thanks,
Adina

Re: Mentors help needed - project status file

[Josh Elser]

ACK. Will investigate.

On 11/3/18 10:38 AM, Adina Crainiceanu wrote:

Hi,

I updated the project status file at
http://incubator.apache.org/projects/rya.html but I'm not sure about the
dates for the "Mentor-related responsibility/oversight" section. Mentors:
is there a way to figure those dates from whimsy or maybe old emails?
The JIRA issue for this is:
https://issues.apache.org/jira/browse/RYA-503

Thanks,
Adina

Re: October podling report draft - please comment

[Josh Elser]

Awesome. That's great to hear, Jürgen!

Looking forward to looks of interaction with you and your coworkers.

On 10/1/18 3:33 PM, Jürgen Jakobitsch wrote:

i'd support mentioning the folks from semantic web company :-)
(it's certainly not going to be drive-by as well)

we will be using rya during the next three years intensively for one of our
research projects (h2020 => logistar)

we just setup a fork on our official github. using this we will commit step
by step a lot of issues that we've
already tested on our local installations (on different nodes and on DC/OS)
including accumulo/hdfs/libthrift version upgrades
and a new shiny sparqlendpoint conforming to all standards. we do this on a
step by step basis now, to be able to create
meaningful and contained pull requests..

krj

*Jürgen Jakobitsch*
Senior Technical Consultant
Semantic Web Company GmbH
EU: +43-14021235 <+43%201%204021235>
US: (415) 800-3776
Mobile: +43-676-6212710 <+43%20676%206212710>
https://www.poolparty.biz
https://www.semantic-web.com

*Download E-Book*: Introducing Semantic AI
<https://www.poolparty.biz/machine-learning-meets-semantics/>


Am Mo., 1. Okt. 2018 um 21:21 Uhr schrieb Josh Elser :


New contributors are good to mention (as long as they're not "drive-by"
contributions where you don't expect future contributions).

On 10/1/18 11:45 AM, David Lotts wrote:

Would it be appropriate to mention the relatively new involvement of the
good folks at Semantic Web Company?
This increases our diversity and stability.
david.

Re: October podling report draft - please comment

[Josh Elser]

New contributors are good to mention (as long as they're not "drive-by" 
contributions where you don't expect future contributions).


On 10/1/18 11:45 AM, David Lotts wrote:

Would it be appropriate to mention the relatively new involvement of the
good folks at Semantic Web Company?
This increases our diversity and stability.
david.

Re: IP clearance needed for the logo?

[Josh Elser]

Talked to Billie about this -- trying to make sure I have the situation 
correct. IMO, the question that needs to be answered is: who can assert 
copyright ownership over the images.


Typically, copyright assertions are one of two entities: the individual 
who created some "work" or a company which paid the individual to create 
the work on their behalf.


From what I see, Robert David posted images from Susan Härtig, who both 
work for Semantic Web. Thus, were these images created as a part of 
Susan's professional responsibilities at Semantic Web Company? If so, a 
CCLA from Semantic Web Company should be filed with the ASF. If not, an 
affirmative statement from Susan (or a trusted member of Rya 
acknowledging on Susan's behalf) would just be required, creating an 
audit-trail of Susan's intent to grant ownership of these images to Rya.


Maybe Robert/Susan can comment? Or Adina, you can chase this offline?

On 9/18/18 9:46 PM, Adina Crainiceanu wrote:

Hi,

Does anyone know  what (if anything) needs to be done to be able to
receive/use a logo designed by Susan/ Semantic Web Company?

Maybe our mentors can weigh in?

Thank you,
Adina

Graduation

[Josh Elser]

When is it going to happen? IMO, you've been ready for a long time now :)

Re: can't creating a Rya Accumulo repo in Vagrant Example of incubator-rya

[Josh Elser]

Forwarding this message to the actual mailing list.

On 5/15/18 2:53 PM, b...@bobdc.com wrote:
I am trying to use the Rya Vagrant Example shown at 
https://github.com/apache/incubator-rya/tree/master/extras/vagrantExample/src/main/vagrant.


After updating the ACCUMULO_VERSION, HADOOP_VERSION, and 
RYA_EXAMPLE_VERSION values in Vagrantfile (the old values referenced 
versions that were no longer available) , I got it installed, and all of 
the verification steps mentioned on the web page above worked. After 
clicking New Repository, I can create an "In Memory Store", but after 
entering a Type of "Rya Accumulo Store", an ID, a title, and accepting 
all the default values shown, I can't create a repo.


The Chrome console adds these messages each time I click "Create"on that 
screen:


jquery-1.11.0.min.js:4 GET 
http://192.168.33.10:8080/rdf4j-workbench/repositories/undefined/info 
500 (Internal Server Error)

send @ jquery-1.11.0.min.js:4
ajax @ jquery-1.11.0.min.js:4
checkOverwrite @ create.ts:25
onclick @ create?type=RyaAccumuloSail&id=id4&title=title+of+id4&next=Next:28
create.ts:37 Uncaught TypeError: Cannot read property 'match' of undefined
     at Object.complete (create.ts:37)
     at j (jquery-1.11.0.min.js:2)
     at Object.fireWith (jquery-1.11.0.min.js:2)
     at x (jquery-1.11.0.min.js:4)
     at XMLHttpRequest.b (jquery-1.11.0.min.js:4)

Any suggestions?

Thanks,

Bob

Re: April Rya podling report draft - please comment

[Josh Elser]

A little late, but it looks good to me too.

When are you submitting paperwork to graduate? :)

On 4/2/18 1:54 PM, Adina Crainiceanu wrote:

Hi,

I started the podling report for the ASF board due Wednesday April 4th.
Please review it and let me know of any recommendations/changes.

I'll submit a version tomorrow evening, and we can still modify it until
Wednesday.

Thanks,
Adina

Rya

Rya (pronounced "ree-uh" /rēə/) is a cloud-based RDF triple store that
supports SPARQL queries. Rya is a scalable RDF data management system built
on
top of Accumulo. Rya uses novel storage methods, indexing schemes, and query
processing techniques that scale to billions of triples across multiple
nodes.
Rya provides fast and easy access to the data through SPARQL, a conventional
query mechanism for RDF data.

Rya has been incubating since 2015-09-18.

Three most important issues to address in the move towards graduation:

   1. Increase diversity of committers

Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
aware of?

No

How has the community developed since the last report?
  * Apache Rya 3.2.12 (incubating) released
  * More people expressed interest in contributing to Rya
  * More discussions about graduation

How has the project developed since the last report?
  * Apache Rya 3.2.12 (incubating) released
  * Improved documentation for deploying Rya PCJ Updater
  * Created a Rya Shell for MongoDB
  * Integrated RyaStreams with the Rya Shell
  * Added PCJ indexer support for MongoDB backend
  * Implemented a forward-chaining rules engine that runs as a batch
process, operates on user-defined SPIN rules, and inserts derived
information back in Rya
  * Added the ability to use the MongoDB aggregation pipeline to evaluate
simple SPARQL expressions for MongoDB backend
  * Implemented single node Kafka streams incremental SPARQL processor

How would you assess the podling's maturity?
Please feel free to add your own commentary.

   [ ] Initial setup
   [ ] Working towards first release
   [ ] Community building
   [x] Nearing graduation
   [ ] Other:

Date of last release:

   2018-03-04

When were the last committers or PPMC members elected?

  * PPMC member Caleb Meier elected on Jan 3rd, 2017


Signed-off-by:

   [ ](rya) Josh Elser
  Comments:
   [ ](rya) Edward J. Yoon
  Comments:
   [ ](rya) Venkatesh Seetharam
  Comments:
   [ ](rya) Billie Rinaldi
  Comments:

IPMC/Shepherd notes:

Re: April Rya podling report draft - please comment

[Josh Elser]

Hi Jürgen,

These reports are more focused around the project's "health" with 
respect to its community as opposed to technical changes being made. So, 
it's usually not appropriate to call out specific changes which have 
been made.


That said, if the report hasn't already been submitted (I'm catching up 
myself), it would be nice to mention the recent contributions by Jürgen 
(and team?) as these are in the spirit of open source :)


On 4/3/18 9:28 AM, Jürgen Jakobitsch wrote:

hi adina..

might be important for your report.. i've created a set of improvement
issues in jira [1].
all related to the SPARQL endpoint.
note that those issues are basically not interferring with existing code,
but are mainly
a drive towards known standards from the semantic web/linked data community.

we (semantic web company) are actively developing on those issues and will
come up with
1. a sample sparql endpoint showcasing all the features we mentioned
 (this is gonna be just a tiny sample so people can take a look at those
features)
 it's a small maven spring project, so that it is possible to test the
features without
 having to rebuild the  whole of ra
2. if 1 = ok
 an integration into existing rya codebase with unit tests as a pull
request.

kind regards
jürgen

[1] https://issues.apache.org/jira/browse/RYA-477



*Jürgen Jakobitsch*
Innovation Director
Semantic Web Company GmbH
EU: +43-14021235 <+43%201%204021235>
US: (415) 800-3776
Mobile: +43-676-6212710 <+43%20676%206212710>
https://www.poolparty.biz
https://www.semantic-web.com

*Download now
<https://www.poolparty.biz/wp-content/uploads/2017/08/IDC_Paper_How_Semantic_Technologies_Steer_Cognitive_Applications.pdf>
**IDC
White Paper*
*Get certified! <https://www.poolparty.biz/academy/> **PoolParty Academy*


*PoolParty selected as a KMWorld Trend-Setting Product for 2017*


PERSONAL INFORMATION
| web   : http://www.turnguard.com
| foaf  : http://www.turnguard.com/turnguard
| g+: https://plus.google.com/111233759991616358206/posts
| skype : jakobitsch-punkt
| xmlns:tg  = "http://www.turnguard.com/turnguard#";
| blockchain : https://onename.com/turnguard

2018-04-03 15:11 GMT+02:00 Billie Rinaldi :


Sounds good to me.

On Mon, Apr 2, 2018 at 10:54 AM, Adina Crainiceanu  wrote:


Hi,

I started the podling report for the ASF board due Wednesday April 4th.
Please review it and let me know of any recommendations/changes.

I'll submit a version tomorrow evening, and we can still modify it until
Wednesday.

Thanks,
Adina

Rya

Rya (pronounced "ree-uh" /rēə/) is a cloud-based RDF triple store that
supports SPARQL queries. Rya is a scalable RDF data management system

built

on
top of Accumulo. Rya uses novel storage methods, indexing schemes, and
query
processing techniques that scale to billions of triples across multiple
nodes.
Rya provides fast and easy access to the data through SPARQL, a
conventional
query mechanism for RDF data.

Rya has been incubating since 2015-09-18.

Three most important issues to address in the move towards graduation:

   1. Increase diversity of committers

Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
aware of?

No

How has the community developed since the last report?
  * Apache Rya 3.2.12 (incubating) released
  * More people expressed interest in contributing to Rya
  * More discussions about graduation

How has the project developed since the last report?
  * Apache Rya 3.2.12 (incubating) released
  * Improved documentation for deploying Rya PCJ Updater
  * Created a Rya Shell for MongoDB
  * Integrated RyaStreams with the Rya Shell
  * Added PCJ indexer support for MongoDB backend
  * Implemented a forward-chaining rules engine that runs as a batch
process, operates on user-defined SPIN rules, and inserts derived
information back in Rya
  * Added the ability to use the MongoDB aggregation pipeline to evaluate
simple SPARQL expressions for MongoDB backend
  * Implemented single node Kafka streams incremental SPARQL processor

How would you assess the podling's maturity?
Please feel free to add your own commentary.

   [ ] Initial setup
   [ ] Working towards first release
   [ ] Community building
   [x] Nearing graduation
   [ ] Other:

Date of last release:

   2018-03-04

When were the last committers or PPMC members elected?

  * PPMC member Caleb Meier elected on Jan 3rd, 2017


Signed-off-by:

   [ ](rya) Josh Elser
  Comments:
   [ ](rya) Edward J. Yoon
  Comments:
   [ ](rya) Venkatesh Seetharam
  Comments:
   [ ](rya) Billie Rinaldi
  Comments:

IPMC/Shepherd notes:


--
Dr. Adina Crainiceanu
Associate Professor
Computer Science Department
United States Naval Academy
410-293-6822
ad...@usna.edu
http://www.usna.edu/Users/cs/adina/

Re: [VOTE] Release Apache Rya (incubating) 3.2.12 RC1

[Josh Elser]

IIRC, the findbugs-annotation artifact is dubious at best in terms of 
licensing. I think the "intent" was that it was compatibly licensed, but 
the artifacts in Maven totally had it mislabeled.


Not something that needs to block your release now, but you should be 
taking this up to make sure are I want y'all to graduate soon :)


On 2/14/18 11:29 AM, Jeff Dasch wrote:

I just dug through some emails and we did identify this in 3.2.11-RC2.  We
had a number of other licensing issues on that RC so it is not clear to me
if this particular finding got dropped, or was determined to be a
non-issue.  Regardless, this same issue does affect the 3.2.11 release.

On Wed, Feb 14, 2018 at 10:57 AM, Puja Valiyil  wrote:


I’m confused because that project was in our previous release.  Didn’t we
upgrade the version of giraph to fix this or am I misremembering?

Sent from my iPhone


On Feb 14, 2018, at 10:37 AM, Jeff Dasch  wrote:

Again, not sure if this license thing is a blocker.  But if it is, I put

up

PR-274 as a fix: https://github.com/apache/incubator-rya/pull/274



On Tue, Feb 13, 2018 at 4:37 PM, Jeff Dasch  wrote:

I'm not voting yet, but I did run a license check and got a hit on this:
(GNU Lesser Public License) FindBugs-Annotations
(com.google.code.findbugs:annotations:2.0.2 -
http://findbugs.sourceforge.net/)

which comes from Apache Giraph
[INFO] org.apache.rya:rya.giraph:jar:3.2.12-incubating
[INFO] +- org.apache.giraph:giraph-core:jar:1.2.0:compile
[INFO] |  +- com.google.code.findbugs:annotations:jar:2.0.2:compile

I'm pretty sure we ran into this during the last release.  Are we still
good to go on this RC, or do we need to cut a new one that has a giraph
profile?




On Mon, Feb 12, 2018 at 8:51 PM, Adina Crainiceanu 

wrote:


Rya community,

I am pleased to be calling this vote for the source release of Apache

Rya

(Incubating), version 3.2.12.

The source zip, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/rya/rya-
incubating-3.2.12-rc1/

Ancillary artifacts such as poms, jars, wars, etc. can be found here:
https://repository.apache.org/content/repositories/
orgapacherya-1009/org/apache/rya/

The Git tag is rya-incubating-3.2.12-rc1
The Git commit ID is e9ecf7fae76e308cfc0d90684ce684493482266c
https://git-wip-us.apache.org/repos/asf?p=incubator-rya.git;
a=commit;h=e9ecf7fae76e308cfc0d90684ce684493482266c


Checksums of rya-project-3.2.12-source-release.zip:
SHA512:8059adff3a264cdcc85edb8ab1c820d87d4e2adbdfd4eebfcd7d2
7b9a3c8c2af8cd09cb39b91ccb5170fe37159b1360078ef8e61321e7f6ca
e6141442bbf8dda
SHA1: 64296d86923dae11294dcff0719cfcb9522a744d
MD5: 9c55ae7f811afaa147ebb7f652543620

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/adina.asc

KEYS file available here:
https://dist.apache.org/repos/dist/release/incubator/rya/KEYS

Issues that were closed/resolved for this release are here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?
projectId=12319020&version=12341570


The vote will be open for at least 72 hours until end of Thursday,
February
15, 2018 ET.
Please download the release candidate and evaluate the necessary items
including checking hashes, signatures, build from source, and test.

Then

please vote:

[ ] +1 Release this package as rya-project-3.2.12
[ ] +0 no opinion
[ ] -1 Do not release this package because because...


Thank you,
Adina

--
Dr. Adina Crainiceanu
Associate Professor
Computer Science Department
United States Naval Academy
410-293-6822 <(410)%20293-6822>
ad...@usna.edu
http://www.usna.edu/Users/cs/adina/

Re: January 2018 incubator report draft - please comment

[Josh Elser]

+1

On 12/29/17 8:57 PM, Adina Crainiceanu wrote:

Hi all,

I started the incubator report due January 3th. I'll submit this version 
now just to make sure we have something in before the deadline, but I'll 
update it on the morning of January 3rd with your comments.


Happy holidays!!

Adina


Rya

Rya (pronounced "ree-uh" /rēə/) is a cloud-based RDF triple store that
supports SPARQL queries. Rya is a scalable RDF data management system 
built on

top of Accumulo. Rya uses novel storage methods, indexing schemes, and query
processing techniques that scale to billions of triples across multiple 
nodes.

Rya provides fast and easy access to the data through SPARQL, a conventional
query mechanism for RDF data.

Rya has been incubating since 2015-09-18.

Three most important issues to address in the move towards graduation:

   1. Have more releases as part of the Apache Foundation
   2. Increase diversity of contributors.


Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
aware of?

No

How has the community developed since the last report?

   * Working on the next release
   * Starting discussions about graduation

How has the project developed since the last report?

   * Implemented a cache for Fluo query metadata
   * Added a Twill App for running the periodic service
   * Fixed several bugs

How would you assess the podling's maturity?
Please feel free to add your own commentary.

   [ ] Initial setup
   [ ] Working towards first release
   [ ] Community building
   [x] Nearing graduation
   [ ] Other:

Date of last release:

   2017-10-10

When were the last committers or PPMC members elected?

  * PPMC member Caleb Meier elected on Jan 3rd, 2017

Signed-off-by:

   [ ](rya) Josh Elser
      Comments:
   [ ](rya) Edward J. Yoon
      Comments:
   [ ](rya) Venkatesh Seetharam
      Comments:
   [ ](rya) Billie Rinaldi
      Comments:

IPMC/Shepherd notes:



--
Dr. Adina Crainiceanu
Associate Professor
Computer Science Department
United States Naval Academy
410-293-6822
ad...@usna.edu <mailto:ad...@usna.edu>
http://www.usna.edu/Users/cs/adina/

Re: [DISCUSS] Graduation?

[Josh Elser]

/me gets out soapbox

Let's remember that incubation at the ASF is *not* about technical 
quality of the software. Incubation is about understanding the way that 
projects are operated at the ASF. This means that the key areas are:


* A diverse community of folks working on a project (not just one 
company, group, etc) to prevent the project from immediately dying if 
that group stops contributing.
* The ability to make valid Apache releases (licensing/copyright 
concerns and ASF policies)
* Community members who embrace community development and the "Apache 
Way": all work and decisions done in the public, merit given to those 
deserving, etc.


The podlings handling of their last release (and licensing issues) gave 
me confidence that they are very close. There will always be a "we 
should fix $x", and that shouldn't be something that holds up graduation 
(except in extreme situations around license incompatibility).


On 11/30/17 7:02 AM, Puja Valiyil wrote:

Hi Eric,
I think the graduation process would take several months.  The rdf4j upgrade is 
likely to be merged in prior to that.
What's the status of that pr?  I know Eric white and a few other developers 
were helping the original author with it, but it fell off my radar over 
thanksgiving.  Did we make a decision about how to support legacy users 
(maintaining a 3.x branch and pulling the rdf 4j upgrade as. 4.x change since 
it's a breaking change)?

Sent from my iPhone


On Nov 30, 2017, at 5:20 AM, Erik Bijsterbosch  wrote:

Hi all,

Shouldn't code for OpenRDF be refactored to RDF4J for graduation?

Regards,
Erik

2017-11-22 23:55 GMT+01:00 Josh Elser :


Hiya,

(Disclaimer, I have not crunched any numbers yet about diversity, traffic,
etc)

I was thinking the other day that Rya is "old" enough that we should start
thinking about graduation[1], and, if we don't think it's ready, let's set
concrete/actionable goals which people can push towards to get the podling
to graduation.

Thoughts/Opinions?

- Josh

[1] https://incubator.apache.org/guides/graduation.html

[DISCUSS] Graduation?

[Josh Elser]

Hiya,

(Disclaimer, I have not crunched any numbers yet about diversity, 
traffic, etc)


I was thinking the other day that Rya is "old" enough that we should 
start thinking about graduation[1], and, if we don't think it's ready, 
let's set concrete/actionable goals which people can push towards to get 
the podling to graduation.


Thoughts/Opinions?

- Josh

[1] https://incubator.apache.org/guides/graduation.html

Re: Twitter announce

[Josh Elser]

Done! You're an admin now :)

If you log into https://tweetdeck.twitter.com, you should see a "team" 
associated for @ApacheRya which you can manage.


On 10/19/17 12:40 PM, Lotts, David wrote:

Josh,

If you can send me your twitter handle,


@dlotts

Thanks, that'll be great.
David.

Re: Twitter announce

[Josh Elser]

I'd prefer to enable you to do it :)

If you can send me your twitter handle, I can grant you permission such 
that you can tweet whatever you'd like from the apacherya account.


On 10/16/17 2:58 PM, David Lotts wrote:

Josh,
I am about to send the release announcement.  Would you like to tweet it as
well?  I'm configuring my gmail account to send from dlo...@apache.org.
david.

On Thu, Jan 12, 2017 at 11:46 AM, Josh Elser  wrote:


Since the responses have been mostly positive, I've just gone ahead and
created an account.

I am happy to transfer ownership of the actual account to anyone, as well
as add anyone to the "team" via tweetdeck to be able to interact with the
account.

https://twitter.com/apacherya

Re: Rya missing mentor sign-off -Fwd: [DRAFT] Incubator PMC Board Report - October 2017

[Josh Elser]

PPMC members elected?

   2017-02-13 Woonsan Ko, committer (non-PMC)

Signed-off-by:

   [X](freemarker) Jacopo Cappellato
  Comments:
   [X](freemarker) Jean-Frederic Clere
  Comments:
   [X](freemarker) David E. Jones
  Comments:
   [X](freemarker) Ralph Goers
  Comments:
   [ ](freemarker) Sergio Fernández
  Comments:

IPMC/Shepherd notes:




Gobblin

Gobblin is a distributed data integration framework that simplifies common
aspects of big data integration such as data ingestion, replication,
organization and lifecycle management for both streaming and batch data
ecosystems.

Gobblin has been incubating since 2017-02-23.

Three most important issues to address in the move towards graduation:

   1. Cut our first release.
   2. Elect new Committer(s) / PPMC.
   3. Update links on website and documentation.

Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
aware of?

   None

How has the community developed since the last report?

* 15+ major companies, startups, universites and research institutes are
now using Gobblin (refer to Powered-by section [1] here:
https://gobblin.apache.org/ )
* Email stats for last month:
   u...@gobblin.incubator.apache.org : 25
   d...@gobblin.incubator.apache.org : 163
* There have been 40 Commits in last month:
 git log --format='%ci' | grep -cE '2017-0(9)'
* 29 of those commits were by non-committers:
git log --format='%ae %ci' | grep -E '2017-0(9)' | cut -d ' ' -f 1 |
sort | uniq -c | sort -n
* Another video conference based meetup happened last month with good
attendance and interest.
* We are continuing to work towards our first release.

[1] This data was collected before incubation via a survey. It was expanded
to include more companies as and when requested by respective contributors.

How has the project developed since the last report?

* Continued active development.
* Progress continues to be tracked via JIRA / Sprint dashboard.

How would you assess the podling's maturity?

There is an all around progress, and the podling is working towards its
first release.

   [ ] Initial setup
   [X] Working towards first release
   [X] Community building
   [ ] Nearing graduation
   [ ] Other:

Date of last release:

   N/A

When were the last committers or PPMC members elected?

   N/A

Signed-off-by:

   [ ](gobblin) Jean-Baptiste Onofré
  Comments:
   [ ](gobblin) Olivier Lamy
  Comments:
   [X](gobblin) Jim Jagielski
  Comments:

IPMC/Shepherd notes:

   johndament: The podling has the right notion of next steps, website is
probably the biggest area of work needed.


Gossip

Gossip is an implementation of the Gossip Protocol.

Gossip has been incubating since 2016-04-28.

Three most important issues to address in the move towards graduation:

   1.
   2.
   3.

Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
aware of?



How has the community developed since the last report?



How has the project developed since the last report?


How would you assess the podling's maturity?
Please feel free to add your own commentary.

   [ ] Initial setup
   [ ] Working towards first release
   [ ] Community building
   [ ] Nearing graduation
   [ ] Other:

Date of last release:

   -XX-XX

When were the last committers or PPMC members elected?



Signed-off-by:

   [ ](gossip) P. Taylor Goetz
  Comments:
   [ ](gossip) Josh Elser
  Comments:
   [ ](gossip) Drew Farris
  Comments:

IPMC/Shepherd notes:




HAWQ

HAWQ is an advanced enterprise SQL on Hadoop analytic engine built around a
robust and high-performance massively-parallel processing (MPP) SQL
framework
evolved from Pivotal Greenplum Database.

HAWQ has been incubating since 2015-09-04.

Three most important issues to address in the move towards
graduation:

   1. Continue to improve the project's release cadence. To this
  end we plan on expanding automation services to support
  increased developer participation.


Any issues that the Incubator PMC (IPMC) or ASF Board wish/need
to be aware of?

  Nothing urgent at this time.

How has the community developed since the last report?

1. Conference Talks (2):

  * Big Data Technology Trends. China Big Data Industry Ecosystem Conference
(Speaker: Lei Chang, August 2, 2017)

  * Future Data Warehouse. China CIO Conference (Speaker: Lei Chang, Sep 16,
2017)

2. Active contributions from approximately 20 different community
contributors since the last report (July 2017).

3. Yi JIN volunteered as the release manager for 2.3 release.

4. Three committer candidates are under voting process:

1) Amy BAI
2) ChunLing WANG
3) Hongxu MA


How has the project developed since the last report?

1. Apache HAWQ 2.2.0.0 was released. HAWQ 2.2 is the first binary release.

Release information:

1) Release page:

https://cwiki.apache.or

Re: Rya podling report draft - please comment

[Josh Elser]

I wouldn't worry about it. Just put a note that says something like 
"PPMC voted to release 3.2.11, waiting on approval by IPMC". No need to 
make it harder on yourselves trying to coordinate :)


On 10/2/17 11:41 AM, David Lotts wrote:

Working on the results now and then general@i.a.o. immediately after.
david.

On Mon, Oct 2, 2017 at 8:45 AM, Adina Crainiceanu  wrote:


David, do you plan on starting a vote for Rya on the general@i.a.o list,
since there are only positive votes from the dev list? Even if the vote
does not conclude by the Wednesday deadline, we can submit the board report
and then maybe modify it a few days later (before the mentor sign-off is
due).


On Sun, Oct 1, 2017 at 9:42 PM, Puja Valiyil  wrote:


Will the vote on the next release have ended before Wednesday?  It might
be worth waiting to submit until we can claim success there

Sent from my iPhone


On Oct 1, 2017, at 9:27 PM, Adina Crainiceanu  wrote:

Hi,

I started the report due Wednesday. Please let me know how we can

improve

it. The draft is below:

Rya

Rya (pronounced "ree-uh" /rēə/) is a cloud-based RDF triple store that
supports SPARQL queries. Rya is a scalable RDF data management system

built

on top of Accumulo. Rya uses novel storage methods, indexing schemes,

and

query processing techniques that scale to billions of triples across
multiple nodes.
Rya provides fast and easy access to the data through SPARQL, a
conventional query mechanism for RDF data.

Rya has been incubating since 2015-09-18.

Three most important issues to address in the move towards graduation:

  1. Have more releases as part of the Apache Foundation
  2. Increase diversity of contributors.


Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
aware of?

  No

How has the community developed since the last report?

  * New release currently under vote on general@ list


How has the project developed since the last report?

  * Implemented new types of inferences: owl:hasValue, owl:unionOf,
owl:equivalentClass, owl:allValuesFrom, owl:intersectionOf, owl: oneOf,
owl:someValuesFrom, owl:ReflexiveProperty, owl:hasSelf
  * Added documentation and examples for the use of shell, Prospector,

and

Pre-computed joins updater
  * Removed/replaced code that used incopatible license (e.g. org.json,
jcalendar)  - use ALv2 compatible license now


How would you assess the podling's maturity?
Please feel free to add your own commentary.

  [ ] Initial setup
  [ ] Working towards first release
  [ ] Community building
  [x] Nearing graduation
  [ ] Other:

Date of last release:

  2016-10-28

When were the last committers or PPMC members elected?

  * PPMC member Caleb Meier elected on Jan 3rd, 2017


Signed-off-by:

  [ ](rya) Josh Elser
 Comments:
  [ ](rya) Edward J. Yoon
 Comments:
  [ ](rya) Venkatesh Seetharam
 Comments:
  [ ](rya) Billie Rinaldi
 Comments:

IPMC/Shepherd notes:



Thank you,
Adina
--
Dr. Adina Crainiceanu
Associate Professor, Computer Science Department
United States Naval Academy
410-293-6822
ad...@usna.edu
http://www.usna.edu/Users/cs/adina/






--
Dr. Adina Crainiceanu
Associate Professor, Computer Science Department
United States Naval Academy
410-293-6822
ad...@usna.edu
http://www.usna.edu/Users/cs/adina/

Re: Podling Report Reminder - October 2017

[Josh Elser]

This Wednesday, folks :)

On 10/1/17 9:06 AM, johndam...@apache.org wrote:

Dear podling,

This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.

The board meeting is scheduled for Wed, 18 October 2017, 10:30 am PDT.
The report for your podling will form a part of the Incubator PMC
report. The Incubator PMC requires your report to be submitted 2 weeks
before the board meeting, to allow sufficient time for review and
submission (Wed, October 04).

Please submit your report with sufficient time to allow the Incubator
PMC, and subsequently board members to review and digest. Again, the
very latest you should submit your report is 2 weeks prior to the board
meeting.

Thanks,

The Apache Incubator PMC

Submitting your Report

--

Your report should contain the following:

*   Your project name
*   A brief description of your project, which assumes no knowledge of
 the project or necessarily of its field
*   A list of the three most important issues to address in the move
 towards graduation.
*   Any issues that the Incubator PMC or ASF Board might wish/need to be
 aware of
*   How has the community developed since the last report
*   How has the project developed since the last report.
*   How does the podling rate their own maturity.

This should be appended to the Incubator Wiki page at:

https://wiki.apache.org/incubator/October2017

Note: This is manually populated. You may need to wait a little before
this page is created from a template.

Mentors
---

Mentors should review reports for their project(s) and sign them off on
the Incubator wiki page. Signing off reports shows that you are
following the project - projects that are not signed may raise alarms
for the Incubator PMC.

Incubator PMC

Re: [VOTE] Release Rya (Incubating) version 3.2.11 RC3

[Josh Elser]

+1

* xsums/sigs OK
* Verified incompatibly licensed modules are optional
* Verified org.json is removed
* Git commit contained in scm
* KEYS contains pubkey of signer
* Can build from source

Good on you all to fix the licensing stuff right away!

On 9/26/17 1:27 PM, David Lotts wrote:

I am pleased to be calling this vote for the source release of Apache Rya
(Incubating), version 3.2.11.

The source zip, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/rya/rya-
incubating-3.2.11-rc3/


Ancillary artifacts such as poms, jars, wars. can be found here:
https://repository.apache.org/content/repositories/
orgapacherya-1008/org/apache/rya/rya-project/3.2.11-incubating/

The Git tag is rya-incubating-3.2.11-rc3
The Git commit ID is afe522412fb74cbb4ab97e1b7a8d1c112be33773
https://git-wip-us.apache.org/repos/asf?p=incubator-rya.git;a=commit;h=afe522412fb74cbb4ab97e1b7a8d1c112be33773


Checksums of rya-project-3.2.11-source-release.zip:
MD5: 3968cfb695a5740cac6acb3c33b702ca
SHA1: d601431c06d9adb3336c2913cc544bd9b43c0d7a
SHA512: b6ae761aa42f80e1cb84bb645184e29e4436eaaaf66aa7249aa65b6adb38
f3dfdd9a6f8b536eb0e2de88ac75cc2a0c8d97d85b4dd0ffef7f9407e05642110b3f

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/dlotts.asc

KEYS file available here:
https://dist.apache.org/repos/dist/release/incubator/rya/KEYS

Issues that were closed/resolved for this release are here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
ctId=12319020&version=12341279


The vote will be open for at least 72 hours starting Tuesday 2pm 9/26/2017
and close at Friday 9/29/2017 2pm Eastern Time USA.
Please download the release candidate and evaluate the necessary items
including checking hashes, signatures, build from source, and test.  Then
please vote:

[ ] +1 Release this package as rya-project-3.2.11
[ ] +0 no opinion
[ ] -1 Do not release this package because because...

Re: third party licenses examined for 3.2.11 RC2

[Josh Elser]

By the letter of the law, you don't have to resolve license conflicts 
until you graduate from the Incubator.


However, the process of identifying bad licensing, finding suitable 
replacements, and implementing such changes shows a _lot_ of maturity 
from the community (as this is a very real problem that comes up as 
projects grow!).


At the end of the day, it really comes down to how the voters cast their 
vote and I expect it would require some "fighting" over email.


For the specifics:

* HSQLDB, afaik, is ALv2. Maybe it's dual-licensed? That one should be 
no-problem.
* re: org.json, our Ted Dunning has made which other projects have 
successfully adopted. The barrier to switch is reportedly quite low 
https://github.com/tdunning/open-json
* Making the benchmarks module optional, like was done with the 
geoindexing module, is the most straightforward path. Google Caliper is 
more permissively licensed and could be leveraged as an alternatively in 
the future https://github.com/google/caliper


I would suggest to bite the bullet now.

On 9/14/17 1:15 PM, David Lotts wrote:

​Here is my completed analysis of our third party licenses.

Result: We have two Licenses not allowed for Apache projects.  See the
bottom.
The question is, is this a blocker for the release?  Can we make a Jira
task to fix for the next version?  One of them: JSON,  just  switched to
category X after our last release.

Using this history as a guide:
https://www.mail-archive.com/dev@rya.incubator.apache.org/msg00969.html
and this :
https://issues.apache.org/jira/browse/RYA-177

in order: the good, the bad:

### BSD  good  from:  http://asm.ow2.org/license.html
  (Unknown license) ASM Core (asm:asm:3.1 - http://asm.objectweb.org/asm/
)

### Good already excluded, see RYA-200 Remove findbugs:jsr305 Dependency
  (GNU Lesser Public License) FindBugs-Annotations
(com.google.code.findbugs:annotations:2.0.2 - http://findbugs.sourceforge.
net/)

### Apache project -- Good
  (Unknown license) commons-beanutils (commons-beanutils:commons-bea
nutils:1.7.0
- no url defined)

### Already exclusion from another library, its Good
  (HSQLDB License) HSQLDB (hsqldb:hsqldb:1.8.0.10 - http://hsqldb.org/)

### used by many Apache projects -- Good
  (Unknown license) servlet-api (javax.servlet:servlet-api:2.5 - no url
defined)
  (Unknown license) jsp-api (javax.servlet.jsp:jsp-api:2.1 - no url
defined)
  (Common Public License Version 1.0) JUnit (junit:junit:4.8.2 -
http://junit.org)

### BSD license -- good from http://www.antlr.org/about.html
  (Unknown license) Antlr 3.4 Runtime (org.antlr:antlr-runtime:3.4 -
http://www.antlr.org)

### Apache -- Good
  (Unknown license) Jettison (org.codehaus.jettison:jettison:1.1 - no
url defined)

### Apache licensed -- Good, all spring stuff
  (Unknown license) spring-aop (org.springframework:spring-ao
p:3.0.5.RELEASE)
  (Unknown license) spring-asm (org.springframework:spring-as
m:3.0.5.RELEASE)
  (Unknown license) spring-beans (org.springframework:spring-be
ans:3.0.5.RELEASE)
  (Unknown license) spring-context (org.springframework:spring-co
ntext:3.0.5.RELEASE)
  (Unknown license) spring-context-support (org.springframework:spring-co
ntext-support:3.0.7.RELEASE
  (Unknown license) spring-core (org.springframework:spring-co
re:3.0.5.RELEASE
  (Unknown license) spring-expression (org.springframework:spring-ex
pression:3.0.5.RELEASE
  (Unknown license) spring-tx (org.springframework:spring-tx
:3.0.5.RELEASE

### Apache project -- Good, BTW: As of 2010-09-01, the ORO project is
retired.
  (Unknown license) oro (oro:oro:2.0.8 - no url defined)
### Apache project -- Good, by looking at the source code
  (Unknown license) regexp (regexp:regexp:1.3 - no url defined)
### Apache licensed -- Good,
https://mvnrepository.com/artifact/org.osgi/org.osgi.compendium
  (Unknown license) org.osgi.compendium (org.osgi:org.osgi.compendium:
4.2.0)
  (Unknown license) org.osgi.core (org.osgi:org.osgi.core:4.2.0 )
### Python license is compat,  -- Good, similar to
http://www.jython.org/license.html
  (Jython Software License) Jython (org.python:jython:2.5.3 -
http://www.jython.org/)

## end of good.

### BAD: JSON: MIT- with evil clause
### As of 2016-11-03 this has been moved to the 'Category X' license list
### ( "The Software shall be used for Good, not Evil."  from
http://www.json.org/license.html   )
###  Consider replacing with this drop in replacement:
### https://mvnrepository.com/artifact/com.tdunning/json
### from: https://stackoverflow.com/questions/10396176/org-
json-jar-provisioning
### other alternatives:
### https://wiki.debian.org/qa.debian.org/jsonevil
   (provided without support or warranty) JSON (JavaScript Object Notation)
(org.json:json:20090211 - http://www.json.org/java/index.html)


### BAD: GPL with classpath exception is explicitly not compatible

  (GNU General Public License (GPL), version 2, with the C

Re: [VOTE] Release Rya (Incubating) version 3.2.11 RC2

[Josh Elser]

Yep. For the same reason that geoindexing module cannot be built by 
default (requires the user to acknowledge that they're using a library 
with this license), the benchmark module cannot be built by default.


Good catch folks.

On 9/13/17 3:57 PM, Jeff Dasch wrote:

Created RYA-370 to track the geoindexing profile bug and the renaming
recommendation.

My finding wrt the sesame-runtime-osgi pom is covered by RYA-8.  Ignoring
that for now.

Here's the current license check.  Are there any issues with the GNU
licenses here?
Apache Giraph seems to be providing the
com.google.code.findbugs:annotations:2.0.2
dependency.
Do we need to profile away the rya.benchmark project which provides the JMH
dependency?

$ mvn license:aggregate-add-third-party
$ egrep -iv "BSD|ASF|MIT|CDDL|EPL|Apache|ASL|Eclipse|Public Domain"
target/generated-sources/license/THIRD-PARTY.txt

Lists of 538 third-party dependencies.
  (Unknown license) ASM Core (asm:asm:3.1 - http://asm.objectweb.org/asm/
)
  (GNU Lesser Public License) FindBugs-Annotations
(com.google.code.findbugs:annotations:2.0.2 - http://findbugs.sourceforge.
net/)
  (Unknown license) commons-beanutils
(commons-beanutils:commons-beanutils:1.7.0
- no url defined)
  (HSQLDB License) HSQLDB (hsqldb:hsqldb:1.8.0.10 - http://hsqldb.org/)
  (Unknown license) servlet-api (javax.servlet:servlet-api:2.5 - no url
defined)
  (Unknown license) jsp-api (javax.servlet.jsp:jsp-api:2.1 - no url
defined)
  (Common Public License Version 1.0) JUnit (junit:junit:4.8.2 -
http://junit.org)
  (Unknown license) Antlr 3.4 Runtime (org.antlr:antlr-runtime:3.4 -
http://www.antlr.org)
  (Unknown license) Jettison (org.codehaus.jettison:jettison:1.1 - no
url defined)
  (provided without support or warranty) JSON (JavaScript Object
Notation) (org.json:json:20090211 - http://www.json.org/java/index.html)
  (GNU General Public License (GPL), version 2, with the Classpath
exception) JMH Core (org.openjdk.jmh:jmh-core:1.13 -
http://openjdk.java.net/projects/code-tools/jmh/jmh-core/)
  (GNU General Public License (GPL), version 2, with the Classpath
exception) JMH Generators: Annotation Processors
(org.openjdk.jmh:jmh-generator-annprocess:1.13
- http://openjdk.java.net/projects/code-tools/jmh/jmh-generator-annprocess/)
  (Unknown license) org.osgi.compendium (org.osgi:org.osgi.compendium:4.2.0
- no url defined)
  (Unknown license) org.osgi.core (org.osgi:org.osgi.core:4.2.0 - no url
defined)
  (Jython Software License) Jython (org.python:jython:2.5.3 -
http://www.jython.org/)
  (Unknown license) spring-aop (org.springframework:spring-aop:3.0.5.RELEASE
- no url defined)
  (Unknown license) spring-asm (org.springframework:spring-asm:3.0.5.RELEASE
- no url defined)
  (Unknown license) spring-beans
(org.springframework:spring-beans:3.0.5.RELEASE
- no url defined)
  (Unknown license) spring-context
(org.springframework:spring-context:3.0.5.RELEASE
- no url defined)
  (Unknown license) spring-context-support
(org.springframework:spring-context-support:3.0.7.RELEASE
- no url defined)
  (Unknown license) spring-core
(org.springframework:spring-core:3.0.5.RELEASE
- no url defined)
  (Unknown license) spring-expression
(org.springframework:spring-expression:3.0.5.RELEASE
- no url defined)
  (Unknown license) spring-tx (org.springframework:spring-tx:3.0.5.RELEASE
- no url defined)
  (Unknown license) oro (oro:oro:2.0.8 - no url defined)
  (Unknown license) regexp (regexp:regexp:1.3 - no url defined)

On Wed, Sep 13, 2017 at 10:45 AM, David Lotts  wrote:


, nexus seems to have a lot of geoindexing
artifacts in it.  Probably need to revist the extras/pom.xml as it
looks like there's a regression in there.


The last release 3.2.10 has no geoindexing jars in Nexus.  I see what you
are saying.  This release candidate has folders for each.
https://repository.apache.org/content/repositories/releases/
org/apache/rya/

  I unfortunately missed your renaming recommendation from your review.

  david.

On Wed, Sep 13, 2017 at 9:25 AM, Jeff Dasch  wrote:


Also, it appears that there is an issue with this project as well:

grep -r 3.2.10-incubating-SNAPSHOT rya-project-3.2.11-incubating
rya-project-3.2.11-incubating/osgi/sesame-runtime-osgi/pom.xml:
*3.2.10-incubating-SNAPSHOT*

On Wed, Sep 13, 2017 at 12:05 AM, Jeff Dasch  wrote:


It is fine to not to release the geoindexing artifacts, but we need all

of

the pom version strings to be consistent (and correct) so that if one

did

want to build them with the geoindexing profile, they can.

Speaking of artifacts, nexus seems to have a lot of geoindexing

artifacts

in it.  Probably need to revist the extras/pom.xml as it looks like

there's

a regression in there.



On Tue, Sep 12, 2017 at 10:22 PM, Puja Valiyil 

wrote:



Don't we not release the geoindexing artifacts? Sorry if I'm being

slow

here

Sent from my iPhone


On Sep 12, 2017, at 5:23 PM, Jeff Dasch  wrote:

-

Re: [RESULT] [VOTE] Release Rya (Incubating) version 3.2.11 RC1

[Josh Elser]

Just catching up -- thanks for turning around those changes so quickly! 
The fixes look good to me. Great work!


On 9/8/17 5:38 PM, David Lotts wrote:

Hello,

The vote to release Rya (Incubating) version 3.2.11 RC1 has failed.

-1 (binding): Josh Elser
+0 (non binding): Jeff Dasch

The following Jira tasks have been created to capture the issues blocking a
successful release.
We have fixed all the following which should take care of all of the
feedback, with the exception of Adina's which perhaps we can address in a
future release or perhaps RC3.

RYA-360 [1]  Header issues: Correct Notice file year, fix wrong Apache
License, s/RYA/Apache Rya/ in the README  pull request #222  [2]
This task fixes three issues:
 - wrong license header (including a copyright line which should not be
present)
 - Copyright year in NOTICE needs updating
 - s/RYA/Apache Rya/ in the README

RYA-361 [3] Remove JCalendar library from merge/copy/export #224 [4]
 - rya.export depends on JCalendar which is LGPL (brought in by RYA-123)

RYA-362 [5] Improve no-arg error message for shell command create-pcj  #223
[6]
 - UX nit on the rya.shell

The following Jira task has been created to capture all of the issues that
will be resolved in the next RC:
  RYA-367 Perform 3.2.11-RC2 Release [7]

Release candidate #2 (3.2.11-RC2) should be coming out  Monday.
Thanks for all the hard work!


[1] https://issues.apache.org/jira/browse/RYA-360
[2] https://github.com/apache/incubator-rya/pull/222
[3] https://issues.apache.org/jira/browse/RYA-361
[4] https://github.com/apache/incubator-rya/pull/224
[5] https://issues.apache.org/jira/browse/RYA-362
[6] https://github.com/apache/incubator-rya/pull/223
[7] https://issues.apache.org/jira/browse/RYA-367

david.
​

Re: [VOTE] Release Rya (Incubating) version 3.2.11 RC1

[Josh Elser]

Yes, policy states that generated sources can omit license headers. 
However, it's also nice to just automate license headers being added and 
not have to make goofy exclusions to work around it :)


I think the major concern at the moment is that plugin which is 
generating a copyright line too (sounds like the plugin is meant for 
applying the Apache License, not necessarily applying the AL at the ASF).


On 9/6/17 1:12 PM, Jeff Dasch wrote:

Billie,

We also have some generated source (jaxb related) that is getting an Apache
License header with a copyright line to The Apache Software Foundation from
the org.codehaus.mojo:license-maven-plugin.  Does generated source fall
under the category of "A file without any degree of creativity" [1] that
does not require a license header?

[1] https://www.apache.org/legal/src-headers.html





On Wed, Sep 6, 2017 at 11:44 AM, Billie Rinaldi 
wrote:


On Tue, Sep 5, 2017 at 6:29 PM, Puja Valiyil  wrote:


Hey Billie,
Are we using the rat plugin properly?  I would have thought that would

have

caught the bad header.



The file has an Apache license header, but it's not the ASF license header,
which is why it wouldn't be flagged. Also, rat does not check for copyright
lines.




On Tue, Sep 5, 2017 at 7:40 PM, Billie Rinaldi 

wrote:



This file has the wrong license header (including a copyright line

which

should not be present):
extras/rya.export/export.client/src/main/java/org/apache/rya
/export/client/conf/TimeUtils.java

Signature, checksums, disclaimer look good, and the source zip matches

the

tag. I was able to build from source and the unit tests passed. I

haven't

done a full dependency analysis yet.

On Fri, Sep 1, 2017 at 10:08 PM, David Lotts  wrote:


I am pleased to be calling this vote for the source release of Apache

Rya

(Incubating), version 3.2.11.
Since I am sending this on the eve of a holiday weekend in the USA,

we'll

start the vote on Tuesday, although voting early is fine.

The source zip, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/rya/rya-

incubating-3

.2.11-rc1/

Ancillary artifacts such as poms, jars, wars, ect. can be found here:
https://repository.apache.org
/content/repositories/orgapacherya-1005/org/apache/rya/rya-project/3
.2.11-incubating/

The Git tag is rya-incubating-3.2.11-rc1
The Git commit ID is 2588d189d483698c0d2cd30e1e7c28f18c3d6871
https://git-wip-us.apache.org/repos/asf
?p=incubator-rya.git;a=commit;h=2588d189d483698c0d2cd30e1e7c28

f18c3d6871


Checksums of rya-project-3.2.10-source-release.zip:
SHA1: f40fe200b6768076d28ccd7b3d613ff6
MD5: f40fe200b6768076d28ccd7b3d613ff6

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/dlotts.asc

KEYS file available here:
https://dist.apache.org/repos/dist/release/incubator/rya/KEYS

Issues that were closed/resolved for this release are here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?
projectId=12319020&version=12341279
(This is very incomplete as many items are yet to be tagged for the
release.  I'll take care of that after the Labor day Monday along

with

release notes for the website.)

The vote will be open for at least 72 hours starting Tuesday

9/12/2017

and

close at 9/15/2017 Noon Eastern Time USA.
Please download the release candidate and evaluate the necessary

items

including checking hashes, signatures, build from source, and test.

Then

please vote:

[ ] +1 Release this package as rya-project-3.2.11
[ ] +0 no opinion
[ ] -1 Do not release this package because because...

Re: [VOTE] Release Rya (Incubating) version 3.2.11 RC1

[Josh Elser]

-1 (binding)

* rya.export depends on JCalendar which is LGPL [1] (brought in by RYA-123)
* Copyright year in NOTICE needs updating
* Nit: s/RYA/Apache Rya/ in the README

Everything else looks ok at first glance.

[1] https://toedter.com/jcalendar/

On 9/2/17 1:08 AM, David Lotts wrote:

I am pleased to be calling this vote for the source release of Apache Rya
(Incubating), version 3.2.11.
Since I am sending this on the eve of a holiday weekend in the USA, we'll
start the vote on Tuesday, although voting early is fine.

The source zip, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/rya/rya-incubating-3
.2.11-rc1/

Ancillary artifacts such as poms, jars, wars, ect. can be found here:
https://repository.apache.org
/content/repositories/orgapacherya-1005/org/apache/rya/rya-project/3
.2.11-incubating/

The Git tag is rya-incubating-3.2.11-rc1
The Git commit ID is 2588d189d483698c0d2cd30e1e7c28f18c3d6871
https://git-wip-us.apache.org/repos/asf
?p=incubator-rya.git;a=commit;h=2588d189d483698c0d2cd30e1e7c28f18c3d6871

Checksums of rya-project-3.2.10-source-release.zip:
SHA1: f40fe200b6768076d28ccd7b3d613ff6
MD5: f40fe200b6768076d28ccd7b3d613ff6

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/dlotts.asc

KEYS file available here:
https://dist.apache.org/repos/dist/release/incubator/rya/KEYS

Issues that were closed/resolved for this release are here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319020&version=12341279
(This is very incomplete as many items are yet to be tagged for the
release.  I'll take care of that after the Labor day Monday along with
release notes for the website.)

The vote will be open for at least 72 hours starting Tuesday 9/12/2017 and
close at 9/15/2017 Noon Eastern Time USA.
Please download the release candidate and evaluate the necessary items
including checking hashes, signatures, build from source, and test.  Then
please vote:

[ ] +1 Release this package as rya-project-3.2.11
[ ] +0 no opinion
[ ] -1 Do not release this package because because...

Re: Loading tab spaced data

[Josh Elser]

Hi Matteo,

Thanks for the bug-report. Do you have an interest in making the change 
to Rya to address this issue? :)


In open source projects, we like to encourage users to make changes to 
"scratch their own itch". Please let us know how we can help enable you 
to make this change.


On 8/25/17 8:45 AM, Matteo Cossu wrote:

Hello,
I have some problems in loading the data with the Map Reduce code provided.
I am using this class: *org.apache.rya.accumulo.mr.tools.RdfFileInputTool .*
When my input data is in N-Triples format and the triples are tab separated
instead of spaces, I get this error:

*org.openrdf.rio.RDFParseException: Expected '<', found: m*
I solved by substituting all the tabs with spaces in my input data, but
since tabs are a possible separator in the N-Triples format, I think this
should be implemented (or fixed) directly within the tool.

Kind Regards,
Matteo Cossu

Re: NiFi processor for Rya ingestion

[Josh Elser]

That's pretty cool, Jeff! Thank you for sharing.

This sounds like a great addition to Apache Rya to me. Perhaps I can 
convince one of the other devs to step up and try to help shepherd this 
in? (otherwise, I'll try to make the time to do it *winks*)


On 7/22/17 8:06 AM, Jeff Zemerick wrote:

In my use case I want to ingest into Rya through a NiFi pipeline so I put
together a NiFi processor that facilitates ingest through Rya's API. It's
nothing too fancy but it does work. I don't know how applicable it might be
to other users. If there is interest I have no problems donating it to your
project.

https://github.com/mtnfog/rya-ingest-nifi-processor

Jeff

Re: Rya's state

[Josh Elser]

Thanks for volunteering, David!

The short answer is that you don't do it via github.com, but just commit 
the change like you would any other contribution.


My typical workflow is to access the GH pull requests HEADs behind 
Github maintains behind the scenes[1] and include the magic text to 
automatically close the PR when it hits the repository's master branch[2].


The long answer is that Gitbox[3] would provide the ability to use 
Github for all that it provides, but this requires a bit of "doing" to 
accomplish.


[1] https://help.github.com/articles/checking-out-pull-requests-locally/
[2] https://help.github.com/articles/closing-issues-via-commit-messages/
[3] https://gitbox.apache.org/

On 7/11/17 6:06 PM, David Lotts wrote:

I'm going to add our release to the download page.
How does one get karma to merge pull requests?
I need it for github
*apache/incubator-rya-site *or do I need to do it from the Apache Git repo?
It has a PR for a bad link that I'd like to merge.

For the download page, I'll do a proper PR so we can review before we merge
and publish it.
david.

On Fri, Jul 7, 2017 at 5:07 PM, Josh Elser  wrote:


Oh good catch, Dave! I didn't even notice that the website was never
updated.

Can someone volunteer to look into this over the weekend, please?


On 7/5/17 2:38 PM, Dave Fisher wrote:


Hi -

I’m doing a quick shepherd check of Rya.

I look at http://rya.incubator.apache.org/download/ and it does not
provide ANY information about your release last October. That really does
not help the project build a community. Please look into your website and
give it the care it needs.

Regards,
Dave

On 2017-07-05 10:32 (-0700), Josh Elser  wrote:


Hi,

Sorry for being a bit more hands-off as of late. Professional and
personal life has been quite ramped up for me :). Looking over the July
2017 report, it made me wonder what the next steps for Rya are and how I
can help push you all in this process!

* What is the next release?
 - What would be contained?
 - What's left to be implemented?
 - When should it be released by?
* Who is in the pipeline to be invited to committer (rhetorical -- these
discussions _must_ happen in private@)
* What contributions need help/shephering? I saw one[1] in a quick glance

- Josh

[1] https://github.com/apache/incubator-rya/pull/171

Re: Test Rya

[Josh Elser]

Hi David,

There is no hard-and-fast timeline on how long a project stays in 
incubation at the Apache Software Foundation. Some projects graduate in 
6-9 months, others incubate for years.


Rya's first release (3.2.10) can be found using the available ASF 
mirrors https://www.apache.org/dyn/closer.cgi, or specifically 
http://apache.cs.utah.edu/incubator/rya/rya-incubating-3.2.10/. Be sure 
to use the signatures and checksums found at 
https://dist.apache.org/repos/dist/release/incubator/rya/rya-incubating-3.2.10/ 
when downloading from the mirrors.


We're in the process of updating the website with some instructions to 
capture this info for the future. Thanks for your interest!


- Josh

On 7/7/17 6:59 PM, david.new...@wellsfargo.com.INVALID wrote:

Rya is very exciting.  When will the incubation period be complete?   How can 
we obtain the software to test?

Thanks,

David Newman
Strategic Planning Manager
Senior Vice President
Innovation Group
Wells Fargo Bank
david.new...@wellsfargo.com
Office: (415) 801-8418
Cell:(925) 788-0529

This message may contain confidential and/or privileged information.  If you 
are not the addressee or authorized to receive this for the addressee, you must 
not use, copy, disclose, or take any action based on this message or any 
information herein.  If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message.  Thank you for 
your cooperation.

Re: Rya's state

[Josh Elser]

Oh good catch, Dave! I didn't even notice that the website was never 
updated.


Can someone volunteer to look into this over the weekend, please?

On 7/5/17 2:38 PM, Dave Fisher wrote:

Hi -

I’m doing a quick shepherd check of Rya.

I look at http://rya.incubator.apache.org/download/ and it does not provide ANY 
information about your release last October. That really does not help the 
project build a community. Please look into your website and give it the care 
it needs.

Regards,
Dave

On 2017-07-05 10:32 (-0700), Josh Elser  wrote:

Hi,

Sorry for being a bit more hands-off as of late. Professional and
personal life has been quite ramped up for me :). Looking over the July
2017 report, it made me wonder what the next steps for Rya are and how I
can help push you all in this process!

* What is the next release?
- What would be contained?
- What's left to be implemented?
- When should it be released by?
* Who is in the pipeline to be invited to committer (rhetorical -- these
discussions _must_ happen in private@)
* What contributions need help/shephering? I saw one[1] in a quick glance

- Josh

[1] https://github.com/apache/incubator-rya/pull/171

Rya's state

[Josh Elser]

Hi,

Sorry for being a bit more hands-off as of late. Professional and 
personal life has been quite ramped up for me :). Looking over the July 
2017 report, it made me wonder what the next steps for Rya are and how I 
can help push you all in this process!


* What is the next release?
  - What would be contained?
  - What's left to be implemented?
  - When should it be released by?
* Who is in the pipeline to be invited to committer (rhetorical -- these 
discussions _must_ happen in private@)

* What contributions need help/shephering? I saw one[1] in a quick glance

- Josh

[1] https://github.com/apache/incubator-rya/pull/171

Re: Podling Report Reminder - July 2017

[Josh Elser]

https://lists.apache.org/thread.html/14fbb6ec756261cd522a4a17db74453d8382d117041af9995620e44a@%3Cdev.rya.apache.org%3E

;)

On 6/30/17 9:17 AM, Meier, Caleb wrote:

Adina is on vacation until the end of July.  So she is unavailable to work on 
it.

Caleb A. Meier, Ph.D.
Software Engineer II ♦ Analyst
Parsons Corporation
1911 N. Fort Myer Drive, Suite 800 ♦ Arlington, VA 22209
Office:  (703)797-3066
caleb.me...@parsons.com ♦ www.parsons.com

-Original Message-
From: Puja Valiyil [mailto:puja...@gmail.com]
Sent: Thursday, June 29, 2017 9:14 PM
To: dev@rya.incubator.apache.org
Subject: Re: Podling Report Reminder - July 2017

Has anyone started working on this or would like to volunteer to put it 
together?  I didn't see anything from Adina saying if she had been working on 
it or not.

Sent from my iPhone


On Jun 29, 2017, at 8:51 PM, johndam...@apache.org wrote:

Dear podling,

This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.

The board meeting is scheduled for Wed, 19 July 2017, 10:30 am PDT.
The report for your podling will form a part of the Incubator PMC
report. The Incubator PMC requires your report to be submitted 2 weeks
before the board meeting, to allow sufficient time for review and
submission (Wed, July 05).

Please submit your report with sufficient time to allow the Incubator
PMC, and subsequently board members to review and digest. Again, the
very latest you should submit your report is 2 weeks prior to the
board meeting.

Thanks,

The Apache Incubator PMC

Submitting your Report

--

Your report should contain the following:

*   Your project name
*   A brief description of your project, which assumes no knowledge of
the project or necessarily of its field
*   A list of the three most important issues to address in the move
towards graduation.
*   Any issues that the Incubator PMC or ASF Board might wish/need to be
aware of
*   How has the community developed since the last report
*   How has the project developed since the last report.
*   How does the podling rate their own maturity.

This should be appended to the Incubator Wiki page at:

https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.apache.org_i
ncubator_July2017&d=CwIFAg&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq
10&r=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8&m=flalrOvFDeLMSCH8lQT
PrIxrM9msw2zGlvhUVqX5zHw&s=Bg6BsDNSH_cDn72IjWIW2yBbeUafd1Q8Q6QSIO21hm4
&e=

Note: This is manually populated. You may need to wait a little before
this page is created from a template.

Mentors
---

Mentors should review reports for their project(s) and sign them off
on the Incubator wiki page. Signing off reports shows that you are
following the project - projects that are not signed may raise alarms
for the Incubator PMC.

Incubator PMC

Re: Podling Report Reminder - July 2017

[Josh Elser]

I can help out with the logistics if someone wants to take on the cross 
of word-smithing. There are plenty of good previous reports[1] to take 
inspiration from :)


[1] https://wiki.apache.org/incubator/January2017

On 6/28/17 2:05 AM, Adina Crainiceanu wrote:

Rya enthusiasts,

Is anyone volunteering to work on the next board report due July 5th? I'm
traveling while on vacation.
For the community development section of the report, I would be include the
2 Rya talks I gave at Apache Big Data North America on May 16-18 in Miami:
a 10 minutes presentation at the  Podling Shark Tank, and a full
presentation on Apache Rya - A Scalable RDF Triple Store.

Adina

On Wed, Jun 28, 2017 at 2:54 AM  wrote:


Dear podling,

This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.

The board meeting is scheduled for Wed, 19 July 2017, 10:30 am PDT.
The report for your podling will form a part of the Incubator PMC
report. The Incubator PMC requires your report to be submitted 2 weeks
before the board meeting, to allow sufficient time for review and
submission (Wed, July 05).

Please submit your report with sufficient time to allow the Incubator
PMC, and subsequently board members to review and digest. Again, the
very latest you should submit your report is 2 weeks prior to the board
meeting.

Thanks,

The Apache Incubator PMC

Submitting your Report

--

Your report should contain the following:

*   Your project name
*   A brief description of your project, which assumes no knowledge of
 the project or necessarily of its field
*   A list of the three most important issues to address in the move
 towards graduation.
*   Any issues that the Incubator PMC or ASF Board might wish/need to be
 aware of
*   How has the community developed since the last report
*   How has the project developed since the last report.
*   How does the podling rate their own maturity.

This should be appended to the Incubator Wiki page at:

https://wiki.apache.org/incubator/July2017

Note: This is manually populated. You may need to wait a little before
this page is created from a template.

Mentors
---

Mentors should review reports for their project(s) and sign them off on
the Incubator wiki page. Signing off reports shows that you are
following the project - projects that are not signed may raise alarms
for the Incubator PMC.

Incubator PMC

Re: can't assign issue to self

[Josh Elser]

Getting the workflow change likely requires an INFRA ask. If it's 
something you all want to pursue, go for it.


Otherwise, we can make sure enough committers have karma to add new 
contributors and do it by hand (like this case).


Jonathan Wonders wrote:

The last message I saw on the mailing list involved manual addition of
users to the group.  From a newcomers perspective, this seems like an
acceptable process as long as how to request addition/assignment is
documented along with the contributing instructions.

On Wed, May 3, 2017 at 7:11 PM, Puja Valiyil  wrote:


I can assign the ticket but was this ever resolved?  I think the
resolution last time was to add people to a Jira user set manually.

Sent from my iPhone


On May 3, 2017, at 7:04 PM, Jonathan Wonders

wrote:

Hi All,

I'm looking to pick up issue RYA-67 but cannot self-assign based on not
being in the contributors group.  There was a similar question on the
mailing list last year but the contributing page doesn't currently

mention

this detail.  It would be helpful to newcomers if the instructions were
updated accordingly.  I'll create an issue for updating the

documentation,

but in the meantime, would it be possible for someone to assign me the

task

or add me to the contributors group?

Thanks,
--Jonathan

Re: draft of ASF Board Report for Rya - please comment

[Josh Elser]

My only comment is to be a bit more concrete on the number of 
contributions you have received from non-committers (e.g. how many 
unique contributors and number of contributions total). This helps to 
show what the pipeline on your community-building looks like.


Otherwise, lgtm. Thanks for putting it together, Adina!

Adina Crainiceanu wrote:

Hi,

I started the Podling report to ASF. This is due Wednesday. Please let me
know of any additions/modifications. I want to submit a draft tomorrow and
then we can modify further if needed on Wednesday.

Thank you,
Adina

Rya

Rya (pronounced "ree-uh" /rēə/) is a cloud-based RDF triple store that
supports SPARQL queries. Rya is a scalable RDF data management system built
on top of Accumulo. Rya uses novel storage methods, indexing schemes, and
query processing techniques that scale to billions of triples across
multiple nodes. Rya provides fast and easy access to the data through
SPARQL, a conventional query mechanism for RDF data.

Rya has been incubating since 2015-09-18.

Three most important issues to address in the move towards graduation:

  1. Have more releases as part of the Apache Foundation
  2. Increase diversity of contributors.
  3. Continue to harden and develop core Rya features to improve user
experience

Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware
of?

  No

How has the community developed since the last report?

  * Talk on Rya accepted at ApacheCon Big Data, May 18, 2017
  * PRs from non-committers which are integrated into the repository
continue to be received

How has the project developed since the last report?

  * Resolved a handful of issues that users have encountered
  * Committed features: Added support for select * {?s ?p ?o} queries
(select all triples). Implemented MongoDB based entity secondary index.
Added MongoDB column visibility. Fixed column visibilities in Fluo. Added
GeoWave, in addition to GeoMesa, to the optional rya.geoindexing. Added
statement metadata optimizer so  that reified queries can be issued in an
efficient way.

How would you assess the podling's maturity?
Please feel free to add your own commentary.

   [ ] Initial setup
   [ ] Working towards first release
   [x] Community building
   [ ] Nearing graduation
   [ ] Other:

Date of last release:

  Oct 28, 2016

When were the last committers or PMC members elected?

  New committer and PPMC member David Lotts elected on Oct 25, 2016
  New PPMC member Caleb Meier elected on Jan 3rd, 2017

Signed-off-by:

   [ ](rya) Josh Elser
  Comments:
   [ ](rya) Edward J. Yoon
  Comments:
   [ ](rya) Venkatesh Seetharam
  Comments:
   [ ](rya) Billie Rinaldi
  Comments:

IPMC/Shepherd notes:

Re: master is in a bad state.

[Josh Elser]

Good catch folks! :)

Aaron D. Mihalik wrote:

ah, "asfbot build" builds "with optional" and that masked the rat issues
with just a normal build.  gotcha.

On Mon, Mar 13, 2017 at 11:54 AM Puja Valiyil  wrote:


Sorry -- this is me.  Well, more like this is me trusting the build server
too much -- the optionals build passes.  Andrew is on it.

On Mon, Mar 13, 2017 at 11:39 AM, Aaron D. Mihalik<
aaron.miha...@gmail.com>
wrote:


Is someone working on this?

RAT doesn't like this file:

Unapproved licenses:

   /home/jenkins/jenkins-slave/workspace/incubator-rya-
master/extras/rya.pcj.fluo/rya.pcj.functions.geo/src/
main/resources/META-INF/services/org.openrdf.query.
algebra.evaluation.function.Function

failed build: https://builds.apache.org/job/incubator-rya-master/67/
console

-- Forwarded message -
From: Apache Jenkins Server
Date: Mon, Mar 13, 2017 at 11:31 AM
Subject: incubator-rya-master - Build # 67 - Failure
To:


The Apache Jenkins build system has built incubator-rya-master (build

#67)

Status: Failure

Check console output at
https://builds.apache.org/job/incubator-rya-master/67/ to view the
results.

Re: article about Rya on Navy website

[Josh Elser]

So cool, Adina! Thanks for sharing :)

Adina Crainiceanu wrote:

An article about Rya has been posted on the Dept of Navy Innovation page:

http://www.secnav.navy.mil/innovation/Pages/2017/02/ApacheRya.aspx

Thank you to all who made this possible (both Rya and the article).
Adina

Re: ApacheCon submissions due today - request for comments

[Josh Elser]

LGTM!

I'd think ApacheCon Big Data would be the logical choice, but I'm not 
100% sure.


Adina Crainiceanu wrote:

Hi,

The deadline for submitting a talk for ApacheCon is today, and I decided to
submit a talk for Rya. If anyone can offer any comments, please let me
know. This is the first time I'm submitting to ApacheCon.

Montors, maybe you have some advice, whether we should submit to ApacheCon
versus ApacheCon Big Data? I was thinking to submit to Big Data, but I'm
not 100% sure that is the right choice.

Thank you,
Adina


*Title *

Apache Rya – A scalable RDF Triple store

or

Introducing Apache Rya



*Abstract (900 chars or less)*

Apache Rya (incubating) is a scalable database management system designed
for storing and searching large amounts of Resource Description Framework
(RDF) data. In its most basic form, RDF data is a  triple. Due to its flexibility, RDF is the standard of choice for
storing a large variety of information. With tremendous increases in data
sizes available, scalable solutions needed to be devised to efficiently
store and query very large RDF graphs within big data architectures. Apache
Rya is an RDF triple store build on top of Apache Accumulo. In this talk,
we present storage methods, indexing schemes, query optimization, and query
evaluation techniques that allow Rya to scale to billions of triples across
multiple nodes, while providing fast and easy access to the data through
conventional query mechanisms such as SPARQL.





*Describe who the audience is and what you expect them to gain from your
presentation*

The audience is anyone interested in RDF, cloud, and database management
systems. Attendees will be introduced to RDF and SPARQL, the query language
commonly used with RDF data, and they will gain an understanding of how Rya
stores and indexes data, as well as how query optimization and processing
is done in Rya.



*Tell us how the content of your presentation will help better the Linux
and open source ecosystem*

The presentation will introduce a new Apache incubator project, Apache Rya.
The presentation will help publicize the project, help existing and future
users gain an understanding of the system, and encourage developers to get
involved in the project.

Re: answered: RAT complains about tinkerpop.rya

[Josh Elser]

David/Kiet,

Can either of you share the report file that RAT generates (in target/) 
for the given module where it failed? This describes what failed the check.


Like Puja says, this shouldn't be happening under normal circumstances. 
It's something that was verified before the first release.


Puja Valiyil wrote:

Fresh checkouts shouldn't have any rat errors-- it's building with rat
enabled on apaches build servers.

On Wednesday, January 18, 2017, Ly, Kiet  wrote:


I just used mvn clean install -DskipTests -Drat.skip=true. Master branch
has a lot of rat errors.

On 1/18/17, 5:43 PM, "David Lotts">
wrote:

 If your maven build err's with RAT complaints about  tinkerpop.rya then
 delete it.

 The sub-project formerly known as "tinkerpop.rya" has recently been
removed
 from master. There is a new tinkerpop sub-project under a different
name, I
 think.

 Anyway, I discovered that git won't delete the folder on checkout (in a
 previously used git clone) because it had a "target" subfolder, which
is
 explicitly ignored.

 So manually remove tinkerpop.rya:
  rm -rf  ./extras/tinkerpop.rya

 And RAT will no longer complain.

 david.



Confidentiality Notice::  This email, including attachments, may include
non-public, proprietary, confidential or legally privileged information.
If you are not an intended recipient or an authorized agent of an intended
recipient, you are hereby notified that any dissemination, distribution or
copying of the information contained in or transmitted with this e-mail is
unauthorized and strictly prohibited.  If you have received this email in
error, please notify the sender by replying to this message and permanently
delete this e-mail, its attachments, and any copies of it immediately.  You
should not retain, copy or use this e-mail or any attachment for any
purpose, nor disclose all or any part of the contents to any other person.
Thank you.

Re: accumulo native memory setting

[Josh Elser]

How did your data-loading job fail? This is a Accumulo server 
configuration property -- it has no direct impact on your client.


4G should be fine, just make sure that you have sufficient physical 
memory on the Accumulo TabletServer hosts.


Ly, Kiet wrote:

Has anyone used the native memory setting and found it stable enough for 
production used?  I found the data loading job crashed randomly after I turned 
it on. May be my setting was wrong elsewhere?


 tserver.memory.maps.max
 4G
   

   
 tserver.memory.maps.native.enabled
 true
   

Confidentiality Notice::  This email, including attachments, may include 
non-public, proprietary, confidential or legally privileged information.  If 
you are not an intended recipient or an authorized agent of an intended 
recipient, you are hereby notified that any dissemination, distribution or 
copying of the information contained in or transmitted with this e-mail is 
unauthorized and strictly prohibited.  If you have received this email in 
error, please notify the sender by replying to this message and permanently 
delete this e-mail, its attachments, and any copies of it immediately.  You 
should not retain, copy or use this e-mail or any attachment for any purpose, 
nor disclose all or any part of the contents to any other person. Thank you.

Re: Should Rya have a Twitter account?

[Josh Elser]

Since the responses have been mostly positive, I've just gone ahead and 
created an account.


I am happy to transfer ownership of the actual account to anyone, as 
well as add anyone to the "team" via tweetdeck to be able to interact 
with the account.


https://twitter.com/apacherya

Ly, Kiet wrote:

It is great and free marketing. Definitely should open an account. Appoint a 
social maven POC from one of the committers.

On 1/11/17, 9:58 AM, "David Lotts"  wrote:

 Should Rya have a Twitter account?
 Lets discuss it.
 Who would manage it?  How to manage the password?
 david.



Confidentiality Notice::  This email, including attachments, may include 
non-public, proprietary, confidential or legally privileged information.  If 
you are not an intended recipient or an authorized agent of an intended 
recipient, you are hereby notified that any dissemination, distribution or 
copying of the information contained in or transmitted with this e-mail is 
unauthorized and strictly prohibited.  If you have received this email in 
error, please notify the sender by replying to this message and permanently 
delete this e-mail, its attachments, and any copies of it immediately.  You 
should not retain, copy or use this e-mail or any attachment for any purpose, 
nor disclose all or any part of the contents to any other person. Thank you.

Re: Fwd: Should Rya have a Twitter account?

[Josh Elser]

Using tweetdeck, you can let multiple people have access to the account.

It's worked well for Accumulo so far.

David Lotts wrote:

Should Rya have a Twitter account?
Lets discuss it.
Who would manage it?  How to manage the password?
david.

Re: January podling report draft - please comment

[Josh Elser]

I think the great work that many of you were involved in to deal with 
the incompatibly-licensed geospatial dependencies would be good to 
mention in addition to the successful release.


Otherwise it looks pretty good to me.

Adina Crainiceanu wrote:

Hi all,

Happy New Year!! I hope everyone had a chance to enjoy the holidays.

Below is the first draft of the podling report due on January 4th. Any
comments and suggestions are welcome.


Rya

Rya (pronounced "ree-uh" /rēə/) is a cloud-based RDF triple store that
supports SPARQL queries. Rya is a scalable RDF data management system built
on top of Accumulo. Rya uses novel storage methods, indexing schemes, and
query processing techniques that scale to billions of triples across
multiple nodes. Rya provides fast and easy access to the data through
SPARQL, a conventional query mechanism for RDF data.

Rya has been incubating since 2015-09-18.

Three most important issues to address in the move towards graduation:

  1. Have more releases as part of the Apache Foundation
  2. Increase diversity of contributors.

Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware
of?

  No

How has the community developed since the last report?

  * New committer and PPMC member, David Lotts,  was invited and accepted to
join Apache Rya PPMC.
  * Sean Busbey resigned as mentor
  * Billie Rinaldi became a mentor for Rya
  * Talk on Rya at Accumulo Summit, October 11, 2016
  * PRs from non-committers which are integrated into the repository
continue to be received

How has the project developed since the last report?

  * We had the first release as part of the ASF
  * Resolved a handful of issues that users have encountered
  * Committed features: implemented new commands for Rya console: AddUser
(give perimssions to users for the tables associated with Rya instance),
RemoveUser , Uninstall, LoadStatementsFile. Added merge tool to allow
cloning between Mongo and Accumulo instances. Added initial Spark support.

Date of last release:

  Oct 28, 2016

When were the last committers or PMC members elected?

  New committer and PPMC member David Lotts elected on Oct 25, 2016

Signed-off-by:

   [ ](rya) Josh Elser
   [ ](rya) Edward J. Yoon
   [ ](rya) Venkatesh Seetharam
   [ ](rya) Billie Rinaldi


Shepherd/Mentor notes:

Re: Fwd: Do i need a jira ticket for changes to the Rya web site?

[Josh Elser]

JIRA issues typically remain open until the change has been resolved (as 
there may be back-and-forth on code review for non-trivial changes).


Sit tight and Aaron (or whoever) will help close things up when it's 
pulled in :)


Ben Kapp wrote:

Should I resolve this issue in Jira now that I have a pull request for it?
Or ought I wait until the pull request has been merged in?

On Fri, Dec 16, 2016 at 6:56 AM, Aaron D. Mihalik
wrote:


John: Thanks for the catch and the pr!

Adina: Yeah, I'll take a look at it ... I was in the middle of updating the
site for the release and to fix some issues I was having with jekyll.  I'll
pick that up again this weekend.

--Aaron

On Fri, Dec 16, 2016 at 8:29 AM Adina Crainiceanu  wrote:


Hi, I'm going on vacation today and I did not have time to merge this. If
someone wants to merge it, please do so, otherwise I'll merge it when I
return in Jan.
Happy Holidays to everyone!

Adina

On Thu, Dec 15, 2016 at 2:39 PM, Josh Elser

wrote:

One little trick, if you name your pull request starting with the JIRA
identifier, "RYA-228", the PR will get automatically linked on the JIRA
issue :)





The change LGTM






John Smith wrote:




Jira issue created


https://issues.apache.org/jira/browse/RYA-228





Pull request


https://github.com/apache/incubator-rya-site/pull/1





Does this look proper?





-- Forwarded message --


From: Puja Valiyil


Date: Wed, Dec 14, 2016 at 11:41 AM


Subject: Re: Do i need a jira ticket for changes to the Rya web site?


To: dev@rya.incubator.apache.org








I think a jira ticket and then add Adina as a watcher.  She knows the


process for updating (I'm not sure everyone has permissions but I might

be


wrong).





Sent from my iPhone







On Dec 14, 2016, at 2:25 PM, John Smith   wrote:





There is a broken link on the Rya web site and I'd like to push a fix for


it.  How do I do this?  Do i need to create a jira ticker or is that just


for source code changes?  How do I submit a pull request for website


changes?












--
Dr. Adina Crainiceanu
Associate Professor, Computer Science Department
United States Naval Academy
410-293-6822<(410)%20293-6822>
ad...@usna.edu
http://www.usna.edu/Users/cs/adina/

Re: Fwd: Do i need a jira ticket for changes to the Rya web site?

[Josh Elser]

One little trick, if you name your pull request starting with the JIRA 
identifier, "RYA-228", the PR will get automatically linked on the JIRA 
issue :)


The change LGTM

John Smith wrote:

Jira issue created
https://issues.apache.org/jira/browse/RYA-228

Pull request
https://github.com/apache/incubator-rya-site/pull/1

Does this look proper?

-- Forwarded message --
From: Puja Valiyil
Date: Wed, Dec 14, 2016 at 11:41 AM
Subject: Re: Do i need a jira ticket for changes to the Rya web site?
To: dev@rya.incubator.apache.org


I think a jira ticket and then add Adina as a watcher.  She knows the
process for updating (I'm not sure everyone has permissions but I might be
wrong).

Sent from my iPhone


On Dec 14, 2016, at 2:25 PM, John Smith  wrote:

There is a broken link on the Rya web site and I'd like to push a fix for
it.  How do I do this?  Do i need to create a jira ticker or is that just
for source code changes?  How do I submit a pull request for website
changes?

Re: LGPL Compatability (again) for Direct vs. Transitive Dependencies

[Josh Elser]

Yes, direct or transitive dependencies have no bearing on the 
application of the license or ASF policy.


Remember, the phrasing of the policy is important: "[you may not bundle 
any products which are category-X]" (probably a bad time to not quote 
directly, but hopefully my point gets across nonetheless).


The "optional dependencies" is the only relevant caveat here (and I'll 
avoid re-hashing in depth as I think it was pretty clear last time). If 
the Geo-Indexing module that Rya provides is 'optional', the dependency 
is OK, but I believe you still must not bundle it (e.g. uber.jar) in a 
release, it would be something users can build themselves if they accept 
the terms of the lgpl.


- Josh

Aaron D. Mihalik wrote:

As we discussed before, a direct dependency on a LGPL licensed jar is
prohibited, but are transitive dependencies prohibited?

For instance, Rya Geoindexing depends on Geomesa (Apache 2.0 licensed) and
Geomesa depends on Geotools (LGPL licensed).  I believe that we get into
trouble in Rya Geoindexing for two reasons:

1. We build an uber jar that contains the Geotools jars.
2. The Rya Geoindexing source code directly uses (or "links") to classes
contained in Geotools.

If we were able to eliminate 1 and 2 (but still have Geomesa and Geotools
as transitive dependencies), could we include Rya Geoindexing in the
release?

Thanks,
Aaron

Rya use-cases on website

[Josh Elser]

Hiya folks,

I had a coworker ask me over the weekend about Rya. He was a little 
confused over why someone might want to use Rya. This is the sort of 
thing that is great to write once on the website and refer people to. 
It's also a great "recruiting" tool for the project.


These are the types of questions I'd focus on trying to answer:

* The "bread and butter" use case examples. The one or two 
application-level things that Rya does *very well*.

* What are some application-level things that Rya does well?
* What about Rya's architecture make it novel/unique/desirable?
* What does Rya do better than its competitors (avoiding bashing the 
competition)?

* What other software complements Rya?

Does anyone have some spare cycles to look into this? I'm happy to do 
some copy editing, but I don't feel comfortable writing this up myself.


- Josh

New mentor

[Josh Elser]

Hiya folks,

Just an FYI that you'll see a new name around helping out as a mentor: 
Billie Rinaldi.


I know that some of you already know/have met Billie in person. I'm very 
glad she volunteered to spend some of her precious time with us :)


- Josh

Re: Importing BSD 3-Clause

[Josh Elser]

And for license headers: 
https://www.apache.org/legal/src-headers.html#3party


See specifically the comments about "minor" and "major" modifications.

Josh Elser wrote:

Also, for reference:
http://www.apache.org/dev/licensing-howto.html#permissive-deps

Aaron D. Mihalik wrote:

Great info. Thanks Josh!

On Wed, Nov 2, 2016 at 4:57 PM, Josh Elser wrote:


Aaron D. Mihalik wrote:


Mentors,

We have a PR [1] that imports existing code from another project and
the
code is BSD 3-Clause Licensed.


Make sure that the LICENSE file for any artifact that Rya is
re-distributing this code in to include the 3-clause BSD license and
state
where you copied it from.

What's the process for including a slightly


modified version of this source code into Rya?


This isn't a licensing question, but a copyright question. When is the
change you made "sufficiently unique" from the original work? Easy to
air
on the side of caution and retain its origins since it's permissively
licensed.

I did a bit of research into other Apache projects and it seems like
this

is fine if we keep the original copy right notices on the files
(example
of
the original file here [2]). And then we modify our LICENSE file like
thrift did here [3].


If there is a copyright notice on the file you are copying, you must
*not*
remove this. You would still apply the ASL header for your
modifications,
but you must leave the original licensing information in place.

The PR has the update to the NOTICE file here [4] and LICENSE file
here [5]

and kept the original copy right notices on the source file (example
here
[6] ... note that the PR will remove the Apache 2.0 license on that
file
soon).

From a licensing perspective, is that sufficient to pull in this code?
(Is
this the correct place for this question or should I move it somewhere
else?)


I'll take a look at the links you provided on GH and comment there.


--Aaron


[1] https://github.com/apache/incubator-rya/pull/106
[2]
https://github.com/afs/JenaSesame/blob/master/src/org/
openjena/jenasesame/impl/BulkUpdateHandlerNoIterRemove.java
[3] https://github.com/apache/thrift/blob/0.9.3/LICENSE#L204
[4]
https://github.com/apache/incubator-rya/blob/66a948e2ad71e0b
6fb2e3c0060d78d133b5e198d/NOTICE#L15
[5]
https://github.com/apache/incubator-rya/blob/66a948e2ad71e0b
6fb2e3c0060d78d133b5e198d/LICENSE#L213
[6]
https://github.com/apache/incubator-rya/blob/66a948e2ad71e0b
6fb2e3c0060d78d133b5e198d/extras/rya.jena.sesame/src/
main/java/org/apache/rya/jena/jenasesame/impl/BulkUpdateHand
lerNoIterRemove.java#L19

Re: Importing BSD 3-Clause

[Josh Elser]

Also, for reference: 
http://www.apache.org/dev/licensing-howto.html#permissive-deps


Aaron D. Mihalik wrote:

Great info.  Thanks Josh!

On Wed, Nov 2, 2016 at 4:57 PM, Josh Elser  wrote:


Aaron D. Mihalik wrote:


Mentors,

We have a PR [1] that imports existing code from another project and the
code is BSD 3-Clause Licensed.


Make sure that the LICENSE file for any artifact that Rya is
re-distributing this code in to include the 3-clause BSD license and state
where you copied it from.

   What's the process for including a slightly


modified version of this source code into Rya?


This isn't a licensing question, but a copyright question. When is the
change you made "sufficiently unique" from the original work? Easy to air
on the side of caution and retain its origins since it's permissively
licensed.

I did a bit of research into other Apache projects and it seems like this

is fine if we keep the original copy right notices on the files (example
of
the original file here [2]). And then we modify our LICENSE file like
thrift did here [3].


If there is a copyright notice on the file you are copying, you must *not*
remove this. You would still apply the ASL header for your modifications,
but you must leave the original licensing information in place.

The PR has the update to the NOTICE file here [4] and LICENSE file here [5]

and kept the original copy right notices on the source file (example here
[6] ... note that the PR will remove the Apache 2.0 license on that file
soon).

  From a licensing perspective, is that sufficient to pull in this code?
(Is
this the correct place for this question or should I move it somewhere
else?)


I'll take a look at the links you provided on GH and comment there.


--Aaron


[1] https://github.com/apache/incubator-rya/pull/106
[2]
https://github.com/afs/JenaSesame/blob/master/src/org/
openjena/jenasesame/impl/BulkUpdateHandlerNoIterRemove.java
[3] https://github.com/apache/thrift/blob/0.9.3/LICENSE#L204
[4]
https://github.com/apache/incubator-rya/blob/66a948e2ad71e0b
6fb2e3c0060d78d133b5e198d/NOTICE#L15
[5]
https://github.com/apache/incubator-rya/blob/66a948e2ad71e0b
6fb2e3c0060d78d133b5e198d/LICENSE#L213
[6]
https://github.com/apache/incubator-rya/blob/66a948e2ad71e0b
6fb2e3c0060d78d133b5e198d/extras/rya.jena.sesame/src/
main/java/org/apache/rya/jena/jenasesame/impl/BulkUpdateHand
lerNoIterRemove.java#L19

Re: Importing BSD 3-Clause

[Josh Elser]

Aaron D. Mihalik wrote:

Mentors,

We have a PR [1] that imports existing code from another project and the
code is BSD 3-Clause Licensed.


Make sure that the LICENSE file for any artifact that Rya is 
re-distributing this code in to include the 3-clause BSD license and 
state where you copied it from.


  What's the process for including a slightly

modified version of this source code into Rya?


This isn't a licensing question, but a copyright question. When is the 
change you made "sufficiently unique" from the original work? Easy to 
air on the side of caution and retain its origins since it's 
permissively licensed.



I did a bit of research into other Apache projects and it seems like this
is fine if we keep the original copy right notices on the files (example of
the original file here [2]). And then we modify our LICENSE file like
thrift did here [3].


If there is a copyright notice on the file you are copying, you must 
*not* remove this. You would still apply the ASL header for your 
modifications, but you must leave the original licensing information in 
place.



The PR has the update to the NOTICE file here [4] and LICENSE file here [5]
and kept the original copy right notices on the source file (example here
[6] ... note that the PR will remove the Apache 2.0 license on that file
soon).

 From a licensing perspective, is that sufficient to pull in this code?  (Is
this the correct place for this question or should I move it somewhere
else?)


I'll take a look at the links you provided on GH and comment there.


--Aaron


[1] https://github.com/apache/incubator-rya/pull/106
[2]
https://github.com/afs/JenaSesame/blob/master/src/org/openjena/jenasesame/impl/BulkUpdateHandlerNoIterRemove.java
[3] https://github.com/apache/thrift/blob/0.9.3/LICENSE#L204
[4]
https://github.com/apache/incubator-rya/blob/66a948e2ad71e0b6fb2e3c0060d78d133b5e198d/NOTICE#L15
[5]
https://github.com/apache/incubator-rya/blob/66a948e2ad71e0b6fb2e3c0060d78d133b5e198d/LICENSE#L213
[6]
https://github.com/apache/incubator-rya/blob/66a948e2ad71e0b6fb2e3c0060d78d133b5e198d/extras/rya.jena.sesame/src/main/java/org/apache/rya/jena/jenasesame/impl/BulkUpdateHandlerNoIterRemove.java#L19

Re: Post-3.2.10 release steps (was Re: [RESULT] [VOTE] Release Rya (Incubating) version 3.2.10 RC3)

[Josh Elser]

Cool! Thanks for the update, Aaron. I primarily wanted to make sure the 
final steps were clear.


I'd encourage you (all) to put some real english behind the release 
notes so it's clear what this version of Rya does (and why people should 
care).


Anyone else should feel free to pick up the slack before you have time 
(per usual ASF dev), but I'd leave the privilege of making the 
announcement to you since you did most of the lifting :)


Aaron D. Mihalik wrote:

Thanks Josh... I was holding off on the announce email until I had the
update to the website ready to go.  I'm a bit slammed today, so I haven't
gotten to it yet.  I'll probably have time on Wednesday :/

As for release notes, I was going to have some standard release boilerplate
and the JIRA generated release notes [1].

The Rya site is now mirrored on github [2] and I'll put up a PR there.  If
someone has time to update the website, I can toss up a PR for my
half-finished update, but it's a bit messy right now.

--Aaron



[1]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12334209&styleName=Html&projectId=12319020
[2] https://github.com/apache/incubator-rya-site


On Mon, Oct 31, 2016 at 12:54 PM Josh Elser  wrote:

Congrats on the first release, folks!

Aaron, don't forget to send out the ANNOUNCE message (as the artifacts
should be replicated to the mirrors by now).

Make sure that the announce includes:

* The proper name, something like "Apache Rya (incubating) 3.2.10" or
"Apache Rya 3.2.10-incubating".
* A brief explanation of what Rya is
* Where users can find information about the release
* The "under incubation" disclaimer boilerplate

Do ensure that you send from your apache.org message as the message to
annou...@apache.org will (likely?) be rejected otherwise. Has anyone put
together release notes on the website?

Aaron D. Mihalik wrote:

Hello,

The vote to release Rya (Incubating) version 3.2.10 RC3 has passed with 3
+1 votes.

+1 (binding):

Josh Elser
Seetharam Venkatesh
Sergio Fernández

I will promote the artifacts to the central repo and copy them to
dist/release

--Aaron

Post-3.2.10 release steps (was Re: [RESULT] [VOTE] Release Rya (Incubating) version 3.2.10 RC3)

[Josh Elser]

Congrats on the first release, folks!

Aaron, don't forget to send out the ANNOUNCE message (as the artifacts 
should be replicated to the mirrors by now).


Make sure that the announce includes:

* The proper name, something like "Apache Rya (incubating) 3.2.10" or 
"Apache Rya 3.2.10-incubating".

* A brief explanation of what Rya is
* Where users can find information about the release
* The "under incubation" disclaimer boilerplate

Do ensure that you send from your apache.org message as the message to 
annou...@apache.org will (likely?) be rejected otherwise. Has anyone put 
together release notes on the website?


Aaron D. Mihalik wrote:

Hello,

The vote to release Rya (Incubating) version 3.2.10 RC3 has passed with 3
+1 votes.

+1 (binding):

Josh Elser
Seetharam Venkatesh
Sergio Fernández

I will promote the artifacts to the central repo and copy them to
dist/release

--Aaron

Re: [VOTE] Release Apache Rya (Incubating) version 3.2.10 RC3

[Josh Elser]

(Forwarding from ppmc)

+1 (binding)

Aaron D. Mihalik wrote:

The Apache Rya community has voted and approved the proposed release of
Apache Rya 3.2.10 (Incubating) RC3.

We now kindly request the Incubator PMC members review and vote on this
incubator release.

Rya (pronounced "ree-uh" /rēə/) is a cloud-based RDF triple store that
supports SPARQL queries. Rya is a scalable RDF data management system built
on top of Apache Accumulo®. Rya uses novel storage methods, indexing
schemes, and query processing techniques that scale to billions of triples
across multiple nodes. Rya provides fast and easy access to the data
through SPARQL, a conventional query mechanism for RDF data. More
information can be found at http://rya.incubator.apache.org/

[VOTE] Thread:
https://lists.apache.org/thread.html/01d692717b2ee088253fa96c42759309a2a4d2aaf9867905bc473fa7@%3Cdev.rya.apache.org%3E

[VOTE] [RESULT] Thread:
https://lists.apache.org/thread.html/e58e7456987d74f11a0698fd5d4dde436bd83016baa269c149f03511@%3Cdev.rya.apache.org%3E

The source zip, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/rya/rya-incubating-3.2.10-rc3/


Ancillary artifacts such as poms, jars, wars, ect. can be found here:
https://repository.apache.org/content/repositories/orgapacherya-1004/org/apache/rya/rya-project/3.2.10-incubating/


The Git tag is rya-incubating-3.2.10-rc3

The Git commit ID is 66d8b7f060bddeeb7c50cb0918f98ce3b265c564
https://git-wip-us.apache.org/repos/asf?p=incubator-rya.git;a=commit;h=66d8b7f060bddeeb7c50cb0918f98ce3b265c564


Checksums of rya-project-3.2.10-incubating-source-release.zip:
SHA1: 4468f55b9f381e9103ca1e2e9c25b30e1cad4ed0
MD5: a28d9a146857576903ff4fc3f7dae908

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/mihalik.asc

KEYS file available here:
https://dist.apache.org/repos/dist/release/incubator/rya/KEYS

Issues that were closed/resolved for this release are here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12334209&styleName=Html&projectId=12319020

The vote will be open for 72 hours and closes at Fri Oct 28 16:00 EDT 2016.

Please download the release candidate and evaluate the necessary items
including checking hashes, signatures, build from source, and test.

Then please vote:
[ ] +1 Release this package as rya-project-3.2.10-incubating
[ ] +0 no opinion
[ ] -1 Do not release this package because because...

--Aaron

Re: [VOTE] Release Rya (Incubating) version 3.2.10 RC3

[Josh Elser]

+1

* Sig/Xsums OK, but you have no other signatures on your key to verify 
that the key used to sign these artifacts is actually your key, Aaron. 
Maybe you can find someone (in person or via phone) or who can your key 
for you? [1]

* Verified that geoindexing is "off"
* Cursory glance over dependencies getting bundled in shaded JARs and 
they look OK

* Listed commit exists in the repo
* L&N look correct for source release
* DISCLAIMER present
* Could build from source (`mvn package`)

Overview on your website:

* "Apache Rya (incubating) is a scalable RDF triple store built on top 
of a columnar index store (Accumulo)." Apache Accumulo®, please.

* Required links are present to ASF
* Incubator branding looks good (to my memory)
* "Apache Rya (incubating)" is prominent too.

Other things:

* Noticed lots of warnings in your Maven project. Would be good to 
address this to reduce the likelihood of build issues by users. [2]
* Nit: would be good to include when the 72hrs is "up" (with tz) instead 
of relying on the timestamp that the message landed in

someone's inbox.
* Got an error running a `mvn install` (since your dependency graph 
seems to be busted -- couldn't run a `mvn dependency:tree` without as I 
should be able to). [3] Rerunning it was fine the second time..
* Maintaining your shaded jars over time is probably a losing battle (if 
the licensing issues this time around weren't sign enough). I'd suggest 
you start putting some thought in how your source-release creates 
binaries that can be useful for people who want to run Rya but are not 
using the exact versions of all of the dependencies you're bundling for 
them.
* I didn't inspect the JARs you're also distributing for licensing 
correctness. Will let this slide since for now :)


- Josh

[1] https://www.apache.org/dev/release-signing.html#web-of-trust
[2] https://paste.apache.org/CQf3
[3] https://paste.apache.org/ssGd

Aaron D. Mihalik wrote:

I am pleased to be calling this vote for the source release of Apache Rya
(Incubating), version 3.2.10.

The source zip, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/rya/rya-incubating-3.2.10-rc3/

Ancillary artifacts such as poms, jars, wars, ect. can be found here:
https://repository.apache.org/content/repositories/orgapacherya-1004/org/apache/rya/rya-project/3.2.10-incubating/

The Git tag is rya-incubating-3.2.10-rc3
The Git commit ID is 66d8b7f060bddeeb7c50cb0918f98ce3b265c564
https://git-wip-us.apache.org/repos/asf?p=incubator-rya.git;a=commit;h=66d8b7f060bddeeb7c50cb0918f98ce3b265c564

Checksums of rya-project-3.2.10-source-release.zip:
SHA1: 4468f55b9f381e9103ca1e2e9c25b30e1cad4ed0
MD5: a28d9a146857576903ff4fc3f7dae908

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/mihalik.asc

KEYS file available here:
https://dist.apache.org/repos/dist/release/incubator/rya/KEYS

Issues that were closed/resolved for this release are here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12334209&styleName=Html&projectId=12319020

Issues resolved between RC1 and RC2 are here:
https://issues.apache.org/jira/browse/RYA-184

Issues resolved between RC2 and RC3 are here:
https://issues.apache.org/jira/browse/RYA-209

The vote will be open for 72 hours.
Please download the release candidate and evaluate the necessary items
including checking hashes, signatures, build from source, and test.  The
please vote:

[ ] +1 Release this package as rya-project-3.2.10
[ ] +0 no opinion
[ ] -1 Do not release this package because because...

Re: Move to Travis-CI?

[Josh Elser]

(disclaimer, I really have no opinion at all about which system is used, 
just providing context)


Aaron D. Mihalik wrote:

Devs,

We now have Jenkins (builds.apache.org) building master and all PRs. This
is awesome, but I think we could do a bit more.

How do you all feel about moving to Travis-CI? It seems like it'll give us
more functionality than Jenkins, many other Apache projects use it, and
it'll be more reliable than builds.apache.org. However, it'll require a
special request to INFRA.


Travis is not wholly more reliable than Jenkins on builds.a.o. If a 
build starts failing on Travis, you pretty much have no remediation at 
all. At least with Jenkins, you have some escalation because they are 
machines that the ASF controls.



Specially, the purpose of moving to Travis-CI would be to gain more
information about our code base, it's "health", and how PRs coming in may
effect it. I think Travis-CI has a couple of key features:

- Travis-CI builds all branches and PRs, and maintains all of the history
(no artifacts) for those builds. Right now Jenkins will only retain the
last few builds across all builds. This is kinda annoying if you want to
investigate why an older PR failed.


This might just be configuration on retention? You should have the karma 
to modify the job to change the number of jobs retained. Or someone with 
VP karma could grant it to you.


Not sure if you have it wired up, but the ASF Jenkins can also be 
configured to build PRs and report back to GH. Not clear to me if you 
knew about that.



- Travis-CI integrates with other tools (eg coveralls.io) that will allow
us to track and explore other facets of our code (coveralls does code
coverage). It seems like Apache supports coveralls, but there are other
integrations (eg coverity scan) that might be useful as well.


If a Jenkins plugin exists, INFRA can be bothered to try to get them to 
install it. INFRA may object depending on the stability of the plugin 
though.



- Travis-CI provides a nice dashboard for looking at the build history for
the project.

What do you all think? I'm new to Travis-CI and many of these other tools,
so if someone else has more experience, please chime in.

Thanks,
Aaron

Re: checklist for release

[Josh Elser]

Ps, I'd recommend getting this up onto the Rya website :)

David Lotts wrote:

Some additional detail:

Here's a checklist for things to consider when evaluating the release

candidate:

1. Download the sources and verify they compile cleanly.

2. Validate the hashes match.

3. Validate that the sources contain no unexpected binaries.
Run the find/grep command:  find . -type f  | grep -v
'\/test\/\|\/site\/\|\.java\|\.xml\|\.xsl\|\.groovy\|\.
properties\|\.sh\|\.bat\|\.md\|\.txt'
which looks for all files that don't have one of the approved extensions.

4. Validate the signature for the build and hashes.
Verify .asc files found at [1] using the Aaron's public key: [2]  Then
verify hashes of these files.


Here are the commands: [3]

a. Install GPG.
b. import Aaron's key from Apache [2]:
 gpg --keyserver
https://dist.apache.org/repos/dist/dev/incubator/rya/KEYS --recv-key
F50EAE1A

c. Download the files at [1] and run this in that folder:
 gpg --verify rya-project-3.2.10-incubating-source-release.zip.asc

If you see "*Good signature*" from the verify, that is good enough as long
as you feel strongly that you have Aaron's real public key.  To eliminate
the warning, either trust Aaron's key "ultimately" or let it find a trusted
path to a key that you trust ultimately.

[1] https://repository.apache.org/content/repositories/
orgapacherya-1002/org/apache/rya/rya-project/3.2.10-incubating/
[2] https://dist.apache.org/repos/dist/release/incubator/rya/KEYS
[3]  https://httpd.apache.org/dev/verification.html


5. Validate the LICENSE/NOTICE/Headers.
Verify that each project contains the ASF license and notice files.
Run the grep command:  fgrep -Ri 'copyright' rya-project-3.2.10 | fgrep -v
'The ASF licenses this file'
This should return only License and Notice files in rya-project-3.2.10.
The license files
and the notice files should be consistent with the ASF license and ASF
copyright statement.  Verify that only
the notice files contains the ASF copyright statement.

Re: findbugs-annotations?

[Josh Elser]

My understanding is that you would still use javax.annotation.Nullable 
(or any defined in JSR-305) in the code and then the implementation you 
provide on the classpath would satisfy the implementation. Have you 
tried out removing the findbugs version for the stephenc version at 
runtime to see if things explode?


re: Phoenix, looks like I need to bash more heads. I had a multi-day 
event recently fixing their licensing, but it appears that you found 
something I had missed. Thanks for pointing it out. I think maybe the 
findbugs dependency was just not removed...


https://github.com/apache/phoenix/blob/master/phoenix-core/pom.xml#L277-L280

Aaron D. Mihalik wrote:

Josh,

I put up a PR to move Rya to findbugs-annotations [1]. Besides removing
some annotations, the biggest change was to go from "import
javax.annotation.Nullable" to "import
edu.umd.cs.findbugs.annotations.Nullable".  Does that look correct?

I went over to Apache Phoenix to see how they deal with the package names
for the findbugs-annotations, and it appears that Phoenix still uses
"javax.annotation.Nullable" and has a direct dependency on findbugs:jsr305
[2].

--Aaron

[1] https://github.com/apache/incubator-rya/pull/115
[2] https://github.com/apache/phoenix/blob/master/pom.xml#L864


On Mon, Oct 17, 2016 at 2:58 PM Aaron D. Mihalik
wrote:


I meant "fluo has a transitive dependency on findbugs:jsr305". I agree
that findbugs-annotations is good and jsr305 is bad.

On Mon, Oct 17, 2016 at 2:51 PM Puja Valiyil  wrote:

Yea findbugs-annotations is not LGPL:
https://github.com/stephenc/findbugs-annotations
It appears to be apache 2, though aaron you should verify.

On Mon, Oct 17, 2016 at 11:19 AM, Aaron D. Mihalik<
aaron.miha...@gmail.com>
wrote:


fluo has a transitive dependency on findbugs-annotations, not direct.

My issue is that

com.github.stephenc.findbugs:findbugs-annotations:3.0.1-1

isn't in maven central.  I think it would be straightforward for us to
exclude and replace with c.g.s.f:findbugs-annotations:3.0.1-1, but it's
going to be difficult with earlier versions of
c.g.s.f:findbugs-annotations.

I'll take a closer look at it today, though.

--Aaron


On Sun, Oct 16, 2016 at 5:51 PM Josh Elser  wrote:


Also, over in Apache Phoenix, we're using
com.github.stephenc.findbugs:findbugs-annotations:1.3.9-1. Maybe I gave
some bad advice on the GAV to use the first time around :)

Josh Elser wrote:

A (Maven) repo? It's published central -- you shouldn't have to do
anything extra to get it. Sonatype is automatically mirrored to

central

(like Apache is).

Also, Fluo is depending on this directly? Or just transitively? I am
hoping I did not miss it directly depending...

No, it's not ok :). You're bundling code whose license is dodgy.

Either

way you need to exclude the Findbugs' findbugs-annotations from these
dependencies. Whether or not you replace in

c.g.s.f:findbugs-annotations

instead is up to you (not sure if you would run into problems)

Aaron D. Mihalik wrote:

Anyone know where I can find a repo for this artifact:

com.github.stephenc.findbugs:findbugs-annotations:3.0.1-1

stephenc lists the Repositories here [1] but I can't find the latest
release in those mentioned repos (i.e. here [2] or here [3])

I don't think we'll have this resolved for RC2, but I'm hoping

that's

okay
because other projects depend on findbugs:jsr305 (i.e. hadoop and

fluo).

--Aaron


[1]


http://stephenc.github.io/findbugs-annotations/

distribution-management.html

[2]


https://oss.sonatype.org/content/repositories/releases/

com/github/stephenc/findbugs/findbugs-annotations/

[3]


https://repo.maven.apache.org/maven2/com/github/stephenc/

findbugs/findbugs-annotations/

Re: [VOTE] Release Rya (Incubating) version 3.2.10 RC2

[Josh Elser]

Sorry! I should have been more clear and used fewer emoticons.

I'll try to take a look at rc2 today for some feedback before rc3.

Aaron D. Mihalik wrote:

-1 We're still including findbugs.

I'm sorry everyone.  I misread Josh's earlier email [1] and thought it was
okay to continue to include findbugs for our first release,  I'll take a
look at upgrading/changing findbugs and make an RC3 very soon.

If anyone has feedback for RC2, I'd appreciate hearing it and we'll include
any additional changes in RC3.

--Aaron

[1] I misread "No, it's not ok :)" as "No, it's ok :)"

On Sun, Oct 16, 2016 at 11:41 PM Aaron D. Mihalik
wrote:


I am pleased to be calling this vote for the source release of Apache Rya
(Incubating), version 3.2.10.

The source zip, including signatures, digests, etc. can be found at:

https://dist.apache.org/repos/dist/dev/incubator/rya/rya-incubating-3.2.10-rc2/

Ancillary artifacts such as poms, jars, wars, ect. can be found here:

https://repository.apache.org/content/repositories/orgapacherya-1002/org/apache/rya/rya-project/3.2.10-incubating/

The Git tag is rya-incubating-3.2.10-rc2
The Git commit ID is 9f0d63e6089df172eb3f41957d2956ec0035953a

https://git-wip-us.apache.org/repos/asf?p=incubator-rya.git;a=commit;h=9f0d63e6089df172eb3f41957d2956ec0035953a

Checksums of rya-project-3.2.10-source-release.zip:
SHA1: 5f91b695e5bebfa89eee27debfca7a264f81f888
MD5: 5199aee4ca11e3c735f6e8b40f563f09

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/mihalik.asc

KEYS file available here:
https://dist.apache.org/repos/dist/release/incubator/rya/KEYS

Issues that were closed/resolved for this release are here:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12334209&styleName=Html&projectId=12319020

Issues resolved between RC1 and RC2 are here:
https://issues.apache.org/jira/browse/RYA-184

The vote will be open for 72 hours.
Please download the release candidate and evaluate the necessary items
including checking hashes, signatures, build from source, and test.  The
please vote:

[ ] +1 Release this package as rya-project-3.2.10
[ ] +0 no opinion
[ ] -1 Do not release this package because because...

Re: SCM tagging conventions

[Josh Elser]

Precisely. Some sort of v3.2.10-rcX during voting with the creation of 
rel/v3.2.10 after the ppmc and ipmc votes pass.


Meier, Caleb wrote:

Given that you cannot delete the tag "rel/", what are the tagging 
conventions that people use throughout the release process?
Obviously you don't want the tag for an RC to be rel in the event that you have 
to create a new RC and delete the old tag.  Is the convention to just
create an RC tag, and once an RC passes vote then create the "rel/" 
tag?

-Original Message-
From: Josh Elser [mailto:josh.el...@gmail.com]
Sent: Friday, October 14, 2016 6:00 PM
To: dev@rya.incubator.apache.org
Subject: Re: SCM tagging conventions

Yeah, making a release with a SNAPSHOT version doesn't make any sense (as 
SNAPSHOTs are explicitly for non-released versions of software).

At the ASF, the only thing to be aware of is that the final Git tag should be 
"rel/
What are the conventions for SCM tags?  Josh, was the issue that you had with 
our tag that is was v3.2.10-SNAPSHOT as opposed to either v3.2.10 or just 
3.2.10?  I want to close out RYA-182, but first I want to understand what the 
issue was.

Re: findbugs-annotations?

[Josh Elser]

Also, over in Apache Phoenix, we're using 
com.github.stephenc.findbugs:findbugs-annotations:1.3.9-1. Maybe I gave 
some bad advice on the GAV to use the first time around :)


Josh Elser wrote:

A (Maven) repo? It's published central -- you shouldn't have to do
anything extra to get it. Sonatype is automatically mirrored to central
(like Apache is).

Also, Fluo is depending on this directly? Or just transitively? I am
hoping I did not miss it directly depending...

No, it's not ok :). You're bundling code whose license is dodgy. Either
way you need to exclude the Findbugs' findbugs-annotations from these
dependencies. Whether or not you replace in c.g.s.f:findbugs-annotations
instead is up to you (not sure if you would run into problems)

Aaron D. Mihalik wrote:

Anyone know where I can find a repo for this artifact:

com.github.stephenc.findbugs:findbugs-annotations:3.0.1-1

stephenc lists the Repositories here [1] but I can't find the latest
release in those mentioned repos (i.e. here [2] or here [3])

I don't think we'll have this resolved for RC2, but I'm hoping that's
okay
because other projects depend on findbugs:jsr305 (i.e. hadoop and fluo).

--Aaron


[1]
http://stephenc.github.io/findbugs-annotations/distribution-management.html

[2]
https://oss.sonatype.org/content/repositories/releases/com/github/stephenc/findbugs/findbugs-annotations/

[3]
https://repo.maven.apache.org/maven2/com/github/stephenc/findbugs/findbugs-annotations/

Re: findbugs-annotations?

[Josh Elser]

A (Maven) repo? It's published central -- you shouldn't have to do 
anything extra to get it. Sonatype is automatically mirrored to central 
(like Apache is).


Also, Fluo is depending on this directly? Or just transitively? I am 
hoping I did not miss it directly depending...


No, it's not ok :). You're bundling code whose license is dodgy. Either 
way you need to exclude the Findbugs' findbugs-annotations from these 
dependencies. Whether or not you replace in c.g.s.f:findbugs-annotations 
instead is up to you (not sure if you would run into problems)


Aaron D. Mihalik wrote:

Anyone know where I can find a repo for this artifact:

com.github.stephenc.findbugs:findbugs-annotations:3.0.1-1

stephenc lists the Repositories here [1] but I can't find the latest
release in those mentioned repos (i.e. here [2] or here [3])

I don't think we'll have this resolved for RC2, but I'm hoping that's okay
because other projects depend on findbugs:jsr305 (i.e. hadoop and fluo).

--Aaron


[1]
http://stephenc.github.io/findbugs-annotations/distribution-management.html
[2]
https://oss.sonatype.org/content/repositories/releases/com/github/stephenc/findbugs/findbugs-annotations/
[3]
https://repo.maven.apache.org/maven2/com/github/stephenc/findbugs/findbugs-annotations/

Re: SCM tagging conventions

[Josh Elser]

Yeah, making a release with a SNAPSHOT version doesn't make any sense 
(as SNAPSHOTs are explicitly for non-released versions of software).


At the ASF, the only thing to be aware of is that the final Git tag 
should be "rel/deleted.


Meier, Caleb wrote:

What are the conventions for SCM tags?  Josh, was the issue that you had with 
our tag that is was v3.2.10-SNAPSHOT as opposed to either v3.2.10 or just 
3.2.10?  I want to close out RYA-182, but first I want to understand what the 
issue was.

Re: [DISCUSS] Path forward for release

[Josh Elser]

Thanks for putting this together, Puja. I don't see the geotools related 
issues anymore.


I took a glance at another JAR that a `mvn package` creates this time:

extras/indexing/target/rya.indexing-3.2.10-SNAPSHOT-accumulo-server.jar

In here, I found: hep/aida/bin/AbstractBin.class

Per https://dst.lbl.gov/ACSSoftware/colt/license.html, code in the 
hep/aida package are licensed as LGPL.


It's really important to understand *all* of the dependencies that 
you're using when you're creating these massive shaded jars...


./extras/rya.merger/target/rya.merger-3.2.10-SNAPSHOT-shaded.jar also 
has the same issue. It appears like it is coming in via tinkerpop-blueprints


[INFO] +- org.apache.rya:rya.sail:jar:3.2.10-SNAPSHOT:compile
[INFO] |  +- com.tinkerpop.blueprints:blueprints-core:jar:2.5.0:compile
[INFO] |  |  \- colt:colt:jar:1.2.0:compile
[INFO] |  | \- concurrent:concurrent:jar:1.3.4:compile

com.google.code.findbugs:jsr305 coming in via hadoop-common (yes, Hadoop 
screwed up) is also bad. This is an easy fix to exclude this dependency 
and add in com.github.stephenc.findbugs:findbugs-annotations instead.


Puja Valiyil wrote:

Hi everyone,
I put up a pull request Friday for. making geoindexing an optional profile
( https://github.com/apache/incubator-rya/pull/101).  It pulls out
geoindexing into a separate project, and there are some obvious next steps
that we could punt to the next release that I list out in the pr.
If no one sees any issues it would be good to move forward with merging
this and going forward with another release candidate.


On Monday, October 10, 2016, Josh Elser>  wrote:


Yup, you got it right, Caleb (given my current interpretation, anyways
:P). The incubator proposal[1] should have called out these dependencies to
begin with. I think this is why this is such a "shock".

Working under the assumption that GeoIndexing is the "tainted fruit" and
we call it optional, I think there is merit in making a release,
acknowledging that it needs work and that it is not entirely at the spirit
of "optional". Getting familiarity with how to make a release is extremely
important. End of the day, this is something that needs to be addressed
prior to graduation. I'm think I'm OK with suggesting that geoindexing is
optional to kick the problem down the road for a first release, but I want
to make sure it doesn't get repeatedly kicked. This should be an extremely
high priority to resolve.

In fewer words: if reworking the indexing to modularize the Geo-related
pieces is something someone can volunteer to do right now, great. That is
the ideal path forward. If it's going to take month(s) to do, I think
punting for one release is OK.

[1] https://wiki.apache.org/incubator/RyaProposal#External_Dependencies

Meier, Caleb wrote:


So just make sure I'm clear with what you said, I'll attempt to
summarize.  For the purposes of a release, it's okay to include source code
for components that have improperly licensed, Runtime dependencies, so long
as they are "optional" and turned off by default.  But when we actually
deploy our artifacts, we need to exclude the jars for all components that
have improperly licensed dependencies.  So in effect, any components that
have improperly licensed dependencies need to be truly optional from a
build perspective -- have an optional build profile -- and should not be
built and deployed by default.

What we are currently working on is making geoindexing optional from a
build perspective.  We're separating it out from the indexing project so
that it can have its own, optional build profile.  If what I said above is
correct, it seems like there is no way around this, other than making the
entire indexing project optional.  But that would be like throwing the baby
out with the bath water.

From: Josh Elser [els...@apache.org]
Sent: Monday, October 10, 2016 10:26 AM
To: dev@rya.incubator.apache.org
Subject: Re: [DISCUSS] Path forward for release

Ok, I put some more thought into this one because it wasn't sitting
right with me. I think there are two main issues:

1) Is geoindexing actually "optional"

2) Would JARs be also published alongside the source release, and do
those JARs bundle these GPL-licensed dependencies.

Assuming #1 is "yes" (because I don't know it well enough technically),
If the geo-indexing modules are disabled by default, you can make the
release. I think this is what Venkatesh was getting at.

When you publish JARs, even though they are not an official release in
Apache's eyes (only source code is an Apache release -- everything else
is "supplemental" and not actually part of the release), you should
still make sure that they are being properly licensed. This also extends
to not being allowed to bundle Category-X dependencies (e.g. GPL). I
think this is how I 

Re: RC2 Release Status

[Josh Elser]

Uh.. why not just use JIRA?

fixVersion, status=Blocker, and Assignees are there for a reason...

Aaron D. Mihalik wrote:

All,

I'm maintaining a small spreadsheet of issues [1] we need to resolve for
RC2.  It is essentially a finer grained copy of what we have in Jira at
RYA-184 [2] (in order to keep track of merges and whatnot).

If anyone is interested in working on RC2, check RYA-184 or this
spreadsheet for an open issue and ping the dev list letting us know that
you're on it.

Thanks,
Aaron


[1]
https://docs.google.com/spreadsheets/d/1p555i5gdBJHXBTQ4DFR37aL-CFLWWhUWHq6VLXDngnQ/edit#gid=0
[2] https://issues.apache.org/jira/browse/RYA-184

[DISCUSS] Java package change before the first ASF release?

[Josh Elser]

Convention in other Java-based ASF projects is to have a package of 
"org.apache". I was recently reminded that Rya still is using 
"mvm.rya...".


Has there been any discussion about ultimately doing an s/package 
mvm.rya/package org.apache.rya/ in the future?


I wanted to mention it before we got to another release candidate :). 
Long term, it's probably a good idea, but there's a good argument in 
doing a release of Rya at the ASF which maintains the old package name 
for the sake of your users.


- Josh

Re: [DISCUSS] Path forward for release

[Josh Elser]

Yup, you got it right, Caleb (given my current interpretation, anyways 
:P). The incubator proposal[1] should have called out these dependencies 
to begin with. I think this is why this is such a "shock".


Working under the assumption that GeoIndexing is the "tainted fruit" and 
we call it optional, I think there is merit in making a release, 
acknowledging that it needs work and that it is not entirely at the 
spirit of "optional". Getting familiarity with how to make a release is 
extremely important. End of the day, this is something that needs to be 
addressed prior to graduation. I'm think I'm OK with suggesting that 
geoindexing is optional to kick the problem down the road for a first 
release, but I want to make sure it doesn't get repeatedly kicked. This 
should be an extremely high priority to resolve.


In fewer words: if reworking the indexing to modularize the Geo-related 
pieces is something someone can volunteer to do right now, great. That 
is the ideal path forward. If it's going to take month(s) to do, I think 
punting for one release is OK.


[1] https://wiki.apache.org/incubator/RyaProposal#External_Dependencies

Meier, Caleb wrote:

So just make sure I'm clear with what you said, I'll attempt to summarize.  For the 
purposes of a release, it's okay to include source code for components that have 
improperly licensed, Runtime dependencies, so long as they are "optional" and 
turned off by default.  But when we actually deploy our artifacts, we need to exclude the 
jars for all components that have improperly licensed dependencies.  So in effect, any 
components that have improperly licensed dependencies need to be truly optional from a 
build perspective -- have an optional build profile -- and should not be built and 
deployed by default.

What we are currently working on is making geoindexing optional from a build 
perspective.  We're separating it out from the indexing project so that it can 
have its own, optional build profile.  If what I said above is correct, it 
seems like there is no way around this, other than making the entire indexing 
project optional.  But that would be like throwing the baby out with the bath 
water.

From: Josh Elser [els...@apache.org]
Sent: Monday, October 10, 2016 10:26 AM
To: dev@rya.incubator.apache.org
Subject: Re: [DISCUSS] Path forward for release

Ok, I put some more thought into this one because it wasn't sitting
right with me. I think there are two main issues:

1) Is geoindexing actually "optional"

2) Would JARs be also published alongside the source release, and do
those JARs bundle these GPL-licensed dependencies.

Assuming #1 is "yes" (because I don't know it well enough technically),
If the geo-indexing modules are disabled by default, you can make the
release. I think this is what Venkatesh was getting at.

When you publish JARs, even though they are not an official release in
Apache's eyes (only source code is an Apache release -- everything else
is "supplemental" and not actually part of the release), you should
still make sure that they are being properly licensed. This also extends
to not being allowed to bundle Category-X dependencies (e.g. GPL). I
think this is how I noticed this in the first place.

I will leave the #1 discussion up to you all because I don't have enough
context -- should really get an answer in the spirit of the question:
"Is Rya useful if GeoIndexing is optional?". Meaning, will the people
using this release all be building the optional GeoIndexing support? In
this case, it's a core feature, and not an optional one.

Let me know if #2 is still not clear. I apologize for (likely) making
things more complicated.

Josh Elser wrote:

No, you're correct. I am disagreeing with Venkatesh :). That's why I
included documentation which outlines why I am disagreeing with him.

Meier, Caleb wrote:

Unless I am misunderstanding something, which I probably am, it seems
like Venkatesh and Josh are saying conflicting things. Venkatesh seems
to be implying that the licenses for runtime dependencies do not need
to be taken into account, while Josh seems to be be saying that the
licenses of all artifacts created need to be compliant, and that the
licensing of those artifacts depends on the licensing of run time
dependencies. Am I missing something here?

Regarding geoindexing and indexing, those projects are somewhat
coupled right now. Puja took steps to remove geoindexing from indexing
in an effort to carry out 2. Going forward it might be best to make
the indexes pluggable.



Sent from my Verizon 4G LTE smartphone


 Original message 
From: Josh Elser
Date: 10/8/16 3:54 PM (GMT-05:00)
To: dev@rya.incubator.apache.org
Subject: Re: [DISCUSS] Path forward for release

Venkatesh is right in that the only "official

Re: [DISCUSS] Path forward for release

[Josh Elser]

Ok, I put some more thought into this one because it wasn't sitting 
right with me. I think there are two main issues:


1) Is geoindexing actually "optional"

2) Would JARs be also published alongside the source release, and do 
those JARs bundle these GPL-licensed dependencies.


Assuming #1 is "yes" (because I don't know it well enough technically), 
If the geo-indexing modules are disabled by default, you can make the 
release. I think this is what Venkatesh was getting at.


When you publish JARs, even though they are not an official release in 
Apache's eyes (only source code is an Apache release -- everything else 
is "supplemental" and not actually part of the release), you should 
still make sure that they are being properly licensed. This also extends 
to not being allowed to bundle Category-X dependencies (e.g. GPL). I 
think this is how I noticed this in the first place.


I will leave the #1 discussion up to you all because I don't have enough 
context -- should really get an answer in the spirit of the question: 
"Is Rya useful if GeoIndexing is optional?". Meaning, will the people 
using this release all be building the optional GeoIndexing support? In 
this case, it's a core feature, and not an optional one.


Let me know if #2 is still not clear. I apologize for (likely) making 
things more complicated.


Josh Elser wrote:

No, you're correct. I am disagreeing with Venkatesh :). That's why I
included documentation which outlines why I am disagreeing with him.

Meier, Caleb wrote:

Unless I am misunderstanding something, which I probably am, it seems
like Venkatesh and Josh are saying conflicting things. Venkatesh seems
to be implying that the licenses for runtime dependencies do not need
to be taken into account, while Josh seems to be be saying that the
licenses of all artifacts created need to be compliant, and that the
licensing of those artifacts depends on the licensing of run time
dependencies. Am I missing something here?

Regarding geoindexing and indexing, those projects are somewhat
coupled right now. Puja took steps to remove geoindexing from indexing
in an effort to carry out 2. Going forward it might be best to make
the indexes pluggable.



Sent from my Verizon 4G LTE smartphone


 Original message 
From: Josh Elser
Date: 10/8/16 3:54 PM (GMT-05:00)
To: dev@rya.incubator.apache.org
Subject: Re: [DISCUSS] Path forward for release

Venkatesh is right in that the only "official" release in the ASF's eyes
is the source release. Any JARs you publish are supplementary and
technically not subject to the rules of Apache releases.

The area I'm still trying to fully grok is that the source-release you
publish must also create artifacts which are properly licensed[1]. Right
now, that means including numerous incompatible dependencies, and, thus,
does not meet the requirements of the ASL and the ASF.

Regarding David's last question: I would assume that the license applies
to both the source code and binary forms of the geo-related artifacts
that you are currently bundling in Rya. GPL is forcing that the source
code for those artifacts be available, but is not implying that the
license only applies to the code in source form.

"A" and 1/2 would be how I expected this to go forward (although, I'm
not sure how "removing GeoIndexing" evolved into "removing Indexing" --
are they so intertwined?). The area that currently makes me feel awkward
is how to interpret "optional dependencies". If every user of Rya would
just be building this support anyways, that's skirting a very gray area
in my current understanding of what is allowed.

- Josh

[1]
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.apache.org_dev_licensing-2Dhowto.html-23binary&d=CwICAw&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8&m=PlHBkcTuE9DcvVb1m3V1nCNNRsvZnLKrtMK1AKmYSY0&s=43QIBqVfsjovifro22HiGqmGW3Q9qY4xvKVtqPzv_x8&e=


Puja Valiyil wrote:

I don't think I follow. The source references an lgpl Api, and we are
publishing binary that references it in nexus. Are you sure it's not
an issue?

Sent from my iPhone


On Oct 6, 2016, at 10:36 PM, Seetharam
Venkatesh wrote:

If it's a runtime dependency, you are fine. Apache only supports
source releases. We vote on source tar ball and not binary artifacts.

Makes sense?

Sent from my iPhone,
Venkatesh


On Oct 6, 2016, at 12:40 PM, David Lotts wrote:

Yes, geotools is a runtime dependency. No geotools source code is
distributed.

By that I mean: Geotools source code is not in our source code
repository.
Only references: imports in our *.java files and dependencies
entries in
our pom.xml. Because of this maven will package geotools JARs
(binaries)
in our shaded/uber JAR and WAR files that we distribute.

With option 1 or 2 as d

Re: [DISCUSS] Path forward for release

[Josh Elser]

No, you're correct. I am disagreeing with Venkatesh :). That's why I 
included documentation which outlines why I am disagreeing with him.


Meier, Caleb wrote:

Unless I am misunderstanding something, which I probably am, it seems like 
Venkatesh and Josh are saying conflicting things. Venkatesh seems to be 
implying that the licenses for runtime dependencies do not need to be taken 
into account, while Josh seems to be be saying that the licenses of all 
artifacts created need to be compliant, and that the licensing of those 
artifacts depends on the licensing of run time dependencies. Am I missing 
something here?

Regarding geoindexing and indexing, those projects are somewhat coupled right 
now. Puja took steps to remove geoindexing from indexing in an effort to carry 
out 2. Going forward it might be best to make the indexes pluggable.



Sent from my Verizon 4G LTE smartphone


 Original message ----
From: Josh Elser
Date: 10/8/16 3:54 PM (GMT-05:00)
To: dev@rya.incubator.apache.org
Subject: Re: [DISCUSS] Path forward for release

Venkatesh is right in that the only "official" release in the ASF's eyes
is the source release. Any JARs you publish are supplementary and
technically not subject to the rules of Apache releases.

The area I'm still trying to fully grok is that the source-release you
publish must also create artifacts which are properly licensed[1]. Right
now, that means including numerous incompatible dependencies, and, thus,
does not meet the requirements of the ASL and the ASF.

Regarding David's last question: I would assume that the license applies
to both the source code and binary forms of the geo-related artifacts
that you are currently bundling in Rya. GPL is forcing that the source
code for those artifacts be available, but is not implying that the
license only applies to the code in source form.

"A" and 1/2 would be how I expected this to go forward (although, I'm
not sure how "removing GeoIndexing" evolved into "removing Indexing" --
are they so intertwined?). The area that currently makes me feel awkward
is how to interpret "optional dependencies". If every user of Rya would
just be building this support anyways, that's skirting a very gray area
in my current understanding of what is allowed.

- Josh

[1] 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.apache.org_dev_licensing-2Dhowto.html-23binary&d=CwICAw&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8&m=PlHBkcTuE9DcvVb1m3V1nCNNRsvZnLKrtMK1AKmYSY0&s=43QIBqVfsjovifro22HiGqmGW3Q9qY4xvKVtqPzv_x8&e=

Puja Valiyil wrote:

I don't think I follow.  The source references an lgpl Api, and we are 
publishing binary that references it in nexus.   Are you sure it's not an issue?

Sent from my iPhone


On Oct 6, 2016, at 10:36 PM, Seetharam Venkatesh   wrote:

If it's a runtime dependency, you are fine. Apache only supports source 
releases. We vote on source tar ball and not binary artifacts.

Makes sense?

Sent from my iPhone,
Venkatesh


On Oct 6, 2016, at 12:40 PM, David Lotts   wrote:

Yes, geotools is a runtime dependency.  No geotools source code is
distributed.

By that I mean: Geotools source code is not in our source code repository.
Only references: imports in our *.java files and dependencies entries in
our pom.xml.   Because of this maven will package geotools JARs (binaries)
in our shaded/uber JAR and WAR files that we distribute.

With option 1 or 2 as discussed, maven will exclude the geotools jars in
our JARs and WARs.  Users of Rya can follow some instructions that we
provide to add "-P indexing" (or similar) to their Maven build command
create their own jar/war containing the optional Rya features and geotools
binaries.

Your "you should be okay." mean which of these
A. option 1 and option 2 will work around the issue and we should proceed
before we release,
- OR -
B.  We are already in compliance and this is not a blocker for release as
long as we are not redistributing geotools source code.

Hopeful for interpretation B, but expecting and happy with A.

david.

On Thu, Oct 6, 2016 at 1:22 PM, Seetharam Venkatesh
wrote:


Quick question - geotools is a runtime dependency? Are you shipping the
source code? If not, you should be okay.

Sent from my iPhone,
Venkatesh


On Oct 6, 2016, at 7:52 AM, Puja Valiyil   wrote:

Hi everyone,
Talking with Aaron, it seems like there were two paths forward for
refactoring in order to create a release.  To refresh everyone's memory,
the issue was that the geo-indexing extensions to Rya pull in geotools,
which prohibits us from releasing Rya under an Apache 2 license.  There

may

be some more particulars that I'm glossing over -- someone please chime

in

if they feel it is key to the discussion.
The two paths forward we had were:
1.  Make all of the index

Re: [DISCUSS] Path forward for release

[Josh Elser]

Venkatesh is right in that the only "official" release in the ASF's eyes 
is the source release. Any JARs you publish are supplementary and 
technically not subject to the rules of Apache releases.


The area I'm still trying to fully grok is that the source-release you 
publish must also create artifacts which are properly licensed[1]. Right 
now, that means including numerous incompatible dependencies, and, thus, 
does not meet the requirements of the ASL and the ASF.


Regarding David's last question: I would assume that the license applies 
to both the source code and binary forms of the geo-related artifacts 
that you are currently bundling in Rya. GPL is forcing that the source 
code for those artifacts be available, but is not implying that the 
license only applies to the code in source form.


"A" and 1/2 would be how I expected this to go forward (although, I'm 
not sure how "removing GeoIndexing" evolved into "removing Indexing" -- 
are they so intertwined?). The area that currently makes me feel awkward 
is how to interpret "optional dependencies". If every user of Rya would 
just be building this support anyways, that's skirting a very gray area 
in my current understanding of what is allowed.


- Josh

[1] http://www.apache.org/dev/licensing-howto.html#binary

Puja Valiyil wrote:

I don't think I follow.  The source references an lgpl Api, and we are 
publishing binary that references it in nexus.   Are you sure it's not an issue?

Sent from my iPhone


On Oct 6, 2016, at 10:36 PM, Seetharam Venkatesh  wrote:

If it's a runtime dependency, you are fine. Apache only supports source 
releases. We vote on source tar ball and not binary artifacts.

Makes sense?

Sent from my iPhone,
Venkatesh


On Oct 6, 2016, at 12:40 PM, David Lotts  wrote:

Yes, geotools is a runtime dependency.  No geotools source code is
distributed.

By that I mean: Geotools source code is not in our source code repository.
Only references: imports in our *.java files and dependencies entries in
our pom.xml.   Because of this maven will package geotools JARs (binaries)
in our shaded/uber JAR and WAR files that we distribute.

With option 1 or 2 as discussed, maven will exclude the geotools jars in
our JARs and WARs.  Users of Rya can follow some instructions that we
provide to add "-P indexing" (or similar) to their Maven build command
create their own jar/war containing the optional Rya features and geotools
binaries.

Your "you should be okay." mean which of these
A. option 1 and option 2 will work around the issue and we should proceed
before we release,
- OR -
B.  We are already in compliance and this is not a blocker for release as
long as we are not redistributing geotools source code.

Hopeful for interpretation B, but expecting and happy with A.

david.

On Thu, Oct 6, 2016 at 1:22 PM, Seetharam Venkatesh
wrote:


Quick question - geotools is a runtime dependency? Are you shipping the
source code? If not, you should be okay.

Sent from my iPhone,
Venkatesh


On Oct 6, 2016, at 7:52 AM, Puja Valiyil  wrote:

Hi everyone,
Talking with Aaron, it seems like there were two paths forward for
refactoring in order to create a release.  To refresh everyone's memory,
the issue was that the geo-indexing extensions to Rya pull in geotools,
which prohibits us from releasing Rya under an Apache 2 license.  There

may

be some more particulars that I'm glossing over -- someone please chime

in

if they feel it is key to the discussion.
The two paths forward we had were:
1.  Make all of the indexing project and its downstream dependencies
optional and exclude them from a release
-- The indexing project includes several "optional" extensions to Rya
(advanced indexing strategies).  Prior to Rya becoming an apache project,
these indexing extensions were optional and there was a separate profile
for including them.  This option involves reverting back to that mindset.
The main argument against this is that these indexing

strategies/extensions

are not in fact optional but are "core" to Rya and can't be excluded.

2.  Refactor Rya to pull geoindexing into a separate project and exclude
that project from the release.
- We could refactor Rya to have geoindexing be its own project and add a
profile to include that in the build.  This would invovle moving the

class

mvm.rya.indexing.GeoIndexer and packages mem.rya.indexing.accumulo.geo

and

mvm.rya.indexing.mongodb.geo to a separate project and then

removing/moving

references to geoindexing anywhere else.  Another option is to refactor

the

GeoIndexer interface to remove the geotools dependency.

I think #1 is a good immediate path for a release and that #2 is a good
longer term path forward.  Since it's probably in our best interests as a
community to get an apache release sooner rather than later, I'd rather

us

go with #1 since it would quicker.  I also think that most users of Rya
would be ok with excluding the indexing project since it is not core
functionality for Rya.  Whi

Re: October incubator podling report - please comment

[Josh Elser]

What's going on with Rya's first release? I feel like it's been 
presented as "going to happen soon!" for the last X reports...


"The PPMC is currently discussing inviting more active contributors to 
become committers"


I would omit this. Reports are public. Lists where such discussions 
would happen are typically private...


"PRs from non-committers which are integrated into the repository 
continue to be received"


Expand on this? How does this reflect in terms of community growth? One 
contributor with 5 PRs? 5 contributors with 1 PR?


s/Fluo/Apache Fluo (incubating)/

Otherwise, looks OK. Thanks for putting this together Adina, and sorry 
for the late reply.


- Josh

Adina Crainiceanu wrote:

ping:

Here is what I have so far. I'll upload it to the incubator wiki and update
if needed.

Thanks,
Adina

Rya

Rya (pronounced "ree-uh" /rea/) is a cloud-based RDF triple store that
supports SPARQL queries. Rya is a scalable RDF data management system built
on top of Accumulo. Rya uses novel storage methods, indexing schemes, and
query processing techniques that scale to billions of triples across
multiple nodes.  Rya provides fast and easy access to the data through
SPARQL, a conventional query mechanism for RDF data.

Rya has been incubating since 2015-09-18.

Three most important issues to address in the move towards graduation:

   1. Become familiar with the release process and have a first release as
part of the Apache Foundation
   2. Expand the documentation to be more formalized and more representative
of the current codebase.
   3. Add new committers to the project.

Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware
of?

   No

How has the community developed since the last report?

   * A new committer was invited and accepted to join the committers for
Apache Rya (incubating).
   * Talk on Rya at the DC Graph Database meetup on August 30, 2016
   * Online presentation on Rya to a group of researchers and developers
from Cray on September 29, 2016
   * Talk on Rya entitled "Accumulo Indexing Strategies for Searching
Semantic Networks" accepted at Accumulo Summit, October 11, 2016
   * The Rya "office hour" teleconference continues every other week, with
few exceptions when people are too busy. Users and developers can ask
questions, receive answers, discuss ideas for future developments. The
minutes are sent to the dev@ list. Attendance at these meetings has grown
beyond existing committers of the project to include new contributors.  New
contributors have led the discussion for new features that they have helped
develop.  We continue posting minutes and reference slides from the
meetings on confluence to provide reference documentation to new
contributors.
   * PRs from non-committers which are integrated into the repository
continue to be received

How has the project developed since the last report?

   * Worked on the first release. The first release candidate was proposed,
but the vote did not pass on the dev list. Working on the next release
candidate.
   * Resolved a handful of issues that users have encountered.
   * Committed features: benchmark tool for the pre-computed joins
optimizer, added support for property chain inference, integrated Fluo with
Rya so triples inserted in Rya are inserted into Fluo too in order to
incrementally update any pre-computed joins registered with Fluo, added
OPTIONAL support for pre-computed joins

Date of last release:

   Not applicable. Initial vote on first release candidate did not pass on
dev list. Working on the next release candidate.

When were the last committers or PMC members elected?

   New committer Caleb Meier elected on August 31, 2016
   The PPMC is currently discussing inviting more active contributors to
become committers.

Signed-off-by:

   [ ](rya) Josh Elser
   [ ](rya) Edward J. Yoon
   [ ](rya) Sean Busbey
   [ ](rya) Venkatesh Seetharam

Shepherd/Mentor notes:


On Sun, Oct 2, 2016 at 4:42 PM, Adina Crainiceanu  wrote:


Hi,

I started the report for October, due on October 5 (Wednesday), Can
someone please fill out the committed features? Any other comments and
suggestions are also appreciated.

Thank you,
Adina

Rya

Rya (pronounced "ree-uh" /rea/) is a cloud-based RDF triple store that
supports SPARQL queries. Rya is a scalable RDF data management system built
on top of Accumulo. Rya uses novel storage methods, indexing schemes, and
query processing techniques that scale to billions of triples across
multiple nodes.  Rya provides fast and easy access to the data through
SPARQL, a conventional query mechanism for RDF data.

Rya has been incubating since 2015-09-18.

Three most important issues to address in the move towards graduation:

   1. Become familiar with the release process and have a first release as
part of the Apache Foundation
   2. Expand the documentation to be more formalized and more
represe

Re: [ANNOUNCE] Welcome new committer Caleb Meier

[Josh Elser]

Congrats, Caleb!

Adina Crainiceanu wrote:

Hi all,

It is my pleasure to announce that Caleb Meier is now a committer for the
Apache Rya (incubating).

Thank you Caleb for your past and future contributions and we are looking
forward to continue working with you. Welcome!

Best wishes,
Adina (on behalf of Rya PPMC)

Re: RYA-179 Review License / Copyright notices on Rya Artifacts

[Josh Elser]

Yeah, this is where I'm not 100% sure how to interpret this. I'm not 
sure if "optional" is interpreted as "there are other ways to do X" or 
if it's "X is not a core-feature of Rya".


@Sean, do you know how this is supposed to be interpreted?

Puja Valiyil wrote:

I guess my point is that the average user doesn't want these capabilities.
We removed the profile to make build process easier, but the main reason we
had it to begin with was because they are optional extensions that can
complicate licensing and add a lot of unwanted dependencies.
The other option we have would be to swap geomesa with geowave [1].
Geowave has an apache 2 license [2] and so all the dependencies that brings
in should be ok.  We've talked about adding GeoWave support a lot, so I
think that there is value outside of for licensing issues.  I don't think
it would be trivial to bring in GeoWave for Geomesa, so that might put
cutting a release on hold for a while.

[1] https://github.com/ngageoint/geowave
[2] https://github.com/ngageoint/geowave/blob/master/LICENSE


On Thu, Sep 15, 2016 at 12:46 AM, Meier, Caleb
wrote:


While the indexer project extensions are optional in that they are turned
off by default to minimize data plume, I would argue that they are not
optional in the sense that Josh has described.  There is no other way to
index/query for freetext, geospatial, and temporal data without these
extensions.  So if a user wants these capabilities, they need the indexer
project and all of the incompatibly licensed dependencies that come along
with it.

From: Puja Valiyil [puja...@gmail.com]
Sent: Wednesday, September 14, 2016 9:49 PM
To: dev@rya.incubator.apache.org
Cc: Billie Rinaldi
Subject: Re: RYA-179 Review License / Copyright notices on Rya Artifacts

The indexer project has a set of configurable optional extension to Rya.
Things like support for geosparql, support for free text indexing, and
support for precomputed joins (which is where the fluo integration comes
in).  These are extensions that by default are turned off.  They can really
increase the data plume associated with some data, which is the main reason
why.

In the original port into Apache, this project was only included if you
specified that profile.  This was because we have traditionally considered
those features experimental and they bring in a lot of possibly unwanted
dependencies.  Aaron refactored it to not be optional when he was updating
the pond to reference the Apache parent Pom.
So no alternative, but functionality that a typical user may debatably not
want.

Sent from my iPhone


On Sep 14, 2016, at 8:05 PM, Josh Elser  wrote:

I would have said that this is only kosher when you have an alternative

to the incompatibly licensed software. Is the indexer actually optional (I
don't have enough context)? Are there ways for me to to indexing of the
same type of data that don't require use of these incompatible dependencies?

Billie might be able to provide some more context too.

Aaron D. Mihalik wrote:

Could we revive the indexer profile again?

(tl;dr: Yes.  Mentors: Please correct us if we're wrong)

This might be a solution.  I found a couple similar cases with Apache
projects and discussions related to those cases.

Apache Flink integrated with Amazon Kinesis [1] and [2].  Note that

Kinesis

is an optional profile, and it's well documented in the POM why it's
optional.

(Note that NiFi got around this by using Amazon's SDK for Java [3],

which

is purely Apache 2.0)

Spark uses optional profiles to build artifacts based on LGPL
dependencies.  Spark has to built by the user to use netlib [4][5],

Ganglia

[6], or Kinesis [6].

I think a profile will work, but I'd like to see it well documented

(both

in the POM and manual) so that we never accidentally create a release

with

these artifacts.

I was going to open a separate ticket to implement this, but I think

it's

good to track all of this effort under RYA-177.

--Aaron

[1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.

com_apache_flink_blob_release-2D1.1.2_flink-2Dstreaming-
2Dconnectors_pom.xml-23L69&d=CwIFAg&c=Nwf-pp4xtYRe0sCRVM8_
LWH54joYF7EKmrYIdfxIq10&r=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8&m=
USEC4e6JdxuZZwMB0AkZPzHtdsKWf8ep6g5BSRLQ2XY&s=
wnYDdDdgR8EEFav9sKC7ftd6ZjSJcOXU8FISG6jJMHc&e=

[2]
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.

com_apache_flink_blob_release-2D1.1.2_flink-2Dstreaming-
2Dconnectors_flink-2Dconnector-2Dkinesis_pom.xml-23L73&d=CwIFAg&c=Nwf-
pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=vuVdzYC2kksVZR5STiFwDpzJ7CrMHC
geo_4WXTD0qo8&m=USEC4e6JdxuZZwMB0AkZPzHtdsKWf8ep6g5BSRLQ2XY&s=
ZFTL5gQzyzLvRcWrafGrCobMJ8d1DWSmZlIVz9M7EuQ&e=

[3] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.

com_apache_nifi_blob_master_pom.xml-23L1316&

Re: RYA-179 Review License / Copyright notices on Rya Artifacts

[Josh Elser]

I would have said that this is only kosher when you have an alternative 
to the incompatibly licensed software. Is the indexer actually optional 
(I don't have enough context)? Are there ways for me to to indexing of 
the same type of data that don't require use of these incompatible 
dependencies?


Billie might be able to provide some more context too.

Aaron D. Mihalik wrote:

Could we revive the indexer profile again?


(tl;dr: Yes.  Mentors: Please correct us if we're wrong)

This might be a solution.  I found a couple similar cases with Apache
projects and discussions related to those cases.

Apache Flink integrated with Amazon Kinesis [1] and [2].  Note that Kinesis
is an optional profile, and it's well documented in the POM why it's
optional.

(Note that NiFi got around this by using Amazon's SDK for Java [3], which
is purely Apache 2.0)

Spark uses optional profiles to build artifacts based on LGPL
dependencies.  Spark has to built by the user to use netlib [4][5], Ganglia
[6], or Kinesis [6].

I think a profile will work, but I'd like to see it well documented (both
in the POM and manual) so that we never accidentally create a release with
these artifacts.

I was going to open a separate ticket to implement this, but I think it's
good to track all of this effort under RYA-177.

--Aaron

[1]
https://github.com/apache/flink/blob/release-1.1.2/flink-streaming-connectors/pom.xml#L69
[2]
https://github.com/apache/flink/blob/release-1.1.2/flink-streaming-connectors/flink-connector-kinesis/pom.xml#L73

[3] https://github.com/apache/nifi/blob/master/pom.xml#L1316

[4] https://github.com/apache/spark/blob/v2.0.0/mllib/pom.xml#L120
[5]
https://github.com/apache/spark/blob/v2.0.0/docs/ml-guide.md#dependencies

[6] https://github.com/apache/spark/blob/v2.0.0/pom.xml#L2414

[7] https://issues.apache.org/jira/browse/LEGAL-198
[8] https://www.gnu.org/licenses/lgpl-java.html



On Wed, Sep 14, 2016 at 12:09 PM David Lotts  wrote:


Great find Aaron!
The ESRI library is quite comparable!

Rya via Geomesa are using *JTS Topology Suite (*JTS): (the javadocs at
vividsolutions seems to be 404 )


http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/geom/Geometry.html

Far from a drop-in replacement, but a path forward:
 http://esri.github.io/geometry-api-java/javadoc/

Interesting, ESRI has Shape file support, but no GML, the opposite of JTS!
david.


On Wed, Sep 14, 2016 at 10:29 AM, Aaron D. Mihalik<
aaron.miha...@gmail.com>
wrote:


Yeah, that sounds possible. I don't like the idea of having to maintain
another build/ci/release process, though.

More importantly, we'd also have to modify our GeoIndexer interface [1]

to

something Apache Friendly.  It looks like Ersi puts out an Apache 2.0
library [2].

[1]
https://github.com/apache/incubator-rya/blob/master/
extras/indexing/src/main/java/mvm/rya/indexing/GeoIndexer.java
[2] https://github.com/Esri/geometry-api-java

On Tue, Sep 13, 2016 at 10:36 PM Jim Hughes  wrote:


Hi Aaron,

Thanks, wasn't finding that list quickly...

It sounds like the GeoMesa/GeoTools usage might fall under this Q/A:
http://www.apache.org/legal/resolved.html#optional.

Thoughts?

Jim

On 9/13/2016 9:25 PM, Aaron D. Mihalik wrote:

Jim,

We've been working off of these lists:

http://www.apache.org/legal/resolved.html#category-a

On Tue, Sep 13, 2016 at 6:07 PM Jim Hughes  wrote:


Hi David,

A number of the geo-dependencies are likely from the geo-indexing

(which

uses GeoMesa (Apache 2.0) which uses GeoTools and JTS).

Are there options to make the geoindexing a profile, provide the

source,

and not provide artifacts for that code at Apache?

Also, is there a list of approved licenses for Apache projects
dependencies?

Cheers,

Jim

On 09/13/2016 05:46 PM, David Lotts wrote:

This issue is a release blocker:


RYA-179  Review

License /

Copyright notices on Rya Artifacts

I was able to create a 3rd party dependency license report for Rya
from the license
maven plugin.


Good: I can send the full list if you like.  Mostly ASL and clearly
permitted.

Okay: A number of CDDL and CPL licenses -- permitted if no source

code

is

included.

Needs Improvement: The following are not clearly permitted

licenses:

(cern.colt MIT license see
https://dst.lbl.gov/ACSSoftware/colt/license.html) colt

(colt:colt:1.2.0 -

no url defined)
-- this is a mistake, should be  java.util.Arrays, not
cern.colt.Arrays  -- creating an issue to eliminate dependency.
(GNU LESSER GENERAL PUBLIC LICENSE) JCalendar
(com.toedter:jcalendar:1.1.4 -

http://www.toedter.com/en/jcalendar/)

(Lesser General Public License (LGPL)) JTS Topology Suite
(com.vividsolutions:jts:1.13 -
http://sourceforge.net/projects/jts-topo-suite)
(Lesser General Public License (LGPL)) Image I/O-Extensions

-

GeoCore

(it.geosolutions.imageio-ext:im

Re: [VOTE] Release Rya (Incubating) version 3.2.10

[Josh Elser]

Great, glad it's helpful. Also, thanks for taking this on. The first 
release is always the hardest, and I didn't do a good job commending you 
on stepping up :)


Aaron D. Mihalik wrote:

Thanks Josh!  This list is great.

I'll add the RC-X to the "Vote" email for the next RC.  I also updated the
release docs to include that note.

I added these tasks to track:

(Blocker) RYA-177 - Review License on Rya Dependencies
RYA-178 Review RAT Exclusions
RYA-179 - Review License / Copyright notices on Rya Artifacts
RYA-180 - Review Licensing of Shaded/War'd Rya Artifacts
RYA-182 - Review SCM Tag in Parent POM

Is RYA-180 subsumed by RYA-177?  If we verify that all of the Rya
Dependencies are not "Category X", are there additional concerns about what
we war/shade up?


No, sadly :). The LICENSE and NOTICE files you have at the top-level of 
the source-release are "easy" right now because you do not bundle any 
other code than just "Apache Rya (incubating)". Therefore, you only have 
to deal with Rya's licensing (which is simple).


When you start creating artifacts that contain other artifacts, you must 
update LICENSE and NOTICE appropriately (in META-INF/ in JARs/WARs). A 
tl;dr is that, for every dependency you bundle, you must include it's 
license in the LICENSE file and propagate any relevant information from 
their NOTICE file (e.g. copyright/attribution statements) into your 
NOTICE file. There are lots of good write-ups coming out of other ASF 
projects of late which can help distill this.


I would recommend we just make a note to deal with this post-3.2.10. As 
an incubator project, you get a pass on doing this all 100% correct; 
however, the incompatible licensing is pretty heinous (so I'm treating 
these separately). :)



--Aaron

On Mon, Sep 12, 2016 at 11:35 AM Josh Elser  wrote:


(thanks for the extension, I started looking at this and then forgot
about it)

-1 (binding)

First off, please include some sort of "RC-X" identifier in the vote
subject so that we can differentiate them in the archives.

- The good

* xsums+sigs match
* Can build from source
* Ran all unit tests (as invoked during `mvn package`)
* Found no binary files

- Things that must be fixed

* https://dist.apache.org/repos/dist/release/incubator/rya and
https://dist.apache.org/repos/dist/dev/incubator/rya don't exist. You
must have the former created with a KEYS file that contains the GPG
public keys for those creating Rya release notes. Typically, you should
use dist.a.o/repos/dist/dev/incubator/rya to stage your release
artifacts, although policy on whether using the staging repo alone is
sufficient is not clear to me. (were it not for the licensing issues
below, we could just fix this)
* jgridshift:jgridshift appears to be LGPL licensed
(https://github.com/floscher/jGridShift/blob/master/LICENSE). You may
not use this software. It looks like it was not appropriately marked in
its pom which is why the configuration from Rya's parent apache.pom did
not catch it. This is brought in via org.geotools.xsd:gt-xsd-gml3.
* colt (http://dst.lbl.gov/ACSSoftware/colt/) appears to be another
brought in by com.tinkerpop.blueprints:blueprints-core
* com.google.code.findbugs:jsr305 is another example of GPL licensing.
While the artifact appears to have the ASL tagged on the pom, all
Findbugs documentation states that the project is GPL.

I would recommend to make a pass over your dependencies to verify that
you aren't depending on any projects which are licensed with a license
on this list: http://www.apache.org/legal/resolved.html#category-x. See
http://www.apache.org/licenses/GPL-compatibility.html for more details.
The above three examples were found via a brief glance.

- Things to fix later (later rc's or the next release)

* Copyright year in NOTICE is wrong (2015 instead of 2016)
* mvn apache-rat:check passes (after `rm DEPENDENCIES`)
* A number of files which have 'Copyright (C) 2014 Rya' in the license
header in extras/rya.merger that should not exist. Copyright statement
should only appear in the NOTICE file (`fgrep -Ri 'copyright'
rya-project-3.2.10 | fgrep -v 'The ASF licenses this file'`)
*v3.2.10-RC1  is incorrect in parent pom
* I see a bunch of maven-shade-plugin uses and at least one warfile
project: keep in mind that you should be ensuring that the generated
artifacts by your official source-release should also be licensed per
ASF policy. This isn't something you have to fix for this first release,
but it would bar Rya from a +1 to graduate from me.
* Saw some XML files in the build which were excluded from the
apache-rat-plugin. I'd recommend minimizing the exclusions as much as
possible.

- Josh

Aaron D. Mihalik wrote:

I am pleased to be calling this vote for the source release of Apache Rya
(Incubating), version 3.2.10.

The source zip, including signatures, digests, etc. c

Re: [VOTE] Release Rya (Incubating) version 3.2.10

[Josh Elser]

(thanks for the extension, I started looking at this and then forgot 
about it)


-1 (binding)

First off, please include some sort of "RC-X" identifier in the vote 
subject so that we can differentiate them in the archives.


- The good

* xsums+sigs match
* Can build from source
* Ran all unit tests (as invoked during `mvn package`)
* Found no binary files

- Things that must be fixed

* https://dist.apache.org/repos/dist/release/incubator/rya and 
https://dist.apache.org/repos/dist/dev/incubator/rya don't exist. You 
must have the former created with a KEYS file that contains the GPG 
public keys for those creating Rya release notes. Typically, you should 
use dist.a.o/repos/dist/dev/incubator/rya to stage your release 
artifacts, although policy on whether using the staging repo alone is 
sufficient is not clear to me. (were it not for the licensing issues 
below, we could just fix this)
* jgridshift:jgridshift appears to be LGPL licensed 
(https://github.com/floscher/jGridShift/blob/master/LICENSE). You may 
not use this software. It looks like it was not appropriately marked in 
its pom which is why the configuration from Rya's parent apache.pom did 
not catch it. This is brought in via org.geotools.xsd:gt-xsd-gml3.
* colt (http://dst.lbl.gov/ACSSoftware/colt/) appears to be another 
brought in by com.tinkerpop.blueprints:blueprints-core
* com.google.code.findbugs:jsr305 is another example of GPL licensing. 
While the artifact appears to have the ASL tagged on the pom, all 
Findbugs documentation states that the project is GPL.


I would recommend to make a pass over your dependencies to verify that 
you aren't depending on any projects which are licensed with a license 
on this list: http://www.apache.org/legal/resolved.html#category-x. See 
http://www.apache.org/licenses/GPL-compatibility.html for more details. 
The above three examples were found via a brief glance.


- Things to fix later (later rc's or the next release)

* Copyright year in NOTICE is wrong (2015 instead of 2016)
* mvn apache-rat:check passes (after `rm DEPENDENCIES`)
* A number of files which have 'Copyright (C) 2014 Rya' in the license 
header in extras/rya.merger that should not exist. Copyright statement 
should only appear in the NOTICE file (`fgrep -Ri 'copyright' 
rya-project-3.2.10 | fgrep -v 'The ASF licenses this file'`)

* v3.2.10-RC1 is incorrect in parent pom
* I see a bunch of maven-shade-plugin uses and at least one warfile 
project: keep in mind that you should be ensuring that the generated 
artifacts by your official source-release should also be licensed per 
ASF policy. This isn't something you have to fix for this first release, 
but it would bar Rya from a +1 to graduate from me.
* Saw some XML files in the build which were excluded from the 
apache-rat-plugin. I'd recommend minimizing the exclusions as much as 
possible.


- Josh

Aaron D. Mihalik wrote:

I am pleased to be calling this vote for the source release of Apache Rya
(Incubating), version 3.2.10.

The source zip, including signatures, digests, etc. can be found at:
https://repository.apache.org/content/repositories/orgapacherya-1001/org/apache/rya/rya-project/3.2.10/

The Git tag is v3.2.10
The Git commit ID is 16196b4c658062545964602835cb5fbd2870e578
https://git-wip-us.apache.org/repos/asf?p=incubator-rya.git;a=commit;h=16196b4c658062545964602835cb5fbd2870e578

Checksums of rya-project-3.2.10-source-release.zip:
SHA1: dee4a5e4f8e74c4de614d02c7b17a5e0db132649
MD5: df4a47ae1232725bc95450f5e49de95c

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/mihalik.asc

Issues that were closed/resolved for this release are here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12334209&styleName=Html&projectId=12319020

The vote will be open for 72 hours.
Please download the release candidate and evaluate the necessary items
including checking hashes, signatures, build from source, and test.  Then
please vote:

[ ] +1 Release this package as rya-project-3.2.10
[ ] +0 no opinion
[ ] -1 Do not release this package because because...

Re: [VOTE] Release Rya (Incubating) version 3.2.10

[Josh Elser]

Negative, don't worry about it.

I would add an exclusion to the apache-rat-plugin configuration for it.

Aaron D. Mihalik wrote:

Apache rat is failing. Delete .\DEPENDENCIES

It does not have a license header (is that required for that file?)
On Sat, Sep 10, 2016 at 3:11 PM Adina Crainiceanu  wrote:


I'm trying to figure out how to vote for this release by following the
checklist at:

http://incubator.apache.org/guides/releasemanagement.html#check-list

I'm trying to build from source. I downloaded the
rya-project-3.2.10-source-release.zip
<
https://repository.apache.org/content/repositories/orgapacherya-1001/org/apache/rya/rya-project/3.2.10/rya-project-3.2.10-source-release.zip

,

unzip it, and then I just tried mvn clean install, but I got errors. How
should I try to build from the source? I'm using Maven 3.0.5.

I copy-pasted the error messages below, in case it helps

Thanks,
Adina

$ mvn clean install
[INFO] Scanning for projects...
Downloading:

http://repository.codehaus.org/org/codehaus/groovy/groovy-eclipse-batch/maven-metadata.xml
Downloading:

http://nexus.codehaus.org/snapshots/org/codehaus/groovy/groovy-eclipse-batch/maven-metadata.xml
[WARNING] Could not transfer metadata
org.codehaus.groovy:groovy-eclipse-batch/maven-metadata.xml from/to
codehaus.org (http://repository.codehaus.org): repository.codehaus.org:
unknown error
[WARNING] Could not transfer metadata
org.codehaus.groovy:groovy-eclipse-batch/maven-metadata.xml from/to
codehaus-snapshots (http://nexus.codehaus.org/snapshots/):
nexus.codehaus.org: unknown error
[WARNING]
[WARNING] Some problems were encountered while building the effective model
for org.apache.rya:rya.prospector:jar:3.2.10
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-shade-plugin is missing. @ line 106, column
21
[WARNING]
[WARNING] Some problems were encountered while building the effective model
for org.apache.rya:rya.indexing:jar:3.2.10
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-shade-plugin is missing. @ line 156, column
12
[WARNING]
[WARNING] Some problems were encountered while building the effective model
for org.apache.rya:rya.reasoning:jar:3.2.10
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-shade-plugin is missing. @ line 97, column
21
[WARNING]
[WARNING] Some problems were encountered while building the effective model
for org.apache.rya:accumulo.pig:jar:3.2.10
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-shade-plugin is missing. @ line 78, column
21
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
[INFO]

[INFO] Reactor Build Order:
[INFO]
[INFO] Apache Rya Project
[INFO] Apache Rya Common Projects
[INFO] Apache Rya Common API
[INFO] Apache Rya Provenance
[INFO] Apache Rya DAO Projects
[INFO] Apache Rya Accumulo DAO
[INFO] Apache Rya MongoDB DAO
[INFO] Apache Rya Extra Projects
[INFO] Apache Rya Prospector
[INFO] Apache Rya Manual
[INFO] Apache Rya SAIL
[INFO] Apache Rya PCJ Core
[INFO] Apache Rya PCJ Fluo Parent
[INFO] Apache Rya PCJ Fluo App
[INFO] Apache Rya PCJ Fluo API
[INFO] Apache Rya Secondary Indexing
[INFO] Apache Rya MapReduce Tools
[INFO] Apache Rya Tinkerpop
[INFO] Apache Rya Console
[INFO] Apache Rya Secondary Indexing Example
[INFO] Apache Rya Reasoning
[INFO] Apache Rya Vagrant VM
[INFO] Apache Rya PCJ Fluo Client
[INFO] Apache Rya PCJ Fluo Integration Tests
[INFO] Apache Rya PCJ Fluo Demo
[INFO] Apache Rya Merge Tool
[INFO] Apache Rya OSGI Bundle
[INFO] Apache Rya ALX
[INFO] Apache Rya ALX Console
[INFO] Apache Rya Camel
[INFO] Apache Rya Pig Projects
[INFO] Apache Rya Accumulo Pig
[INFO] Apache Rya Web Projects
[INFO] Apache Rya Web Implementation
[INFO]

[INFO]

[INFO] Building Apache Rya Project 3.2.10
[INFO]

Downloading:

http://repo.maven.apache.org/maven2/org/codehaus/mojo/animal-sniffer-maven-plugin/1.15/animal-sniffer-maven-plugin-1.15.pom
Downloaded:

http://repo.maven.apache.org/maven2/org/codehaus/mojo/animal-sniffer-maven-plugin/1.15/animal-sniffer-maven-plugin-1.15.pom
(6 KB at 1.0 KB/sec)
Downloading:

http://repo.maven.apache.org/maven2/org/codehaus/mojo/animal-sniffer-parent/1.15/animal-sniffer-parent-1.15.pom
Downloaded:

http://repo.maven.apache.org/maven2/org/codehaus/mojo/animal-sniffer-parent/1.15/animal-sniffer-parent-1.15.pom
(6 KB at 21.5 KB/sec)
Downloading:

http://repo.maven.apache.org/maven2/org/codehaus/mojo/mojo-parent/36/mojo-parent-36.pom
Downloaded:

http://repo.maven.apache.org/maven2/org/codehaus/mojo/mojo-parent/36/mojo-parent-36.pom
(28 KB at 84.6 KB/sec)
Downloading:

h

Re: Understanding Apache Staging Repo Rules?

[Josh Elser]

I don't see orgapacherya-1000, only 1001 and that one is still open.

Failed Signature Validation sounds like it could not verify the GPG 
signatures on the artifacts that we deployed. Is the KEYs file for Rya 
published and containing your public signature?


I see http://pgp.mit.edu/pks/lookup?op=vindex&search=0xC3CC40CAF50EAE1A, 
is that they key you used to sign the artifacts?


Aaron D. Mihalik wrote:

I built and pushed 3.2.10-RC1 last night and it appears that it failed
Staging Repo Validation.

You can see the staging repo artifacts here:
https://repository.apache.org/#stagingRepositories

and the repo is orgapacherya-1000

I closed the staging repo and Nexus notes that the "[Close] operation
failed with 3 notifications".  I think that these "3 notifications"
represents only one error, the "Failed Signature Validation".  We'll start
looking at that issue.

I can't find much information about the "Apache Ruleset" and Nexus doesn't
provide much feedback.  Can a mentor double check this for me?  Are we only
failing one rule? Are there more automated "Apache Rules" that may trigger
on the close, or is it just these two?

Thanks,
Aaron

Re: Release Advice (Strange Build Failure Behavior)

[Josh Elser]

Excellent :)

Makes me wonder if we could actually determine when DNS is hosed when 
launching MiniAccumuloCluster and fail in an obvious manner..


Aaron D. Mihalik wrote:

Builds on my machine were failing and I was concerned that builds.a.o was
uncovering additional tests that were going to fail.

Turns out, this is not the case.  All tests pass on my local machine I'm
continuing the process to cut a RC now.

I was having issues running the Mini Accumulo Cluster tests on my local
machine because my DNS set up was screwy.  That's fixed now and the tests
pass.

--Aaron

On Wed, Sep 7, 2016 at 12:41 PM Josh Elser  wrote:


IMO, a flakey test should just be disabled until someone makes time to
fix it. But, why is builds.a.o blocking you from making a release?
You'll be building the release locally anyways [1].

[1] http://www.apache.org/dev/release.html#owned-controlled-hardware

Aaron D. Mihalik wrote:

Caleb and I went to cut a RC yesterday, and it seems like the build is in
an unstable state.  It seems like a strange, non-deterministic test

failure

that might be related to the builder server.  I've documented it here:

   RYA-171 - Mongo Tests are not Cleaning Up
https://issues.apache.org/jira/browse/RYA-171

Should we continue with the 3.2.10-RC or wait until this is fixed?

Also, the Apache Build server is slammed.  Yesterday it took 1.5 hours to
get a machine to start our build :/

--Aaron

Re: Release Advice (Strange Build Failure Behavior)

[Josh Elser]

IMO, a flakey test should just be disabled until someone makes time to 
fix it. But, why is builds.a.o blocking you from making a release? 
You'll be building the release locally anyways [1].


[1] http://www.apache.org/dev/release.html#owned-controlled-hardware

Aaron D. Mihalik wrote:

Caleb and I went to cut a RC yesterday, and it seems like the build is in
an unstable state.  It seems like a strange, non-deterministic test failure
that might be related to the builder server.  I've documented it here:

  RYA-171 - Mongo Tests are not Cleaning Up
https://issues.apache.org/jira/browse/RYA-171

Should we continue with the 3.2.10-RC or wait until this is fixed?

Also, the Apache Build server is slammed.  Yesterday it took 1.5 hours to
get a machine to start our build :/

--Aaron

Re: Meetup/Incubator Report Add

[Josh Elser]

Awesome! Thanks for sharing, Aaron.

Aaron D. Mihalik wrote:

Adina/Puja:

I gave an impromptu lighting talk about Rya last night at the DC Graph
Database Meetup.   We should add that to the next incubator report.

https://www.meetup.com/graphdb-baltimore/events/233370193/

Thank you Adina for a nice website to point everyone to, and thanks Caleb
for the Accumulo Summit presentation.  I talked through the first half of
the deck for the lighting talk.

--Aaron

Re: here we go again

[Josh Elser]

Actually, everyone else will only receive the message if a moderator 
let's it through :)


I think I was feeling cranky when I saw one that just said "YOO" go 
through and denied it.


tl;dr Subscribe to the list per the posted instructions, then post to 
the list.


Adina Crainiceanu wrote:

To subscribe to the dev list, an email to dev-subscribe@rya.incubator
.apache.org should suffice. Only the email address used to send that email
matters, as that email address will be added to the dev list. You should
receive a confirmation email after you subscribe.

Unfortunately, if you are subscribed to the dev list, and you send an email
to that dev list, you will not receive the email, but everyone else will
receive the email - making it harder to check that the email was indeed
received, and that you are indeed on the list.

Andrew, let me know if you have problems subscribing to the Rya dev list.

On Wed, Aug 31, 2016 at 8:17 AM, Aaron D. Mihalik
wrote:


Adina has it as dev-subscr...@rya.incubator.apache.org on the Rya website.

http://rya.incubator.apache.org/community/

On Wed, Aug 31, 2016 at 7:28 AM Puja Valiyil  wrote:


Hey Andrew,
I think you send an email to subscribe-...@rya.incubator.apache.org.  It
might need to say subscribe in the message subject.

Sent from my iPhone


On Aug 30, 2016, at 6:50 PM, Smith, Andrew
wrote:

Add to dev list?
Andrew

Re: Status of the release

[Josh Elser]

That "makes it to master" caveat might be problematic here since you're 
using the gitflow approach (and things only hit master after a release). FYI


Sean Busbey wrote:

To close a github pr, you have to have a commit that makes it to master
with something like "closes #45", where "#45" is the PR number. (Or I think
if you merge the exact commit hash from the head of the PR branch that'll
work).

https://help.github.com/articles/closing-issues-via-commit-messages/

You can close PRs that are spurious by pushing an empty commit to master
with similar language. I usually try to include a reasoning.



On Thu, Aug 18, 2016 at 8:53 AM, Aaron D. Mihalik
wrote:


Puja are you still using the "Commit Process for Committers" instructions
at [1]?  Can you take a look at these instructions and figure out why they
are not closing the pull requests?

It would be worth it to see how spark is pulling stuff in.  Their PRs look
nice: https://github.com/apache/spark/pull/14695

[1] https://cwiki.apache.org/confluence/display/RYA/Contributing+to+Rya

On Thu, Aug 18, 2016 at 9:14 AM Aaron D. Mihalik
wrote:


Go ahead and pull in changes.  That branch is in a bad state and will be
deleted.  Caleb and I will resume the release today.

On Thu, Aug 18, 2016 at 9:00 AM Puja Valiyil  wrote:


Hey Aaron and Caleb,
I saw that there was a release branch.  Should we hold off on merging
things into develop while you are working on the release?  I had put off
merging pull requests while you guys were actively working so that it
wouldn't be adding work, but there are a lot of requests at this point
that
should be pulled in.  Let me know if its ok to start pulling stuff in or
if
that will just add more work to what you all are currently doing.
Thanks,
Puja

Re: maven issue for 3.2.10 release

[Josh Elser]

I'd concur with your assessment, Aaron. I would think that you should 
just remove that configuration from the maven-release-plugin. One less 
command to have to "know about" to make a release (I love projects that 
are as simple as "mvn release:prepare; mvn release:perform").


Similarly, allowTimestampedSnapshots=true seems like a bad idea on the 
release-plugin's configuration.


Aaron D. Mihalik wrote:

I'm able to perform most of the steps for the release from the command line
(e.g. build rya, sign and deploy snapshot artifacts, create and tag git
branches), but I don't see my 3.2.10 artifacts in the staging repository
[1].

I'm following the instructions from here [2].

I think it's an issue with my "mvn release:perform" command.  I looked
through the logs and it says "Executing goals 'install'..." and I expected
it to say "deploy".  Note the log snippet at the end of my email below.

I'm pretty sure this is because (for some reason) our we override the maven
release goal to "install" [3].  I've tried overriding this on the command
line, but it didn't work.

I checked my local m2 repo, and all of the 3.2.10 artifacts are correctly
installed.

I figure I have two options:
1. Remove the override in the POM, commit the change to 3.2.10-SNAPSHOT and
redo the release.

2. run "mvn deploy -Papache-release" from the 3.2.10 directory created
during the "mvn release:perform" command

Here are my exact commands:

1.Checkout out code
git clone https://git-wip-us.apache.org/repos/asf/incubator-rya.git
incubator-rya-apache

2. Create release candidate branch
git checkout -b 3.2.10-RC1 develop
git push -u origin 3.2.10-RC1

3. Build Rya, prepare and perform release (note I'm skipping tests because
I've run them all before on the snapshots and release)
mvn clean package -Papache-release -DskipTests
mvn release:prepare  -Darguments="-DskipTests"
mvn release:perform -Darguments="-DskipTests" -Dgoals=deploy

4. Delete "3.2.10" tag create during prepare
git tag -d 3.2.10
git push origin :refs/tags/3.2.10

--Aaron


[1] https://repository.apache.org/#stagingRepositories
[2] http://www.apache.org/dev/publishing-maven-artifacts.html#prepare-poms
[3] https://github.com/apache/incubator-rya/blob/develop/pom.xml#L621

Maven logs:

2650 [main] [INFO]
org.apache.maven.shared.release.phase.CheckoutProjectFromScm - Checking out
the project to perform the release ...

2673 [main] [INFO] org.apache.maven.scm.manager.plexus.DefaultScmManager -
Executing: /bin/sh -c cd
/Users/mihalik/Documents/workspace/incubator-rya-apache/target&&  git clone
--branch 3.2.10 https://git-wip-us.apache.org/repos/asf/incubator-rya.git
/Users/mihalik/Documents/workspace/incubator-rya-apache/target/checkout

2673 [main] [INFO] org.apache.maven.scm.manager.plexus.DefaultScmManager -
Working directory:
/Users/mihalik/Documents/workspace/incubator-rya-apache/target

11528 [main] [INFO] org.apache.maven.scm.manager.plexus.DefaultScmManager -
Executing: /bin/sh -c cd /var/folders/qw/7lbq60nx48n01zhm4jvrj0rrgn/T/
&&  git ls-remote https://git-wip-us.apache.org/repos/asf/incubator-rya.git

11528 [main] [INFO] org.apache.maven.scm.manager.plexus.DefaultScmManager -
Working directory: /var/folders/qw/7lbq60nx48n01zhm4jvrj0rrgn/T

12037 [main] [INFO] org.apache.maven.scm.manager.plexus.DefaultScmManager -
Executing: /bin/sh -c cd
/Users/mihalik/Documents/workspace/incubator-rya-apache/target/checkout&&
git fetch https://git-wip-us.apache.org/repos/asf/incubator-rya.git

12037 [main] [INFO] org.apache.maven.scm.manager.plexus.DefaultScmManager -
Working directory:
/Users/mihalik/Documents/workspace/incubator-rya-apache/target/checkout

12565 [main] [INFO] org.apache.maven.scm.manager.plexus.DefaultScmManager -
Executing: /bin/sh -c cd
/Users/mihalik/Documents/workspace/incubator-rya-apache/target/checkout&&
git checkout 3.2.10

12565 [main] [INFO] org.apache.maven.scm.manager.plexus.DefaultScmManager -
Working directory:
/Users/mihalik/Documents/workspace/incubator-rya-apache/target/checkout

12654 [main] [INFO] org.apache.maven.scm.manager.plexus.DefaultScmManager -
Executing: /bin/sh -c cd
/Users/mihalik/Documents/workspace/incubator-rya-apache/target/checkout&&
git ls-files

12654 [main] [INFO] org.apache.maven.scm.manager.plexus.DefaultScmManager -
Working directory:
/Users/mihalik/Documents/workspace/incubator-rya-apache/target/checkout

12684 [main] [INFO]
org.apache.maven.shared.release.phase.RunPerformGoalsPhase - Invoking
perform goals in directory
/Users/mihalik/Documents/workspace/incubator-rya-apache/target/checkout

12684 [main] [INFO]
org.apache.maven.shared.release.phase.RunPerformGoalsPhase - Executing
goals 'install'...

Re: Minutes from Rya Working Group

[Josh Elser]

Great, thanks for the clarification, Puja!

Puja Valiyil wrote:

I think what Josh said is in line with what we were thinking.  The thought
would be that if any design work is done before starting a feature, that
design work would be posted to confluence or the dev list so that the
entire community has an opportunity to comment on it.  There isn't an
expectation that one would wait for comments prior to starting work, but at
the same time it provides more insight into things that are being actively
worked than just jira might.  Significant decisions should be proposed and
debated on the dev list.

On Thu, Aug 11, 2016 at 11:36 AM, Josh Elser  wrote:



Josh Elser wrote:


We spent some time talking through Jira and how as a community we need to

document and conform to standard definitions about jira states.  We
decided
to increase community involvement by:
1.  Establishing WIP pull requests: If a developer has started work, they
should not wait until the work has finished to submit the pull request.
Instead they can submit WIP pull requests and receive feedback as they
develop the feature.
2.  Moving more design discussions to confluence and the dev list:
Rather
than having discussions over email (which may happen outside of the dev
list), we should move more discussions related to design to confluence,
jira, and the dev list


Err, hold up. Discussions *must* happen on email. Are discussions
happening outside of the dev list now? The in-person meetings are OK to
talk about ideas, but just reporting minutes and decisions agreed upon
by the IRL attendees is not OK.


Realized that I didn't do a good job clarifying this late last night.

Discussions can (and do) happen offline. The Apache Way isn't trying to
assert that this cannot happen. The distinction is that project _decisions_
should not be made in these offline discussions. Ideas/proposals can be
thought up offline, but the community at large must still have the ability
to participate in discussion.


IMO, email is still the best way to have interactive discussion, but

recording design decisions and architectures on Confluence as reference
material sounds like a good idea to me.

Re: Minutes from Rya Working Group

[Josh Elser]

Josh Elser wrote:

We spent some time talking through Jira and how as a community we need to
document and conform to standard definitions about jira states.  We
decided
to increase community involvement by:
1.  Establishing WIP pull requests: If a developer has started work, they
should not wait until the work has finished to submit the pull request.
Instead they can submit WIP pull requests and receive feedback as they
develop the feature.
2.  Moving more design discussions to confluence and the dev list:
Rather
than having discussions over email (which may happen outside of the dev
list), we should move more discussions related to design to confluence,
jira, and the dev list


Err, hold up. Discussions *must* happen on email. Are discussions
happening outside of the dev list now? The in-person meetings are OK to
talk about ideas, but just reporting minutes and decisions agreed upon
by the IRL attendees is not OK.


Realized that I didn't do a good job clarifying this late last night.

Discussions can (and do) happen offline. The Apache Way isn't trying to 
assert that this cannot happen. The distinction is that project 
_decisions_ should not be made in these offline discussions. 
Ideas/proposals can be thought up offline, but the community at large 
must still have the ability to participate in discussion.



IMO, email is still the best way to have interactive discussion, but
recording design decisions and architectures on Confluence as reference
material sounds like a good idea to me.

Re: Minutes from Rya Working Group

[Josh Elser]

Puja Valiyil wrote:

Aaron and Caleb talked about the status of the release.  They described the
remaining steps and outlined what they are planning to do this week to for
creating the release.  Aaron had a question about gpg maven tools.


Were these left outstanding? I have a little bit of experience here.


We spent some time talking through Jira and how as a community we need to
document and conform to standard definitions about jira states.  We decided
to increase community involvement by:
1.  Establishing WIP pull requests: If a developer has started work, they
should not wait until the work has finished to submit the pull request.
Instead they can submit WIP pull requests and receive feedback as they
develop the feature.
2.  Moving more design discussions to confluence and the dev list:  Rather
than having discussions over email (which may happen outside of the dev
list), we should move more discussions related to design to confluence,
jira, and the dev list


Err, hold up. Discussions *must* happen on email. Are discussions 
happening outside of the dev list now? The in-person meetings are OK to 
talk about ideas, but just reporting minutes and decisions agreed upon 
by the IRL attendees is not OK.


IMO, email is still the best way to have interactive discussion, but 
recording design decisions and architectures on Confluence as reference 
material sounds like a good idea to me.



We also decided to make the Rya working group alternate between
prioritizing bugs in jira and community outreach.

The next working group will be in two weeks and will focus on prioritizing
tasks in jira and putting together a road map for the project.  The working
group after that will discuss how to add a new backend persistence to Rya.

Thanks,
Puja

Re: [DISCUSS] let's try a release

[Josh Elser]

Aaron --

Comments?

Puja Valiyil wrote:

Aaron had signed himself up a few months ago, I'm not sure how far he got 
though.

Sent from my iPhone


On Jul 31, 2016, at 2:00 AM, Sean Busbey  wrote:

Hi folks!

Anyone up for acting as the community's first release manager? It's
been a while, and working through the process of doing a release is
something that takes practice so it's good to get in the habit.

Mostly offline 7/24-7/30

[Josh Elser]

Just a heads up if anyone needs to get in touch. Expect delayed list 
responses from me next week.


Reach out directly if there's anything urgent.

- Josh

Re: July incubator podling report -- please comment

[Josh Elser]

LGTM. Added my signoff.

Thanks for the community effort!

Adina Crainiceanu wrote:

I posted the report on the Incubator wiki. Let me know if there are any
updates to be made before Wednesday when it is due.

Thanks,
Adina

On Fri, Jul 1, 2016 at 2:58 PM, Puja Valiyil  wrote:


Updates below.  I don't think that I will be able to post this to the
incubator wiki -- could someone please copy and paste this once it is has
been signed off on?



Rya

Rya (pronounced "ree-uh" /rēə/) is a cloud-based RDF triple store that
supports SPARQL queries. Rya is a scalable RDF data management system built
on top of Accumulo. Rya uses novel storage methods, indexing schemes, and
query processing techniques that scale to billions of triples across
multiple nodes. Rya provides fast and easy access to the data through
SPARQL, a conventional query mechanism for RDF data.

Rya has been incubating since 2015-09-18.

Three most important issues to address in the move towards graduation:

   1. Become familiar with the release process and have a first release as
part of the Apache Foundation
   2. Expand the documentation to be more formalized and more representative
of the current codebase.
   3. Add new committers to the project.

Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
aware of?

No

How has the community developed since the last report?

* We have a Rya "office hour" teleconference every other week. Users and
developers can ask questions, receive answers, discuss ideas for future
developments. The minutes are sent to the dev@ list.   Attendance at these
meetings has grown beyond existing committers of the project to include new
contributors.  New contributors have led the discussion for new features
that they have helped develop.  We have also begun posting minutes and
reference slides from the meetings on confluence to provide reference
documentation to new contributors.
* We have more PRs from non-committers which are integrated into the
repository
   * Developed more extensive Rya website and confluence page for
documentation for new contributors

How has the project developed since the last report?

   * Integrated Rya with Apache build process -- Rya is currently being
built by Jenkins on Apache servers
   * Resolved a handful of issues that users have encountered.
   * Upgrades for versions for a number of dependencies
   * Committed features: advanced OWL forward chaining reasoning tool for
Accumulo based Rya, extensions to pre-computed join capabilities for more
complex SPARQL queries, additions of timestamps for Mongo backed Rya.


Date of last release:

   Not applicable

When were the last committers or PMC members elected?

   Not applicable.  The PMC is currently discussing inviting a couple of
active contributors to become committers.

Signed-off-by:

   [ ](rya) Josh Elser
   [ ](rya) Edward J. Yoon
   [ ](rya) Sean Busbey
   [ ](rya) Venkatesh Seetharam

On Fri, Jul 1, 2016 at 2:23 AM, Josh Elser  wrote:


Was the website up when the last report was written? I agree with Adina;
afaik, the website is good. Should def call that out if it is new.

Otherwise, agree with Sean's point and it LGTM.
On Jun 30, 2016 6:04 PM, "Adina Crainiceanu"  wrote:


I agree with Sean that we should mention that the PPMC is currently
considering new committer additions.

I would also remove the second point in the "three most important

issues

to

address in the move toward graduation" - I think that the "how to
contribute" from the website + confluence is OK, even if it can be
improved.

I think the report looks good. Thank you Puja for taking the lead on

this.

If you don't have permission to edit the incubator wiki, you need to

create

an account and send email to gene...@incubator.apache.org to ask
permission
to edit (make sure you include your wiki username)

Thanks,
Adina


On Thu, Jun 30, 2016 at 12:21 PM, Sean Busbey

wrote:

if the PPMC is considering new committer additions, it's worth noting
in the report.
especially since the situation described under community development
sounds like we ought to be.

the specific folks under consideration should not be mentioned,

natch,

just if the PPMC is currently in the discussion phase.

On Thu, Jun 30, 2016 at 8:37 AM, Puja Valiyil

wrote:

Rya

Rya (pronounced "ree-uh" /rēə/) is a cloud-based RDF triple store

that

supports SPARQL queries. Rya is a scalable RDF data management

system

built

on top of Accumulo. Rya uses novel storage methods, indexing

schemes,

and

query processing techniques that scale to billions of triples

across

multiple nodes. Rya provides fast and easy access to the data

through

SPARQL, a conventional query mechanism for RDF data.

Rya has been incubating since 2015-09-18.

Three most important issues to address in the move towards

graduation:

   1. Become familiar with the release process and have a first

release

as

Commendations on a good website

[Josh Elser]

ICYMI, general@incubator has been having a discussion around branding of 
podling websites


https://wiki.apache.org/incubator/BrandingAuditJune2016

Of the two facets measured, Rya passed both with flying colors.

Good job :)

- Josh

Re: July incubator podling report -- please comment

[Josh Elser]

Was the website up when the last report was written? I agree with Adina;
afaik, the website is good. Should def call that out if it is new.

Otherwise, agree with Sean's point and it LGTM.
On Jun 30, 2016 6:04 PM, "Adina Crainiceanu"  wrote:

> I agree with Sean that we should mention that the PPMC is currently
> considering new committer additions.
>
> I would also remove the second point in the "three most important issues to
> address in the move toward graduation" - I think that the "how to
> contribute" from the website + confluence is OK, even if it can be
> improved.
>
> I think the report looks good. Thank you Puja for taking the lead on this.
> If you don't have permission to edit the incubator wiki, you need to create
> an account and send email to gene...@incubator.apache.org to ask
> permission
> to edit (make sure you include your wiki username)
>
> Thanks,
> Adina
>
>
> On Thu, Jun 30, 2016 at 12:21 PM, Sean Busbey  wrote:
>
> > if the PPMC is considering new committer additions, it's worth noting
> > in the report.
> > especially since the situation described under community development
> > sounds like we ought to be.
> >
> > the specific folks under consideration should not be mentioned, natch,
> > just if the PPMC is currently in the discussion phase.
> >
> > On Thu, Jun 30, 2016 at 8:37 AM, Puja Valiyil  wrote:
> > > Rya
> > >
> > > Rya (pronounced "ree-uh" /rēə/) is a cloud-based RDF triple store that
> > > supports SPARQL queries. Rya is a scalable RDF data management system
> > built
> > > on top of Accumulo. Rya uses novel storage methods, indexing schemes,
> and
> > > query processing techniques that scale to billions of triples across
> > > multiple nodes. Rya provides fast and easy access to the data through
> > > SPARQL, a conventional query mechanism for RDF data.
> > >
> > > Rya has been incubating since 2015-09-18.
> > >
> > > Three most important issues to address in the move towards graduation:
> > >
> > >   1. Become familiar with the release process and have a first release
> as
> > > part of the Apache Foundation
> > >   2. Expand the "how to" document to explain the ways new contributors
> > can
> > > become involved in the project, so we increase the size of the
> community.
> > >   3. Add new committers to the project.
> > >
> > > Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
> > > aware of?
> > >
> > > No
> > >
> > > How has the community developed since the last report?
> > >
> > >* We have a Rya "office hour" teleconference every other week. Users
> > and
> > > developers can ask questions, receive answers, discuss ideas for future
> > > developments. The minutes are sent to the dev@ list.   Attendance at
> > these
> > > meetings has grown beyond existing committers of the project to include
> > new
> > > contributors.  New contributors have led the discussion for new
> features
> > > that they have helped develop.  We have also begun posting minutes and
> > > reference slides from the meetings on confluence to provide reference
> > > documentation to new contributors.
> > >* We have more PRs from non-committers which are integrated into the
> > > repository
> > >
> > > How has the project developed since the last report?
> > >
> > >   * Integrated Rya with Apache build process -- Rya is currently being
> > > built by Jenkins on Apache servers
> > >   * Resolved a handful of issues that users have encountered.
> > >   * Upgrades for versions for a number of dependencies
> > >   * Committed features: advanced OWL forward chaining reasoning tool
> for
> > > Accumulo based Rya, extensions to pre-computed join capabilities for
> more
> > > complex SPARQL queries, additions of timestamps for Mongo backed Rya.
> > >
> > >
> > > Date of last release:
> > >
> > >   Not applicable
> > >
> > > When were the last committers or PMC members elected?
> > >
> > >   Not applicable
> > >
> > > Signed-off-by:
> > >
> > >   [ ](rya) Josh Elser
> > >   [ ](rya) Edward J. Yoon
> > >   [ ](rya) Sean Busbey
> > >   [ ](rya) Venkatesh Seetharam
> >
>
>
>
> --
> Dr. Adina Crainiceanu
> Associate Professor, Computer Science Department
> United States Naval Academy
> 410-293-6822
> ad...@usna.edu
> http://www.usna.edu/Users/cs/adina/
>