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

Reply via email to