Please correct me if I am wrong, but it seems like Apache GitHub integration is currently fairly lackluster. It does not seem to seamlessly integrate with a lot of GitHub main features. For example, it does not seem to integrate with GitHub issues, which is a big part of what makes a GitHub repository "lively". As it stands, you mostly end up with a shell of what a GitHub repository should be.

With that in mind, contributors would probably have to get familiar with the jira issues and the ASF repository overall. If you add that to the fact that contributors would also have to sign an ICLA, I think this would deter a lot of potential small contributors. Also, it could be confusing to have an Alpha under Olingo that is not officially supported or that might be dropped at any time.

Personally, I think either :

- Put it on the GitHub repo and wait for the project to reach an adequate maturity. (Maybe have some kind of link or encouragement from the main Olingo site)


- Put it on the ASF repo in Alpha but officially support it


On 2016-10-14 9:24 AM, Ramesh Reddy wrote:
GitHub repo is created to capture the early enthusiasm of community 
contributors without much restrictions of ICLA and ASF and also to gauge the 
interest of the participant to drive the feature to the somewhat of a mature 
state. If Olingo starts adapting all the extensions which are not directly 
involved with implementing the OData specification, it is just going to spread 
the current limited resources too thin and quality of our offering will surely 
to take hit. When PMC thinks that module has reached sufficient maturity and/or 
sustained interest, PMC to vote on bringing it under ASF repos and making the 
individuals part of the committers.

Also even though we think Olingo has been established as umbrella project, our 
builds except of V2 vs V4 have not been set up to bring these kind of 
extensions in a non dependent fashion. This separate build/release process and 
code repositories absolutely must be there. If we are willing to take these 
steps, you will have my vote for it.


----- Original Message -----
On 14/10/2016 10:35, Amend, Christian wrote:
Hi all,

I would like to reanimate this discussion. I have been trying to find
information about having an Repository which is not under Apache control
as part of an Apache project but I could not find any useful information
about this.
In my personal opinion we should not use the GitHub repository because as
an Apache project we should rely on Apache infrastructure. This allows all
Olingo PMC members to have committing rights and prevents a single person
from having to provide/own the GitHub repository.
Also I would see this as a good way to attract users/contributers to Olingo
which we might miss if the connection between the GitHub repository and
the Apache Olingo project isn`t clear.
Also in my opinion we would not lose anything by providing an Alpha version
via Olingo. If there is no feedback or contributions coming we can still
decide not to take this forward. This would also mean that the current
Olingo PMC members do not have to provide support for the Alpha version.

Here is a link on the Apache to GitHub features: for those interested. These
features could be useful to integrate the GitHub mirror more.

Please consider the points above and let me know what you think!
I have already expressed my preference below: a GIT repository, hosted
at the ASF infrastructure, with full-fledged GitHub integration.
We will not loose anything about attracting extra-ASF contribution, but
as PMC we will retain control over the repository itself.

Obviously, this will require contributors to sign an ICLA, but I urge to
remind that this is the one of the pillars of how The ASF works.

If this is seen as too onerous and discouraging new contributors, then
simply The ASF is not the right place to be and the V4 JPA effort should
better find its home as one of the numerous github-homed open source
projects in the wild.
With no official relationship with the Apache Olingo PMC, naturally.


From: mibo []
Sent: Samstag, 24. September 2016 06:56
To: Grande, Oliver <>;
Subject: RE: [DISCUSS] V4 JPA contribution

IMHO I also think we should keep the barrier for further contributors (and
contributions) to the JPA extension low.

Hence using a GitHub repository as starting point could be a good decision.

This way contributing and building the first releases (alpha, beta,
whatever…) are completely independent from Apache (and any ICLA).

Afterward when the JPA extension project has contributors and a own
“community” it could be moved into a official Apache Git and under the
OData umbrella aka. Olingo  ;o)

And if all works well the time between start on GitHub and then move to
Olingo must not be long and could also include the direct promotion of
Oliver to a Olingo committer / PMC (if he wish  ;o)

tldr; Start with a low entry barrier on GitHub and end (after some time)
with a JPA extension in Olingo (on Apache)

Best Regards, Michael

Am 23. September 2016 um 16:04:16, Grande, Oliver
(<>) schrieb:

as I'm new to Apache and Open Source I have the feeling that I can't help
finding the right way is to handle my contribution.

My idea was to contribute to the JPA processor after an initial
contribution, as I see it only as a starting point.


-----Original Message-----
From: Ramesh Reddy []
Sent: Freitag, 23. September 2016 15:18
Subject: Re: [DISCUSS] V4 JPA contribution

IMO, creating the JIRA and promoting the extensions available on main
Olingo website should not be an issue. Many projects do that such
promotions, it is good for both parties, shows the whole eco-system around
the main project.

Another note I would like to emphasize is, if Oliver Grande contributed
initial code, it is not necessary that he is the only one needs to take
responsibility to integrate or complete it. Anyone of you with similar
needs for JPA could continue the Oliver's work.


----- Original Message -----

Has anyone officially been in contact with Oliver Grande since his
contribution? I know he is active on the user list, but I think it would
be nice to have his opinion regarding all of this.

I personally think creating a github repo and giving access to Oliver
Grande is indeed a good idea. If the ASF repo is not used, I still think
it would be nice to keep some kind of link with the main Olingo project
to let users know that the "main Olingo team" encourages contribution to
this JPA processor. Currently there is "odata4-JPA" listed as a Olingo
component, which leads to a summary with the POC jira items. Just an
idea, but would it be possible to delete the POC jira items and maybe
have that "odata4-JPA" summary link to the JPA processor potential
github repo?


On 2016-09-21 11:09 AM, Amend, Christian wrote:
This is a valid point. If we put this code into an ASF repository the
Olingo project as a whole is somewhat responsible for this code. This
could be reduced by making the contributor Oliver Grande an Olingo
committer so he could keep working on the code. He also started answering
mails on the users list already so he seems committed. Of course adding
another committer would require a vote on the private mailing list and
requires the consent of the Olingo project.

We could also think about giving commit access to the separate Git
repository more freely to users that ask for it. This might also be an
incentive for more contributions. I think it is possible to give commit
access only to the new repository while leaving the core repo alone.
We could also ask for volunteers on the user mailing list while clearly
stating that we won`t accept this contribution to Olingo if there are not
enough users that promise to contribute. Having an Alpha release could
also help identify potential committers. And I don`t think that an Alpha
release would require maintenance from the current Olingo PMC/committers.

As for being cumbersome to work with the Apache repositories I agree. But
also heard that Apache is working on a tighter integration with the
mirror. I am not sure how far this has progressed. Do you know anything
about this?

I personally would object to another separate Apache project for a JPA
implementation. IMHO Olingo is the OData umbrella project at Apache.


-----Original Message-----
From: Ramesh Reddy []
Sent: Mittwoch, 21. September 2016 16:47
Subject: Re: [DISCUSS] V4 JPA contribution

IMO, at least there are two reasons for me
- Working with ASF repository is cumbersome than the Github. Meaning
working with external pull requests, code review features etc. I wish
Olingo repo was on GitHub, instead of using the mirror.
- second, most important is these are not part of ASF (yet), Olingo by
including these in their repository comes with certain amount of
responsibilities from committers, about their completeness, correctness,
documents and management. Unless these are reasonably proved by the
external community effort, Olingo committers are on hook to maintain
as if they were part of Olingo repo. So, my suggestion is wait until that
time, then we can take vote to include with Olingo repo. If you are
thinking outside of Olingo, then that need to be approached as new Apache
project, that probably is completely separate effort.


----- Original Message -----
On 21/09/2016 16:32, Ramesh Reddy wrote:
Yes, I have added the github organization and starter repo for this
time ago here

let me know who is leading the effort with your Github userid, I will
the commit rights to the repo.
Any specific reason to not use an ASF repository (mirrored and
integrated with GitHub as others, of course)?

----- Original Message -----
On 21/09/2016 16:03, Amend, Christian wrote:
Hi all,

With Olingo Issue 1010
we got a big contribution for the V4 Olingo code line. I personally
this is great and we should integrate this into the Olingo project.
main question I have how this could be done best.
  From the V2 JPA extension we learned that the inability to make JPA
releases independent from the core library hurts the development
Also a lot of feedback was centered around extending the JPA
and requiring callbacks to adjust the SQL statements before they are
to the database. I am not really familiar with JPA and I did not
into the details of the contribution to see if these points are
met. Any feedback here is welcome.

For first steps I would suggest:

- Delete the POC JPA Jira Items as they are not needed anymore

- Integrate the code into our repository in a branch so
can look at the code

- Decide on a repository

- Decide on a release strategy

- Perform an alpha release and collect feedback

WDYT? Do you have any ideas about how to set this up so we can make
independent releases? Should we ask for a separate git repository?
IMO, a separate GIT repository with independent release process seems
the simpler way to handle what you report above.

Just my 2c.
Francesco Chicchiriccò

Tirasa - Open Source Excellence

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail

This email has been checked for viruses by Avast antivirus software.

Reply via email to