Hi,
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?
Alexandre
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 risk 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 I
also heard that Apache is working on a tighter integration with the GitHub
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.
WDYT?
-----Original Message-----
From: Ramesh Reddy [mailto:rare...@redhat.com]
Sent: Mittwoch, 21. September 2016 16:47
To: dev@olingo.apache.org
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 these 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.
Ramesh..
----- Original Message -----
On 21/09/2016 16:32, Ramesh Reddy wrote:
Yes, I have added the github organization and starter repo for this long
time ago here https://github.com/olingo-extensions
let me know who is leading the effort with your Github userid, I will give
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
(https://issues.apache.org/jira/browse/OLINGO-1010)
we got a big contribution for the V4 Olingo code line. I personally think
this is great and we should integrate this into the Olingo project. The
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
process.
Also a lot of feedback was centered around extending the JPA processor
and requiring callbacks to adjust the SQL statements before they are
send
to the database. I am not really familiar with JPA and I did not dive
into the details of the contribution to see if these points are already
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 everyone
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.
Regards.
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
