[VOTE] Accept Olingo proposal as an incubating project
Hi all, I'd like to call a VOTE for acceptance of Olingo into the Apache incubator. The proposal is pasted at the bottom on this email. The corresponding wiki page is: http://wiki.apache.org/incubator/OlingoProposal [ ] +1 Accept Olingo into the Apache incubator [ ] +0 Don't care. [ ] -1 Don't accept Olingo into the incubator because... +1 from me (binding) I'll close the VOTE next Sunday. Thanks, Florian = Apache Olingo Proposal = === Abstract === Apache Olingo is a generic Java language implementation of the OData 2.0 specification which will serve as a code base for the upcoming OASIS OData specification. === Proposal === The Open Data Protocol (OData) [1] is a Web protocol for querying and updating data that provides a way to unlock your data and free it from silos that exist in applications today. OData does this by applying and building upon Web technologies such as HTTP, Atom Publishing Protocol (AtomPub) and JSON to provide access to information from a variety of applications, services, and stores. The Apache Olingo is a library which enables developers to implement OData producers and OData consumers. Basic principles of the library are to provide an OData 2.0 specification compliant OData Library, enhancements shall be possible in a compatible manner, have a clear separation between Core and API, to provide an option to build extensions on top. This library should be base for implementing future releases of the specification. === Background === OData was originally developed by Microsoft and is released in a version 2.0 under an Open Specification Promise [2]. A lot of companies did show interests in this protocol, used it in products and gave feedback back to Microsoft. This joined effort resulted in a new release OData 3.0 in 2012, this version became the basis for the OASIS technical committee [3] which is currently working on a new version of the specification. This OASIS standard release is expected this year. The initial Java code of this project was developed by a development team that had already experience with other OData 2.0 and 3.0 implementations at SAP AG. The current code base implements OData 2.0 and because of this version is widely used it is a good starting point to build an open source community for the OData standard. The current code also comes up with an implementation of an OData sample service. On the one side this is an example for users which want to use the library to expose their own data and on the other side it illustrates how implemented features work. Additionally, the code base includes an extension which is called JPA processor. With this extension it is easy to expose any JPA persistence model via OData protocol without a lot of coding. === Rationale === More software vendors moving to OData means more choice for customers who will be able to use different implementations. For the standard to succeed, however, ensuring interoperability is paramount: in order to manage an ever growing context and leverage the enormous portability and interoperability issues that a globally adopted standard brings, it is necessary to think about how to make the related ecosystem healthy and sustainable. Successful modern standards are driven by: Clear documentation, built iteratively with continuous feedback from stakeholders A clearly defined compatibility process, enforced by tools that allow to gauge how implementations can be compatible and interoperable Accurate compliance criteria, documented in writing as well as in actual testing code that measure how tools and libraries are able to interoperate A sample implementation to clear up potential doubts and ensure that the standard can actually be implemented in real life scenarios The above mentioned pieces are able to make the development activity, towards an OData implementation, easier and more successful. Having an healthy ecosystem will ensure a smoother implementation process, more compliant products, and ultimately, a wider adoption of the standard. The OData ecosystem has been successful in creating and documenting early versions of the standard, yet it might potentially lack two very important aspects, that is a exhaustive implementation of the complete protocol that can be used productively and to ensure interoperability. As much as such artifacts can be developed independently by any OData proponent, the value of having a neutral party as a steward of actual code is to be considered. The Apache Software Foundation has been playing this kind of role for many years, and can provide the perfect environment to foster contributions on the OData theme with a great amount of expertise. === Initial Goals === Implement OData 2.0, make it final and mature Start implementation of OASIS OData draft specification Provide input and feedback for the draft specification to the OASIS OData TC based on implementation Implement OData add-ons
Re: [VOTE] Accept Olingo proposal as an incubating project
+1 binding Regards, Alan On Jul 1, 2013, at 3:38 AM, Florian Müller wrote: > Hi all, > > I'd like to call a VOTE for acceptance of Olingo into the Apache incubator. > > The proposal is pasted at the bottom on this email. > The corresponding wiki page is: > http://wiki.apache.org/incubator/OlingoProposal > > [ ] +1 Accept Olingo into the Apache incubator > [ ] +0 Don't care. > [ ] -1 Don't accept Olingo into the incubator because... > > +1 from me (binding) > > I'll close the VOTE next Sunday. > > > Thanks, > > Florian > > > > = Apache Olingo Proposal = > > === Abstract === > > Apache Olingo is a generic Java language implementation of the OData 2.0 > specification which will serve as a code base for the upcoming OASIS OData > specification. > > === Proposal === > > The Open Data Protocol (OData) [1] is a Web protocol for querying and > updating data that provides a way to unlock your data and free it from silos > that exist in applications today. OData does this by applying and building > upon Web technologies such as HTTP, Atom Publishing Protocol (AtomPub) and > JSON to provide access to information from a variety of applications, > services, and stores. > > The Apache Olingo is a library which enables developers to implement OData > producers and OData consumers. Basic principles of the library are to provide > an OData 2.0 specification compliant OData Library, enhancements shall be > possible in a compatible manner, have a clear separation between Core and > API, to provide an option to build extensions on top. This library should be > base for implementing future releases of the specification. > > === Background === > > OData was originally developed by Microsoft and is released in a version 2.0 > under an Open Specification Promise [2]. A lot of companies did show > interests in this protocol, used it in products and gave feedback back to > Microsoft. This joined effort resulted in a new release OData 3.0 in 2012, > this version became the basis for the OASIS technical committee [3] which is > currently working on a new version of the specification. This OASIS standard > release is expected this year. > > The initial Java code of this project was developed by a development team > that had already experience with other OData 2.0 and 3.0 implementations at > SAP AG. The current code base implements OData 2.0 and because of this > version is widely used it is a good starting point to build an open source > community for the OData standard. > > The current code also comes up with an implementation of an OData sample > service. On the one side this is an example for users which want to use the > library to expose their own data and on the other side it illustrates how > implemented features work. > > Additionally, the code base includes an extension which is called JPA > processor. With this extension it is easy to expose any JPA persistence model > via OData protocol without a lot of coding. > > === Rationale === > > More software vendors moving to OData means more choice for customers who > will be able to use different implementations. For the standard to succeed, > however, ensuring interoperability is paramount: in order to manage an ever > growing context and leverage the enormous portability and interoperability > issues that a globally adopted standard brings, it is necessary to think > about how to make the related ecosystem healthy and sustainable. Successful > modern standards are driven by: > > Clear documentation, built iteratively with continuous feedback from > stakeholders > A clearly defined compatibility process, enforced by tools that allow to > gauge how implementations can be compatible and interoperable > Accurate compliance criteria, documented in writing as well as in actual > testing code that measure how tools and libraries are able to interoperate > A sample implementation to clear up potential doubts and ensure that the > standard can actually be implemented in real life scenarios > The above mentioned pieces are able to make the development activity, towards > an OData implementation, easier and more successful. Having an healthy > ecosystem will ensure a smoother implementation process, more compliant > products, and ultimately, a wider adoption of the standard. > > The OData ecosystem has been successful in creating and documenting early > versions of the standard, yet it might potentially lack two very important > aspects, that is a exhaustive implementation of the complete protocol that > can be used productively and to ensure interoperability. As much as such > artifacts can be developed independently by any OData proponent, the value of > having a neutral party as a steward of actual code is to be considered. The > Apache Software Foundation has been playing this kind of role for many years, > and can provide the perfect environment to foster contributions on the OData > theme with a great amo
Re: [VOTE] Accept Olingo proposal as an incubating project
+1 (binding) Regards JB On 07/01/2013 03:49 PM, Alan Cabrera wrote: +1 binding Regards, Alan On Jul 1, 2013, at 3:38 AM, Florian Müller wrote: Hi all, I'd like to call a VOTE for acceptance of Olingo into the Apache incubator. The proposal is pasted at the bottom on this email. The corresponding wiki page is: http://wiki.apache.org/incubator/OlingoProposal [ ] +1 Accept Olingo into the Apache incubator [ ] +0 Don't care. [ ] -1 Don't accept Olingo into the incubator because... +1 from me (binding) I'll close the VOTE next Sunday. Thanks, Florian = Apache Olingo Proposal = === Abstract === Apache Olingo is a generic Java language implementation of the OData 2.0 specification which will serve as a code base for the upcoming OASIS OData specification. === Proposal === The Open Data Protocol (OData) [1] is a Web protocol for querying and updating data that provides a way to unlock your data and free it from silos that exist in applications today. OData does this by applying and building upon Web technologies such as HTTP, Atom Publishing Protocol (AtomPub) and JSON to provide access to information from a variety of applications, services, and stores. The Apache Olingo is a library which enables developers to implement OData producers and OData consumers. Basic principles of the library are to provide an OData 2.0 specification compliant OData Library, enhancements shall be possible in a compatible manner, have a clear separation between Core and API, to provide an option to build extensions on top. This library should be base for implementing future releases of the specification. === Background === OData was originally developed by Microsoft and is released in a version 2.0 under an Open Specification Promise [2]. A lot of companies did show interests in this protocol, used it in products and gave feedback back to Microsoft. This joined effort resulted in a new release OData 3.0 in 2012, this version became the basis for the OASIS technical committee [3] which is currently working on a new version of the specification. This OASIS standard release is expected this year. The initial Java code of this project was developed by a development team that had already experience with other OData 2.0 and 3.0 implementations at SAP AG. The current code base implements OData 2.0 and because of this version is widely used it is a good starting point to build an open source community for the OData standard. The current code also comes up with an implementation of an OData sample service. On the one side this is an example for users which want to use the library to expose their own data and on the other side it illustrates how implemented features work. Additionally, the code base includes an extension which is called JPA processor. With this extension it is easy to expose any JPA persistence model via OData protocol without a lot of coding. === Rationale === More software vendors moving to OData means more choice for customers who will be able to use different implementations. For the standard to succeed, however, ensuring interoperability is paramount: in order to manage an ever growing context and leverage the enormous portability and interoperability issues that a globally adopted standard brings, it is necessary to think about how to make the related ecosystem healthy and sustainable. Successful modern standards are driven by: Clear documentation, built iteratively with continuous feedback from stakeholders A clearly defined compatibility process, enforced by tools that allow to gauge how implementations can be compatible and interoperable Accurate compliance criteria, documented in writing as well as in actual testing code that measure how tools and libraries are able to interoperate A sample implementation to clear up potential doubts and ensure that the standard can actually be implemented in real life scenarios The above mentioned pieces are able to make the development activity, towards an OData implementation, easier and more successful. Having an healthy ecosystem will ensure a smoother implementation process, more compliant products, and ultimately, a wider adoption of the standard. The OData ecosystem has been successful in creating and documenting early versions of the standard, yet it might potentially lack two very important aspects, that is a exhaustive implementation of the complete protocol that can be used productively and to ensure interoperability. As much as such artifacts can be developed independently by any OData proponent, the value of having a neutral party as a steward of actual code is to be considered. The Apache Software Foundation has been playing this kind of role for many years, and can provide the perfect environment to foster contributions on the OData theme with a great amount of expertise. === Initial Goals === Implement OData 2.0, make it final and mature Start implementation of OASIS OData draft specif
Re: personal expectations for ombudsman role
On Sun, Jun 30, 2013 at 08:02:09AM -0700, Alan Cabrera wrote: > > On Jun 30, 2013, at 7:42 AM, Joe Schaefer wrote: > > > Now that things have settled down a bit, > > I'd like to talk about some of the things > > I'm looking for out of the ombudsman post. > > > > 1) proactively solicits opinions of exiting podlings > >about their experiences in the form of interviews > >and surveys. > > > > 2) make anonymized results of (1) available to the IPMC > >on a regular basis. > > > > 3) provides advocacy and facilitates solutions for > >committers who report issues with their podling's > >mentors. > > I might change 3 to state: > > provides advocacy and facilitates solutions for podling, and IPMC members, > who report issues that cannot normally be solved through normal established > processes. > > I thought it would be good to extend the help to anyone related to the > Incubator and be clear that the problems the ombudsman would work to resolve > would be extraordinary issues and that most, if not all, problems would be > solved through normal established processes. > +1 to Alan's clarification, but otherwise I like it Joe. > > That's pretty much it- what are your expectations > > for the ombudsman role? > > > Nice and simple. I like it. > > > Regards, > Alan > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: personal expectations for ombudsman role
+1 On Jul 1, 2013, at 11:27 AM, Chip Childers wrote: > On Sun, Jun 30, 2013 at 08:02:09AM -0700, Alan Cabrera wrote: >> >> On Jun 30, 2013, at 7:42 AM, Joe Schaefer wrote: >> >>> Now that things have settled down a bit, >>> I'd like to talk about some of the things >>> I'm looking for out of the ombudsman post. >>> >>> 1) proactively solicits opinions of exiting podlings >>> about their experiences in the form of interviews >>> and surveys. >>> >>> 2) make anonymized results of (1) available to the IPMC >>> on a regular basis. >>> >>> 3) provides advocacy and facilitates solutions for >>> committers who report issues with their podling's >>> mentors. >> >> I might change 3 to state: >> >> provides advocacy and facilitates solutions for podling, and IPMC members, >> who report issues that cannot normally be solved through normal established >> processes. >> >> I thought it would be good to extend the help to anyone related to the >> Incubator and be clear that the problems the ombudsman would work to resolve >> would be extraordinary issues and that most, if not all, problems would be >> solved through normal established processes. >> > > +1 to Alan's clarification, but otherwise I like it Joe. > >>> That's pretty much it- what are your expectations >>> for the ombudsman role? >> >> >> Nice and simple. I like it. >> >> >> Regards, >> Alan >> >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Provisionr version 0.4.0-incubating, RC0
+1 (binding). That said, here's a couple of nits I *really* would like you guys to address for the next release: On Thu, Jun 27, 2013 at 1:33 AM, Andrei Savu wrote: > Source and binary files: > http://people.apache.org/~asavu/provisionr-0.4.0-incubating-candidate-0/ > > The tag to be voted upon: > https://git-wip-us.apache.org/repos/asf?p=incubator-provisionr.git;a=tag;h=62abf302b47460abff904e2e721606255561757d The tag and the published tarballs differ in one file: .gitignore > Provisionr's KEYS file containing PGP keys we use to sign the release: > http://www.apache.org/dist/incubator/provisionr/KEYS It really would be quite nice if the key for release came with at least some level of WOT. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Provisionr version 0.4.0-incubating, RC0
On Mon, Jul 01, 2013 at 10:29:01AM -0700, Roman Shaposhnik wrote: > > Provisionr's KEYS file containing PGP keys we use to sign the release: > > http://www.apache.org/dist/incubator/provisionr/KEYS > > It really would be quite nice if the key for release came with at least > some level of WOT. As podlings get integrated into the ASF, wouldn't a reasonable approach to this request be for the mentors that have voted to add their sigs to the final release (after they +1 the vote)? Adding signatures is something TLP's do, so why not help podlings in a similar way? This, of course, assumes that the new signers are established within the ASF WOT. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Provisionr version 0.4.0-incubating, RC0
Thanks Roman! Good catch finding the missing .gitignore - I've create a JIRA issue: https://issues.apache.org/jira/browse/PROVISIONR-42 We can address the WOT thing next time we meet face to face. Cheers, -- Andrei Savu / axemblr.com On Mon, Jul 1, 2013 at 8:29 PM, Roman Shaposhnik wrote: > +1 (binding). > > That said, here's a couple of nits I *really* would like you guys > to address for the next release: > > On Thu, Jun 27, 2013 at 1:33 AM, Andrei Savu wrote: > > Source and binary files: > > http://people.apache.org/~asavu/provisionr-0.4.0-incubating-candidate-0/ > > > > The tag to be voted upon: > > > https://git-wip-us.apache.org/repos/asf?p=incubator-provisionr.git;a=tag;h=62abf302b47460abff904e2e721606255561757d > > The tag and the published tarballs differ in one file: .gitignore > > > Provisionr's KEYS file containing PGP keys we use to sign the release: > > http://www.apache.org/dist/incubator/provisionr/KEYS > > It really would be quite nice if the key for release came with at least > some level of WOT. > > Thanks, > Roman. >
Re: [VOTE] Release Apache Provisionr version 0.4.0-incubating, RC0
On Mon, Jul 1, 2013 at 10:42 AM, Chip Childers wrote: > As podlings get integrated into the ASF, wouldn't a reasonable approach > to this request be for the mentors that have voted to add their sigs to > the final release (after they +1 the vote)? Adding signatures is > something TLP's do, so why not help podlings in a similar way? This, of > course, assumes that the new signers are established within the ASF > WOT. +1 That's the approach that Daniel Shahaf suggested last year when this issue was discussed. http://mail-archives.apache.org/mod_mbox/incubator-general/201210.mbox/%3C20121011202956.GA4372%40lp-shahaf.local%3E Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSSION] Apache Olingo next steps
On Jun 28, 2013, at 7:42 AM, Alan Cabrera wrote: > > On Jun 28, 2013, at 6:43 AM, Florian Müller wrote: > >> Hi, >> >> About two weeks ago, Stephan presented the Apache Olingo (OData) proposal >> [1]. >> There has been a bit of a discussion about the name and the diversity of the >> initial committers. The name has been changed from OData to Olingo and one >> new initial committer from a different company has been added. We assume >> that the topic will attract a diverse community over time. >> >> Can anyone think of a reason not to move forward with a vote? > > While these are all good things to do, none of those issues needed to be > resolved before the vote. They just needed to be attended to before the > podling graduates. > > It should be ok to start the vote. As one of the two Mentors signed up for this project, I have one or two reasons to wait. The reasons are one or two additional Mentors! Regards, Dave > > > Regards, > Alan > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
