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

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=id4=title+of+id4=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 <bil...@apache.org>:


Sounds good to me.

On Mon, Apr 2, 2018 at 10:54 AM, Adina Crainiceanu <ad...@usna.edu> 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=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 <e.bijsterbo...@gmail.com> 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 <els...@apache.org>:


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]

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 <els...@apache.org> 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]

lease feel free to add your own commentary.

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

Date of last release:

   2017-03-25

When were the last committers or 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 si

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 <ad...@usna.edu> 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 <puja...@gmail.com> 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 <ad...@usna.edu> 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=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: [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

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=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=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 <els...@apache.org> 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 <els...@apache.org> 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.

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=CwIFAg=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq
10=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8=flalrOvFDeLMSCH8lQT
PrIxrM9msw2zGlvhUVqX5zHw=Bg6BsDNSH_cDn72IjWIW2yBbeUafd1Q8Q6QSIO21hm4
=

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: 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: 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: 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

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<els...@apache.org> 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<els...@apache.org>  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=Html=12319020
[2] https://github.com/apache/incubator-rya-site


On Mon, Oct 31, 2016 at 12:54 PM Josh Elser<els...@apache.org>  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=Html=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 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=Html=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<aaron.miha...@gmail.com>
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<puja...@gmail.com>  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<josh.el...@gmail.com>  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=Html=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/<whatever" which will prevent it from being force-push 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: 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: [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<els...@apache.org
<javascript:_e(%7B%7D,'cvml','els...@apache.org');>>  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 ho

[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<els...@apache.org>
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 re

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<els...@apache.org>
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=CwICAw=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8=PlHBkcTuE9DcvVb1m3V1nCNNRsvZnLKrtMK1AKmYSY0=43QIBqVfsjovifro22HiGqmGW3Q9qY4xvKVtqPzv_x8=


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<vseetha...@gmail.com> 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<dlo...@gmail.com> 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 

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<els...@apache.org>
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=CwICAw=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8=PlHBkcTuE9DcvVb1m3V1nCNNRsvZnLKrtMK1AKmYSY0=43QIBqVfsjovifro22HiGqmGW3Q9qY4xvKVtqPzv_x8=

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<vseetha...@gmail.com>   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<dlo...@gmail.com>   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<vseetha...@gmail.com>
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<puja...@gmail.com>   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:

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 

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<ad...@usna.edu>  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
rep

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<caleb.me...@parsons.com>
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<els...@apache.org>  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=CwIFAg=Nwf-pp4xtYRe0sCRVM8_
LWH54joYF7EKmrYIdfxIq10=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8=
USEC4e6JdxuZZwMB0AkZPzHtdsKWf8ep6g5BSRLQ2XY=
wnYDdDdgR8EEFav9sKC7ftd6ZjSJcOXU8FISG6jJMHc=

[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=CwIFAg=Nwf-
pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10=vuVdzYC2kksVZR5STiFwDpzJ7CrMHC
geo_4WXTD0qo8=USEC4e6JdxuZZwMB0AkZPzHtdsKWf8ep6g5BSRLQ2XY=
ZFTL5gQzyzLvRcWrafGrCobMJ8d1DWSmZlIVz9M7EuQ=

[3] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.

com_apache_nifi_blob_master_pom.xml-23L1316=CwIFAg=
Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10=
vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8=
U

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 

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<els...@apache.org>  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. can be found at:


https://repository.apache.org/content/reposito

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 

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

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: 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<puja...@gmail.com>  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<josh.el...@gmail.com>  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"<ad...@usna.edu>  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<bus...@apache.org>

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<puja...@gmail.com>

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 

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" <ad...@usna.edu> 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 <bus...@apache.org> 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 <puja...@gmail.com> 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/
>

Re: Inatall Apche Yetus test-patch for pre-commit checks

[Josh Elser]

The --jenkins argument isn't using a Jenkins instance, Amila, it's just 
an option to trigger things that would happen when it's being invoked by 
a Jenkins server (which you're not actually doing). For example, that's 
why it's trying to write a report to JIRA instead of just printing it 
out locally.


Have Adina (or anyone else on the project with the karma) create a 
PreCommit job on the ASF jenkins (or just copy Accumulo's[1]), and work 
with them to modify the configuration to run against Rya. Because you 
are not a committer, you can't have access to do this yourself.


[1] 
https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-ACCUMULO-Build/


Amila Wijayarathna wrote:

Hi josh,

Thank you for replying.
I made a local patch file and I could successfully ran Yetus with it. After
that I successfully  ran yetus with complete url of PR patches as a patch

Now i need to integrate jenkins with yetus. As I have locally installed
jenkins, I ran the test patch with --jenkins command and got this result
[1]. But in jenkins server there is no any changes made.
Can i know what are the configuration that need to change when integrate
yetus to locally installed jenkins.
I searched about this but unfortunately i couldn't find any.

[1]
https://gist.github.com/AmilaWijayarathna/00ca81c7090db79225efbd3edae31e37

Thank you!

On Thu, Jun 2, 2016 at 1:04 AM, Josh Elser<josh.el...@gmail.com>  wrote:


Amila,

Typically, the next step is to write a Yetus personality for the project.

As an example:
https://github.com/apache/yetus/blob/rel/0.3.0/precommit/personality/accumulo.sh

You can then do the following on JIRA issues that are in "Patch Available"

./test-patch.sh --project=rya RYA-123

or, I believe you could give it the complete URL to a patch

./test-patch.sh --project=rya
https://github.com/apache/incubator-rya/pull/39.patch


Amila Wijayarathna wrote:


Hi all,

I'm trying to install yetus  test-patch in my ubuntu laptop and need to
know how to use Apache Yetus test-patch for the pre-commit checks.

I downloaded yetus-0.3.0-bin.tar.gz from [1] and went through [2] and
installed base requirements also.

And I'm not sure how to proceed further.
Can some one please guide me on what is the procedure to follow when doing
this?

[1]

https://www.apache.org/dyn/closer.lua?path=/yetus/0.3.0/yetus-0.3.0-bin.tar.gz
[2] http://yetus.apache.org/documentation/0.2.1/precommit-basic/

Thank you very much!

Re: compile with accumulo 1.7.1

[Josh Elser]

Ok, it looks like the two offending usages (at first glance) are 
ArgumentChecker and AbstractRecordReader. Neither of these are Accumulo 
public API (nor are they intended to be). The former is easily replaced 
in Rya with Guava's Preconditions or Objects in JDK7+.


The latter might be a little more difficult, but should really just 
inherit from the RecordReader in Hadoop. I'll open up a JIRA issue for this.


Josh Elser wrote:

 From the Accumulo side of things, this is very concerning to me.
Anything using the Accumulo public API should work across any
maintenance release (1.7.x).

Maybe this is a sign that Rya is using something it shouldn't be (or
Accumulo needs to expand its definition of public API to include
something else).

Ly, Kiet wrote:

How hard is it to update rya to use accumulo 1.7.x? Develop branch
failed to compile with accumulo 1.7.1.

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: compile with accumulo 1.7.1

[Josh Elser]

From the Accumulo side of things, this is very concerning to me. 
Anything using the Accumulo public API should work across any 
maintenance release (1.7.x).


Maybe this is a sign that Rya is using something it shouldn't be (or 
Accumulo needs to expand its definition of public API to include 
something else).


Ly, Kiet wrote:

How hard is it to update rya to use accumulo 1.7.x? Develop branch failed to 
compile with accumulo 1.7.1.

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: Jenkins job

[Josh Elser]

+1 Apache Yetus is a great starting point (and makes it easy to run the 
same test(s) locally). I am embarrassed that I have not mentioned it 
myself :)


Sean Busbey wrote:

Any particular reason y'all are aiming at using Travis CI for PR
evaluation rather than the ASF Jenkins?

I ask because my next suggestion is to look at Apache Yetus
Test-Patch[1] for automating a bunch of contribution checks (beyond
just "running maven"). I know we have examples to point to for using
it on jenkins, but I don't have a working example on Travis-CI yet.


[1]: http://yetus.apache.org/documentation/0.2.1/precommit-basic/

On Tue, May 10, 2016 at 6:35 AM, Adina Crainiceanu<ad...@usna.edu>  wrote:

Yes, integrating performance testing is part of the project. Maybe we can
talk about ways to achieve that during the next Rya meeting.

Thanks,
Adina

On Mon, May 9, 2016 at 4:53 PM, Puja Valiyil<puja...@gmail.com>  wrote:


Integrating Travis ci sounds good! Some tests don't run well on my Windows
box so that would be super useful!
Beyond that we had said integrating some performance benchmarking into the
infrastructure was a good use of his time?

Sent from my iPhone


On May 9, 2016, at 1:58 PM, Adina Crainiceanu<ad...@usna.edu>  wrote:

Aaron, Josh, Puja,

 From the discussion during the office hours last week and the link Josh
sent, I understand that the continuous integration for Rya is set, just
some details need to be taken care of (set the job to run automatically).
Is that correct? If not, is there something that Amila can do for the
continuous integration task?


Here is a paragraph from Amila's original proposal. I want to know if any
of it still needs to be done/can be done by Amila.

"As the first step, I will integrate RYA build to jenkins[1] and
travisCI[2]. By using jenkins and travisCI, we can automate RYA build per
commit basis or per daily basis. We can use either way we prefer, but I
believe per commit is more suitable since then we can identify if any
commit cause to any build failure or test failure. Jenkins is an open
source tool to perform continuous integration and build automation. We

can

use apache jenkins servers to run RYA jenkins build jobs. I have to

discuss

with apache­infrastructure team also about how to achieve this and I have
already started a mailing thread in their mailing list. TravisCI is also

a

continuous integration tool which I am planning to configure with RYA
build. By using travisCI, we can get a build status per every PR that a
contributor send, so when merging PRs committers don’t need to run and
check them again."


Thank you,
Adina


On Wed, May 4, 2016 at 1:03 PM, Josh Elser<josh.el...@gmail.com>

wrote:

https://builds.apache.org/job/incubator-rya-develop/

It looks like there hasn't been a build since 2016/04/07. So, the job is
there to run, it's just not automatically being run.

- Josh



--
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/

Jenkins job

[Josh Elser]

https://builds.apache.org/job/incubator-rya-develop/

It looks like there hasn't been a build since 2016/04/07. So, the job is 
there to run, it's just not automatically being run.


- Josh

Re: Rya Working Group (April 6, Noon Eastern)

[Josh Elser]

Thanks for sending this out as always! I'll do my best to try to drop in 
and say hello :)


Puja Valiyil wrote:

Oops, let's include the date and time this time!
Rya Working Group
Wednesday, May 4, 2016
12:00 pm  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr
Call-in toll-free number: 1-888-5981409
Attendee access code: 7483409


On Tue, May 3, 2016 at 4:35 PM, Puja Valiyil  wrote:


All,
Just a reminder that we have the Rya working group tomorrow.  This week we
will be going over potential methods of improving client configuration of
Rya through a centralized administration mechanism.  I'm not going to set
up a webex, but we can use the following line for tomorrow's discussion:
Call-in toll-free number: 1-888-5981409
Attendee access code: 7483409
I'll send out slides tomorrow before the working group!
Thanks,
Puja

On Tue, Apr 5, 2016 at 10:29 AM, Aaron D. Mihalik

Re: congratulations to Amila Wijayarathna - GSOC 2016 participant

[Josh Elser]

Congrats, Amila!

Write great code :)

Amila Wijayarathna wrote:

Hi all,
Thank you for helping me past few months regarding to the project. I will
try my level best to make this project a success and looking forward to
work with you all.

Thank you.

Re: Integrate jenkins to Apache-rya incuabator.

[Josh Elser]

(ugh, sorry for the rapid-fire)

Also just restricted where your job will run. The "ubuntu" nodes are 
pretty good (sans the "cloud-slaves"). Some of the nodes in the general 
pool will cause more headache than anything else.


Josh Elser wrote:

You had "Developers" listed and not "Recipient List" in the email
reporter configuration. Switched that and kicked a job.

Josh Elser wrote:

From your console output:

"No emails were triggered."

https://builds.apache.org/job/incubator-rya-develop/6/console

Looks to me like your job isn't configured to mail.

Aaron D. Mihalik wrote:

Thanks Josh. I'm a bit confused, though. We have had two "unstable"
builds today and no notifications. Also, I tried to post to
notificati...@rya.incubator.apache.org and that didn't go through.

Do we need to ping someone to open up
notificati...@rya.incubator.apache.org
?

--Aaron

On Wed, Apr 6, 2016 at 6:41 PM Josh Elser<josh.el...@gmail.com> wrote:


Actually, easy-peasy


https://wiki.apache.org/general/Jenkins#How_do_I_allow_Jenkins_to_mail_to_my_project.27s_.22dev.22_list.3F



You should be good to go. I did those steps for ya.

Josh Elser wrote:

Yeah, there's some shenanigans you can do to allow posts from an
address
that isn't subscribed. I'll have to find the instructions again,
though.
I don't recall what they were anymore.

Aaron D. Mihalik wrote:

Thanks Sean. I added a build for develop [1] and it's uploading Rya
artifacts to the Apache repo [2].

I also configured Jenkins to send notifications@rya (both through the
Jenkins configure page and by sending an email to [3]. But I haven't

seen

any emails on notifications@rya. Does someone need to approve Jenkins
subscribe?

--Aaron

[1] https://builds.apache.org/job/incubator-rya-develop/
[2]


https://repository.apache.org/content/repositories/snapshots/org/apache/rya/



[3] notifications-allow-subscribe-jenkins=
builds.apache@rya.incubator.apache.org

On Tue, Apr 5, 2016 at 10:52 AM Sean Busbey<bus...@apache.org> wrote:


Please be sure you both read the jenkins guidelines:

http://wiki.apache.org/general/Jenkins

in particular, the mandatory job settings and the need to
subscribe to
infrastructure@apache and builds@apache.

On Tue, Apr 5, 2016 at 9:48 AM, Sean Busbey<sean.bus...@gmail.com>
wrote:

all done. You and Puja should have access now.

On Mon, Apr 4, 2016 at 1:50 PM, Aaron D. Mihalik
<aaron.miha...@gmail.com> wrote:

Sean,

Were you able to add Puja and me to the Apache Jenkins server? I
logged
into Jenkins and I don't see the "New Item" button.

Here are user names:

Aaron Mihalik (mihalik)
Puja Valiyil (pujav65)

--Aaron

On Thu, Mar 31, 2016 at 1:09 PM Aaron D. Mihalik<

aaron.miha...@gmail.com>

wrote:


Add me and Puja. One of us will add Rya to the build.

Aaron Mihalik (mihalik)
Puja Valiyil (pujav65)


On Wed, Mar 30, 2016 at 6:54 PM Sean Busbey<bus...@apache.org>

wrote:

yeah I should be able to. let me check tonight to make sure
there's
not some expectation that the IPMC chair do this for podlings.

who all will we be adding?

On Tue, Mar 29, 2016 at 6:47 PM, Josh
Elser<josh.el...@gmail.com>

wrote:

Josh Elser wrote:

I'm not sure how podlings are meant to get karma (as the wiki

page

is

worded in terms of TLP's "PMC Chair"), so that's something I
can

figure

out for you as a mentor.

I don't have the karma to do this (I think I need a PMC chair
person
http://people.apache.org/phonebook.html?service=pmc-chairs)

Sean is on that list -- he may be able to do
`modify_appgroups.pl
hudson-jobadmin --add=` on minotaur.


--
Sean

Re: Integrate jenkins to Apache-rya incuabator.

[Josh Elser]

You had "Developers" listed and not "Recipient List" in the email 
reporter configuration. Switched that and kicked a job.


Josh Elser wrote:

 From your console output:

"No emails were triggered."

https://builds.apache.org/job/incubator-rya-develop/6/console

Looks to me like your job isn't configured to mail.

Aaron D. Mihalik wrote:

Thanks Josh. I'm a bit confused, though. We have had two "unstable"
builds today and no notifications. Also, I tried to post to
notificati...@rya.incubator.apache.org and that didn't go through.

Do we need to ping someone to open up
notificati...@rya.incubator.apache.org
?

--Aaron

On Wed, Apr 6, 2016 at 6:41 PM Josh Elser<josh.el...@gmail.com> wrote:


Actually, easy-peasy


https://wiki.apache.org/general/Jenkins#How_do_I_allow_Jenkins_to_mail_to_my_project.27s_.22dev.22_list.3F


You should be good to go. I did those steps for ya.

Josh Elser wrote:

Yeah, there's some shenanigans you can do to allow posts from an
address
that isn't subscribed. I'll have to find the instructions again,
though.
I don't recall what they were anymore.

Aaron D. Mihalik wrote:

Thanks Sean. I added a build for develop [1] and it's uploading Rya
artifacts to the Apache repo [2].

I also configured Jenkins to send notifications@rya (both through the
Jenkins configure page and by sending an email to [3]. But I haven't

seen

any emails on notifications@rya. Does someone need to approve Jenkins
subscribe?

--Aaron

[1] https://builds.apache.org/job/incubator-rya-develop/
[2]


https://repository.apache.org/content/repositories/snapshots/org/apache/rya/


[3] notifications-allow-subscribe-jenkins=
builds.apache@rya.incubator.apache.org

On Tue, Apr 5, 2016 at 10:52 AM Sean Busbey<bus...@apache.org> wrote:


Please be sure you both read the jenkins guidelines:

http://wiki.apache.org/general/Jenkins

in particular, the mandatory job settings and the need to
subscribe to
infrastructure@apache and builds@apache.

On Tue, Apr 5, 2016 at 9:48 AM, Sean Busbey<sean.bus...@gmail.com>
wrote:

all done. You and Puja should have access now.

On Mon, Apr 4, 2016 at 1:50 PM, Aaron D. Mihalik
<aaron.miha...@gmail.com> wrote:

Sean,

Were you able to add Puja and me to the Apache Jenkins server? I
logged
into Jenkins and I don't see the "New Item" button.

Here are user names:

Aaron Mihalik (mihalik)
Puja Valiyil (pujav65)

--Aaron

On Thu, Mar 31, 2016 at 1:09 PM Aaron D. Mihalik<

aaron.miha...@gmail.com>

wrote:


Add me and Puja. One of us will add Rya to the build.

Aaron Mihalik (mihalik)
Puja Valiyil (pujav65)


On Wed, Mar 30, 2016 at 6:54 PM Sean Busbey<bus...@apache.org>

wrote:

yeah I should be able to. let me check tonight to make sure
there's
not some expectation that the IPMC chair do this for podlings.

who all will we be adding?

On Tue, Mar 29, 2016 at 6:47 PM, Josh Elser<josh.el...@gmail.com>

wrote:

Josh Elser wrote:

I'm not sure how podlings are meant to get karma (as the wiki

page

is

worded in terms of TLP's "PMC Chair"), so that's something I
can

figure

out for you as a mentor.

I don't have the karma to do this (I think I need a PMC chair
person
http://people.apache.org/phonebook.html?service=pmc-chairs)

Sean is on that list -- he may be able to do
`modify_appgroups.pl
hudson-jobadmin --add=` on minotaur.


--
Sean

Re: Looking towards our next IPMC report

[Josh Elser]

Yay. If I can offer my $0.02:

* As you go through the process the first time, update the website 
immediately. Every little step you do, write it down (this will make 
sure that you're not the only person to be able to make a release).
* Automate as much as you possibly can. Ideally, your process should be 
`mvn release:prepare && mvn release:perform` as a Maven project.

* Try to take some help from other projects [1], [2], [3] for starters.
* Ask questions if you get stuck :)

- Josh

[1] http://accumulo.apache.org/releasing.html
[2] http://accumulo.apache.org/verifying_releases.html
[3] http://nifi.apache.org/release-guide.html

Aaron D. Mihalik wrote:

Josh/Venkatesh: I'll take RM for our first release. David put a lot of
effort in researching this process, so I'll look through his notes over the
weekend, start the process, and ping the dev list with questions.

Thanks again for your help.

--Aaron
On Wed, Apr 6, 2016 at 5:55 PM Josh Elser<josh.el...@gmail.com>  wrote:


+1 to Venkatesh's overall message (if I can put words in mouths): don't
get too hung up on "perfect the first time". Showing progress is much
more important.

Seetharam Venkatesh wrote:

Thanks Adina, report looks good. There are quite a few low hanging issues
that can be addressed quickly.


Become familiar with the release process and have a first release as

part

of the Apache Foundation
I have done about 5 incubating releases and can help if someone can
volunteer as an RM. This is not hard and its an easy win for a podling.


Expand the "how to" document to explain the ways new contributors can

become involved in the project
This can start simple and can be iterated. You can also look at what

other

incubating projects are doing.


We have a Rya "office hour" teleconference every other week

Can you also please put this on the confluence wiki so its accessible.

Thanks!
Venkatesh

On Wed, Apr 6, 2016 at 11:40 AM Adina Crainiceanu<ad...@usna.edu>

wrote:

I submitted the report. Sorry for waiting till the last minute - I

wanted

to have a website first :)

Thank you,
Adina

On Wed, Apr 6, 2016 at 2:30 PM, Seetharam Venkatesh<
venkat...@innerzeal.com

wrote:
Hey folks, the report is to be signed off today and I do not see it

being

filled at http://wiki.apache.org/incubator/April2016.

Appreciate if one of you could take care of this asap.

Thanks!
Venkatesh

On Wed, Feb 24, 2016 at 7:26 AM Sean Busbey<bus...@apache.org>   wrote:


For those interested in posting feedback, the website jira is RYA-42

On Wed, Feb 24, 2016 at 8:31 AM, Adina Crainiceanu<ad...@usna.edu>

wrote:

I created a JIRA ticket for the website. If anyone has specific ideas

for

it, please fell free to mention/implement them. Otherwise I'll try to
use/customize the apache-website-template available at
https://github.com/apache/apache-website-template/ as soon as

possible,

but

definitely before the next report is due

Adina

On Tue, Feb 23, 2016 at 10:01 PM, Puja Valiyil<puja...@gmail.com>

wrote:

David and I tried to compile a process for creating a release -- we

didn't

get that far.  The main thing blocking us at this point is the whole
process for signing a release, no one we knew had a public key and

then

David and I got lost/confused when trying to generate and register

one.

All of this sounds borderline embarrassing since there is a lot of
documentation out there but we didn't have time to fully digest it

in

time.
I'm also not clear on what else we would need to do besides run mvn
release, like compile release notes, etc.  I'm sorry if there's a

lot

of

documentation exactly detailing what we need to do.
Other than that, I think we've made a lot of progress as a community

this

past month.  We've had a lot of new contributors, had a lot of new

bugs

reported by new end users, and have closed out a lot of issues.

On Tue, Feb 23, 2016 at 3:18 PM, Sean Busbey<bus...@apache.org>

wrote:

Heya Rya!

We're about 5-6 weeks from our next scheduled turn for the IPMC's

board

report.

How are folks doing? The project sounds a bit quiet to me, but I'm

not

sure how much of that is me being sure to look in the right

places.

To Review, here are your self-identified three most important

objectives:

1. Populate the website for the project
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. Become familiar with the release process and have a first

release as

   part of the Apache Foundation

At least to me, numbers 1 and 3 seem like big barriers to getting

new

folks brought in. Anyone have a list of the blockers keeping us

from

those two? I tried searching the jira for relevant tickets, but

didn't

find any.

-Sean



--
Dr. Adina Crainiceanu
http://www.usna.edu/Users/cs/adina/


--
Dr. Adina Crainiceanu
http://www.usna.edu/Users/cs/adina/

Re: Integrate jenkins to Apache-rya incuabator.

[Josh Elser]

Actually, easy-peasy

https://wiki.apache.org/general/Jenkins#How_do_I_allow_Jenkins_to_mail_to_my_project.27s_.22dev.22_list.3F

You should be good to go. I did those steps for ya.

Josh Elser wrote:

Yeah, there's some shenanigans you can do to allow posts from an address
that isn't subscribed. I'll have to find the instructions again, though.
I don't recall what they were anymore.

Aaron D. Mihalik wrote:

Thanks Sean. I added a build for develop [1] and it's uploading Rya
artifacts to the Apache repo [2].

I also configured Jenkins to send notifications@rya (both through the
Jenkins configure page and by sending an email to [3]. But I haven't seen
any emails on notifications@rya. Does someone need to approve Jenkins
subscribe?

--Aaron

[1] https://builds.apache.org/job/incubator-rya-develop/
[2]
https://repository.apache.org/content/repositories/snapshots/org/apache/rya/

[3] notifications-allow-subscribe-jenkins=
builds.apache@rya.incubator.apache.org

On Tue, Apr 5, 2016 at 10:52 AM Sean Busbey<bus...@apache.org> wrote:


Please be sure you both read the jenkins guidelines:

http://wiki.apache.org/general/Jenkins

in particular, the mandatory job settings and the need to subscribe to
infrastructure@apache and builds@apache.

On Tue, Apr 5, 2016 at 9:48 AM, Sean Busbey<sean.bus...@gmail.com>
wrote:

all done. You and Puja should have access now.

On Mon, Apr 4, 2016 at 1:50 PM, Aaron D. Mihalik
<aaron.miha...@gmail.com> wrote:

Sean,

Were you able to add Puja and me to the Apache Jenkins server? I
logged
into Jenkins and I don't see the "New Item" button.

Here are user names:

Aaron Mihalik (mihalik)
Puja Valiyil (pujav65)

--Aaron

On Thu, Mar 31, 2016 at 1:09 PM Aaron D. Mihalik<

aaron.miha...@gmail.com>

wrote:


Add me and Puja. One of us will add Rya to the build.

Aaron Mihalik (mihalik)
Puja Valiyil (pujav65)


On Wed, Mar 30, 2016 at 6:54 PM Sean Busbey<bus...@apache.org> wrote:


yeah I should be able to. let me check tonight to make sure there's
not some expectation that the IPMC chair do this for podlings.

who all will we be adding?

On Tue, Mar 29, 2016 at 6:47 PM, Josh Elser<josh.el...@gmail.com>

wrote:

Josh Elser wrote:

I'm not sure how podlings are meant to get karma (as the wiki page

is

worded in terms of TLP's "PMC Chair"), so that's something I can

figure

out for you as a mentor.


I don't have the karma to do this (I think I need a PMC chair
person
http://people.apache.org/phonebook.html?service=pmc-chairs)

Sean is on that list -- he may be able to do `modify_appgroups.pl
hudson-jobadmin --add=` on minotaur.



--
Sean

Re: Work on populate website for Rya RYA-42

[Josh Elser]

Wow, the website looks really great, Adina! Well done.

I'm very happy to see the incubator disclaimer on there, the necessary 
links to Apache documents, and some "getting involved" instructions.


The only comment I have (per policy as a podling) is that "Apache Rya" 
should really be "Apache Rya (incubating)". I know it's very pedantic, 
but that is the project's "proper" name until it graduates to a TLP (it 
has lots of other implications to be a TLP and not just a podling).


Adina Crainiceanu wrote:

David, I have an initial website working for Rya - it uses jekyll and is
based on the apache-website-template (similar with
systemml.incubator.apache.org). I was planning on committing the new
website  today, and then people can improve it. All the ideas you mentioned
sound great and it would be good if you or someone else can help with
implementation.

Adina

On Wed, Apr 6, 2016 at 6:49 AM, Aaron D. Mihalik
wrote:


Yeah. Googling for "ostrich clipart" or "ostrich drawing" turns up a lot of
good ideas too.
On Tue, Apr 5, 2016 at 8:23 PM Puja Valiyil  wrote:


Here's a picture of a rhea from Wikipedia David:
https://en.m.wikipedia.org/wiki/Rhea_(bird)
Sorry for the semi useless input here.

Sent from my iPhone


On Apr 5, 2016, at 3:35 PM, Lotts, David

wrote:

Adina,
I see you have taken on RYA-42 "populate website for Rya".
Funny, I just freed up some of my time hoping to work on developing a

Rya web site.  Do you need any help?  Or do you have it taken care of?
  Or, on the other extreme, maybe you are looking for someone to take it
over?

I came up with a simple Logo that is a re-work of the Accumulo logo,

which means it might be too close for a trademark.  I can share that with
you if you are interested.  A couple people have mentioned name matches:

a

Ria bird and something in outer space named like "Ria".  I have not found
either yet.

Looking at the Accumulo site, it says: "Site created with Bootstrap

including icons from GLYPHICONS and Font Awesome."   The page reformats
when squashing the width, which is nice for mobile screens and desktops,

so

I thought we might do the same.

david.

Re: April 2016 ASF report - please comment

[Josh Elser]

Awesome. I appreciate you trying to make this as accessible as possible!

Puja Valiyil wrote:

This is mostly my fault-- I had thought that having these would spur more 
development, but the fact that Aaron and my office blocks google hangouts has 
made this difficult.  I'll see about distributing my work telecon line-- that 
would allow for the meeting to be recorded as well.
Also, we have had significantly more development this past month than the 
report indicates.  Some features I can think off the top of my head:
1.  Free text search support for mongo db
2.  Additional geo indexing for mongodb
3.  Extensions of examples for both mongo and accumulo backed Rya.
4.   Extensions to query planning to support more complex pre-computed joins

Sent from my iPhone


On Mar 30, 2016, at 5:51 PM, Josh Elser<josh.el...@gmail.com>  wrote:

Sean Busbey wrote:

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


Currently I think folks have to reach out to get the telecon details.
Any plans for it to be posted on the website? Along with a schedule?
Maybe recordings?

Totally agree. Having meetings is fine, but you need to make sure everyone has 
equal opportunity to be a part of it. Personally, I think I've missed two that 
I could have attended because of short-notice.

Re: April 2016 ASF report - please comment

[Josh Elser]

Sean Busbey wrote:

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



Currently I think folks have to reach out to get the telecon details.
Any plans for it to be posted on the website? Along with a schedule?
Maybe recordings?



Totally agree. Having meetings is fine, but you need to make sure 
everyone has equal opportunity to be a part of it. Personally, I think 
I've missed two that I could have attended because of short-notice.

Re: Integrate jenkins to Apache-rya incuabator.

[Josh Elser]

Let me try to suggest a different approach:

If Amila wants to focus on getting a travis-ci build to work, it would 
be very trivial for a committer to copy the command into the "maven 
command" form field in Jenkins. I'm not sure how podlings are meant to 
get karma (as the wiki page is worded in terms of TLP's "PMC Chair"), so 
that's something I can figure out for you as a mentor.


Once the committer has the necessary karma to interact with Jenkins, 
it's dirt simple to copy an existing Jenkins job, change the repository 
location and make sure it runs the expect maven command.


Josh Elser wrote:

Uh, in general, I'm not sure what Amila is going to be able to do
herself. Only people with Apache IDs (e.g. committers) are going to be
allowed to have an account on Jenkins AFAIK. (the wiki page Aaron linked
calls this out).

Aaron D. Mihalik wrote:

The apache build server is here: https://builds.apache.org/

It links to this Jenkins wiki page:
http://wiki.apache.org/general/Jenkins

I tried to log into minotaur.apache.org, but it seems to be in a strange
state. Note that they minotaur.apache.org is in the process of being
decommissioned.

--Aaron


On Fri, Mar 25, 2016 at 12:12 PM Puja Valiyil<puja...@gmail.com> wrote:


Hi Amila,
It might also be worth someone pointing you to the Apache Jenkins site.
That is where we would want the build to be run.
Maybe one of the mentors can point you to the right place?

Sent from my iPhone


On Mar 25, 2016, at 11:04 AM, Amila Wijayarathna<

amwijayarat...@gmail.com> wrote:

Hi Mark,
Thank you for your prompt response. I will go through these links as

well.

Thank you!

On Fri, Mar 25, 2016 at 8:10 PM, Mark Wallace<

mwall...@modusoperandi.com>

wrote:


You're welcome. A couple of other links I found that could be helpful

as

you
are going through things:




http://stackoverflow.com/questions/30576881/jenkins-build-when-a-change-is-pushed-to-github-option-is-not-working





https://learning-continuous-deployment.github.io/jenkins/github/2015/04/17/github-jenkins/


-Mark

-Original Message-
From: Amila Wijayarathna [mailto:amwijayarat...@gmail.com]
Sent: Friday, March 25, 2016 10:37 AM
To: dev@rya.incubator.apache.org
Subject: Re: Integrate jenkins to Apache-rya incuabator.

Hi Mark,

Thank you for your the idea, I will go through this.


On Wed, Mar 23, 2016 at 9:11 PM, Mark Wallace<

mwall...@modusoperandi.com>

wrote:


Generally, there are no Jenkins-specific things you need to do the
software itself. Since the software has a maven build, an automated
build in Jenkins should be easy to set up.

Jenkins will need the ability to pull the software (probably the
development branch). Since the code is public on github, then this
should be no problem.

Apparently, there is a Jenkins plug in for this:
https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Plugin

Here's some guidance you may have already seen:
http://fourkitchens.com/blog/article/trigger-jenkins-builds-pushing-gi

thub

I usually set up things to trigger a build on any change to the
develop branch.

Hope this helps,

--
Mark Wallace
PRINCIPAL ENGINEER, SEMANTIC APPLICATIONS MODUS OPERANDI, INC.

-Original Message-
From: Amila Wijayarathna [mailto:amwijayarat...@gmail.com]
Sent: Wednesday, March 23, 2016 10:51 AM
To: infrastructure-...@apache.org
Cc: dev@rya.incubator.apache.org; Adina Crainiceanu
<adina...@gmail.com>
Subject: Integrate jenkins to Apache-rya incuabator.

Hi all,
We are planning to integrate jenkins to Apache-rya incuabator. Can
some one please guide me on what is the procedure to follow when
doing

this?

Thank you!
--

*Amila Wijayarathna*
Undergraduate,
Faculty of Information Technology,
University of Moratuwa,
Sri Lanka.



--

*Amila Wijayarathna*
Undergraduate,
Faculty of Information Technology,
University of Moratuwa,
Sri Lanka.



--

*Amila Wijayarathna*
Undergraduate,
Faculty of Information Technology,
University of Moratuwa,
Sri Lanka.

Re: Test 'testMilliSecondsNoZone' Fails when Building from Source

[Josh Elser]

Amila -- Please make sure you subscribe to the mailing list so that you 
receive all correspondences.


Send a message to dev-subscr...@rya.incubator.apache.org and follow the 
instructions you receive in the reply.


Thanks.

Amila Wijayarathna wrote:

Hi all,

I am trying to build Apache Rya source available at [1]. I could
successfully built the source by running without tests using "mvn clean
install -Dmaven.test.skip=true". But when I am running the source with
tests using "mvn clean install", I am getting test failure at [2].

It seems like in the test 'testMilliSecondsNoZone', it pass
'2002-02-02T02:02:02.222' to serializeAndDeserialize method, but it returns
'2002-02-01T02:02:02.222' after deserialising and it causes the test to
fail.

Is this a know issue or am I getting this due to some incompatibility in my
environment?

Any idea on this is thoroughly appreciated.

[1]. https://github.com/apache/incubator-rya
[2].
testMilliSecondsNoZone(mvm.rya.api.resolver.impl.DateTimeRyaTypeResolverTest)
  Time elapsed: 0.051 sec<<<  FAILURE!
java.lang.AssertionError: Before='2002-02-02T02:02:02.222'; Expected should
match actual regex after='2002-02-02T\d\d:\d\d:02\.222Z'
deserialized:2002-02-01T20:02:02.222Z
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
mvm.rya.api.resolver.impl.DateTimeRyaTypeResolverTest.testMilliSecondsNoZone(DateTimeRyaTypeResolverTest.java:116)

Thank You!

*Amila Wijayarathna,*
undergraduate,
Faculty of Information Technology,
University of Moratuwa,
Sri Lanka.

Re: continuous integration for Rya as GSOC project?

[Josh Elser]

No worries! Advertising for interest is still good at this point. 
Refining tasks to be an appropriate length seems prudent now.


WRT infra, it depends a lot on what you (collective "you" as the 
project) want to see tested and how you as developers get the test 
results. For example:


* Do devs deploy on their own machines (local, ec2) or use some 
packaging (Vagrant, Docker, RPMs/DEBs+scripting)
* What defines "correctness" for Rya? What about "performance"? How do 
you measure them?
* How far do unit tests get you? Integration tests? What, if any, new 
tests does Rya need?


At a high level, that's what is always on my mind. I don't have enough 
context to say what I think Rya should have, but that's at least my 
thought process :)


Adina Crainiceanu wrote:

Josh, I completely agree with all your comments, and thank you for taking
the time to provide input.
Would it be possible for you to elaborate on what needs to be implemented
to have the reliable testing infrastructure you mentioned?
I realize that I should have had a better plan before proposing the
continuous integration project for GSoC, but now it is out there and a
student is interested in it. I hope that you and other people on this list
can help with fleshing out a plan for implementing the testing
infrastructure, so the project is fit for GSoC. I am very happy to
supervise the student if the project/student get selected for GSoC.

Thank you very much,
Adina

On Sat, Feb 20, 2016 at 3:00 PM, Josh Elser<josh.el...@gmail.com>  wrote:


Well to avoid my original reaction being taken out of my intended context,
an umbrella testing/integration gsoc project would be cool. I just meant
that making Jenkins run sounds like a one week effort at best.

Getting some reliable testing infrastructure, especially with all the
databases that Rya supports would be super cool.
On Feb 19, 2016 8:56 AM, "Adina Crainiceanu"<ad...@usna.edu>  wrote:


I was looking at
http://en.flossmanuals.net/GSoCMentoring/defining-a-project/ for project
ideas and infrastructure/automation was one of the ideas, but I agree

that

it is not the typical project and might not be the right scope/flavor.
Should I remove the gsoc2016 label so it does not show up in the list?

I also listed the search over multiple Rya instances as one of the
projects. I think a simple version can be implemented by a good student

in

3 month, and that is more inline with the other projects.

On Fri, Feb 19, 2016 at 11:44 AM, Josh Elser<josh.el...@gmail.com>

wrote:

re Jenkins server, yes. https://builds.apache.org

Assuming it hasn't changed since I was involved, GSoC should be a
programming task that a student could accomplish in ~3months with a

strong

weekly effort (I'm not sure if it's quantified in hrs/week).

Some examples from 2015:




https://www.google-melange.com/gsoc/project/details/google/gsoc2015/shuxiong/5796788510392320




https://www.google-melange.com/gsoc/project/details/google/gsoc2015/radu_manole/5668600916475904




https://www.google-melange.com/gsoc/project/details/google/gsoc2015/adperezmorales3/5717271485874176

I was pulling these from
https://www.google-melange.com/gsoc/projects/list/google/gsoc2015


Puja Valiyil wrote:


I don't think setting up some Jenkins jobs would be difficult.

There's

a

nice GUI for Jenkins that guides you through it and since we cleaned

up

the

poms recently it should be straight forward.
Does apache have a Jenkins server we could use?

Sent from my iPhone

On Feb 18, 2016, at 2:23 PM, Adina Crainiceanu<ad...@usna.edu>

wrote:

Hi all,

I though that one of the proposed projects for Rya at GSoC could be

to

have
a student working on setting up continuous integration / automatic

builds

for Rya. Those with more experience in something like that, can you
please
comment on what would be needed for such a project?

Thanks,
Adina

--
Dr. Adina Crainiceanu
http://www.usna.edu/Users/cs/adina/



--
Dr. Adina Crainiceanu
http://www.usna.edu/Users/cs/adina/

Re: Another question about assigning bugs in jira

[Josh Elser]

Ok, people might just need to be moved around? I'm not 100% sure. I'll 
try to take a look.


Adina Crainiceanu wrote:

Yes, I filed a ticket https://issues.apache.org/jira/browse/INFRA-11281 and
we have "Hadoop permissions", which I thought should solve these issues

On Mon, Feb 29, 2016 at 12:33 PM, Josh Elser<josh.el...@gmail.com>  wrote:


Adina -- did you ever file an INFRA ticket about changing the workflow? I
seem to remember something about this (but I could just be making it up).


Aaron D. Mihalik wrote:


Interesting... "Administrators" are not assignable users.  "Commiters"
are,
though.  Would it be bad if I added "administrators" as "commiters"?

I'm going to assume it's not bad, and we can undo it later.

More importantly, did something change?

On Mon, Feb 29, 2016 at 11:53 AM Puja Valiyil<puja...@gmail.com>   wrote:

Hey everyone,

I can't assign bugs to myself anymore (or anyone for that matter).  I
wanted to pick up RYA-34 (the issue with inference on Mongo). Can someone
assign it to me and then I can mark it as in progress?
Thanks,
Puja

Re: Another question about assigning bugs in jira

[Josh Elser]

Adina -- did you ever file an INFRA ticket about changing the workflow? 
I seem to remember something about this (but I could just be making it up).


Aaron D. Mihalik wrote:

Interesting... "Administrators" are not assignable users.  "Commiters" are,
though.  Would it be bad if I added "administrators" as "commiters"?

I'm going to assume it's not bad, and we can undo it later.

More importantly, did something change?

On Mon, Feb 29, 2016 at 11:53 AM Puja Valiyil  wrote:


Hey everyone,
I can't assign bugs to myself anymore (or anyone for that matter).  I
wanted to pick up RYA-34 (the issue with inference on Mongo). Can someone
assign it to me and then I can mark it as in progress?
Thanks,
Puja

Re: continuous integration for Rya as GSOC project?

[Josh Elser]

re Jenkins server, yes. https://builds.apache.org

Assuming it hasn't changed since I was involved, GSoC should be a 
programming task that a student could accomplish in ~3months with a 
strong weekly effort (I'm not sure if it's quantified in hrs/week).


Some examples from 2015:

https://www.google-melange.com/gsoc/project/details/google/gsoc2015/shuxiong/5796788510392320

https://www.google-melange.com/gsoc/project/details/google/gsoc2015/radu_manole/5668600916475904

https://www.google-melange.com/gsoc/project/details/google/gsoc2015/adperezmorales3/5717271485874176

I was pulling these from 
https://www.google-melange.com/gsoc/projects/list/google/gsoc2015


Puja Valiyil wrote:

I don't think setting up some Jenkins jobs would be difficult.  There's a nice 
GUI for Jenkins that guides you through it and since we cleaned up the poms 
recently it should be straight forward.
Does apache have a Jenkins server we could use?

Sent from my iPhone


On Feb 18, 2016, at 2:23 PM, Adina Crainiceanu  wrote:

Hi all,

I though that one of the proposed projects for Rya at GSoC could be to have
a student working on setting up continuous integration / automatic builds
for Rya. Those with more experience in something like that, can you please
comment on what would be needed for such a project?

Thanks,
Adina

--
Dr. Adina Crainiceanu
http://www.usna.edu/Users/cs/adina/

Re: question - notifications list

[Josh Elser]

Yes, I think you had to ask INFRA for that.

https://issues.apache.org/jira/plugins/servlet/project-config/RYA/notifications

There is a Rya Notification Scheme, but I don't have karma to change it, 
and I don't know of any other interface to modify it.


You can always ask in https://s.apache.org/infrachat before filing an 
issue on their JIRA project if you prefer.


Adina Crainiceanu wrote:

Hi,

Does anyone know what to do in order to have the automatic notifications go
to notifications@r.i.a.o instead of dev@ ? I suspect that I should file an
INFRA ticket to request that, but I wanted to make sure that is the right
step before doing it. An answer from the mentors would be welcome.

Thank you,
Adina