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
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:
https://reference.apache.org/pmc/github 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!
From: mibo [mailto:m...@apache.org]
Sent: Samstag, 24. September 2016 06:56
To: Grande, Oliver <oliver.gra...@sap.com>; email@example.com
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.
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
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.
From: Ramesh Reddy [mailto:rare...@redhat.com]
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 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: firstname.lastname@example.org<mailto:email@example.com>
> > 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.