olingo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bolz, Michael" <michael.b...@sap.com>
Subject Re: Hello from the JayData team - volunteering to contribute/continue odatav4-js
Date Fri, 11 Dec 2015 11:32:27 GMT
Hi all,

I agree that getting new contributors and contributions to Olingo is really great.
Especially for the JavaScript part which could not be developed and maintained as deserved.

For integration I agree with Christian and refer to the Apache Way (http://www.apache.org/foundation/getinvolved.html
<http://www.apache.org/foundation/getinvolved.html>).
Contributions are always welcome and those from JayStack are surely valuable for Olingo  ;o)

For integration I recommend the suggestion from using GitHub for their main development 
and contribute patches/features via JIRA issue with attached patches (http://olingo.apache.org/contribute.html
<http://olingo.apache.org/contribute.html>).
In the future we could probably create a separate branch in which all their contributions
are pushed (by an Olingo committer)
as we have done it in the past with e.g. Java “olingo-server-extension”.
However, I recommend to start with GitHub and JIRA.

And as conclusion I would like to say “Welcome” to our Olingo community  ;o)

Best Regards,
Michael

> On 10 Dec 2015, at 16:55, Amend, Christian <christian.amend@sap.com> wrote:
> 
> Hi Peter,
> 
> yes creating the GitHub clone was the right approach. This will give you the possibility
to make changes independent from any committers access rights. We followed the same approach
for the Google Summer of Code where a Student developed code over the summer. Since we could
not give him a "committer" status he made the changes in a GitHub repository and we committed
them.  
> Unfortunately the GitHub to Apache integration is a bit rusty. So we would still need
patch files to get the changes into the Apache main repository. As we saw with the GSoC the
best way to collect these patches is JIRA. 
> In my personal opinion I would love to use GitHub as a main repository as the contribution
mechanism via Pull requests is far easier than creating patch files. Here the Apache policies
come into play. The main repository must be within the Apache infrastructure for now. There
currently is another project which got permission to use GitHub as a main repository as a
POC but Olingo does not have this opportunity right now. I hope this changes in the future.

> 
> Best Regards,
> Christian
> 
> -----Original Message-----
> From: Peter Zentai [mailto:peter.zentai@jaystack.com] 
> Sent: Donnerstag, 10. Dezember 2015 15:38
> To: dev@olingo.apache.org
> Cc: Marc Schweigert <marcsc@microsoft.com>; Dénes Csiszár <denes.csiszar@jaystack.com>;
Robert Bonay <robert.bonay@jaystack.com>
> Subject: Re: Hello from the JayData team - volunteering to contribute/continue odatav4-js
> 
> Hi Christian and thanks Mark for the introduction
> 
> first and foremost thanks a lot for your welcoming lines Christian. We would be honored
if we could participate.
> 
> As a matter of fact we already started doing some things so as to at least have things
compiling/deploying. Time is now a great pressure on us (we need to be delivering something
substantial business value by Q1 - 2016, but we already have a ctp release date at 16th December).
   So for now, and really just as a means of getting some results, we made a fork from olingo-odata4-js
on Github and fixed the most pressing issues with NPM v3. (We created a PR in the Github.com
copy of the project, clear just to indicate our intentions. we understand that that PR would
never be accepted) We are to deploy an interim npmjs package from this fork.
> 
> As next step we make ourselves super prepped in the Apache Foundation way of things (thanks
for the starting point) and start collecting issues in JIRA. In the mean time - just this
year - we will maintain our Github fork, strictly stating everywhere that this fork should
not be used other then to test JayData 1.5 From January we would drop our fork and would contribute
to the main on the way we are supposed to. Do you think there are plans from Apache side to
integrate using pull requests  vs diffs attached to tickets?
> 
> I am interested in your thoughts, is this approach acceptable?
> 
> best regards
> Peter
> 
> 
> 
> Sent from Windows Mail
> 
> From: Amend, Christian<mailto:christian.amend@sap.com>
> Sent: ?Thursday?, ?December? ?10?, ?2015 ?1?:?52? ?PM
> To: dev@olingo.apache.org<mailto:dev@olingo.apache.org>
> Cc: Marc Schweigert<mailto:marcsc@microsoft.com>
> 
> Hi Peter,
> 
> awesome to hear that you are also driving forward the OData V4.0 development. We have
a similar resource situation and therefore focused on the development of the
> OData V4.0 Java server Library. Olingo data.js was so far a contribution from Microsoft
and you are right that, based on the resource situation, there were less development
> activities on the V4.0 JavaScript client side. We are looking forward to contributions
for the Olingo odata.js client from your side.
> 
> We are living the Apache Open Source way as described here  http://www.apache.org/foundation/getinvolved.html.
Everybody can contribute to the Olingo project and we are committing
> the code changes. Actually we are reworking our contribution guide and creating a separate
one for Java Script. As first step we recommend that you clone project, create JIRA issues
for bugs you find
> and attach according patches to the issue. Which we can validate and commit.
> 
> This is also the first time since Incubation that a larger group of people approach the
Olingo community with an explicit interest to commit to Olingo. Previously we received the
contributions first and then decided to give someone committing rights to the repository.
This would ensure that committers understand the code and have a longer interest in the project.
Since you now come and state that interest upfront we have no precedent within the Olingo
community on how to handle this. I would suggest that we handle this in the most open way
as possible on the mailing list. So I hope you can bear and discuss with us when we are figuring
out on how to best introduce and include you into the community.
> 
> Are there concrete plans, when you want to start with the development?
> 
> Best Regards,
> Christian
> 
> -----Original Message-----
> From: Peter Zentai [mailto:peter.zentai@jaystack.com]
> Sent: Mittwoch, 9. Dezember 2015 12:27
> To: dev@olingo.apache.org
> Cc: Marc Schweigert <marcsc@microsoft.com>
> Subject: Hello from the JayData team - volunteering to contribute/continue odatav4-js
> 
> Hello Olingo Dev Team,
> 
> I am writing on behalf of the JayData team at jaystack.com. We have been heavily investing
in OData in the past years - almost exclusively on the JavaScript side. In the past we created
JayData - one of the notable JS tools for V1-V3 OData with is idiomatic approach.. Unfortunately
we could not catch up with V4 because of resources issues. These issues has been battled -
and we managed to pull in a sizable investment money (in the range of $2m) to help our dreams
come true. Which is providing a full suite of ODataV4 client and server tools for JavaScript.
> 
> For this purpose we would like to continue using olingo-odata-js, as a protocol level
driver - as we did it in the past. Unfortunately this piece, the odata-v4-js library seems
kind of abandoned. No changes for more then a half year and the npm package is definitely
broken on npm 3.x.  (especially the RAT package is not working - which is a particularly unfortunate
thing, as RAT does not add to the olingo functionality just renders it broken). Also there
are a number of issues in the current implementation which we consider bugs.
> 
> Our humble question is: is there a way for us to actively contribute to odata-v4-js,
potentially maintaining this on a daily basis with a dedicated dev team of 2-3 developers?
How governance works? What should be our next steps?
> 
> Thanks for any help on this
> 
> yours sincerely
> 
> Peter Aron Zentai OBO the JayData team
> 
> 
> 
> Sent from Windows Mail
> 


Mime
View raw message