Thanks Kenn and Reuven!
This brings up the question, how should we proceed with the further development? Up until now, we did all changes in our own repository, which was very flexible as we could do code reviews and PR merges by ourselves.
We would love to take a full responsibility for the newly created modules, because we have put a great effort into their development over the years.
Would it be possible to gain commit rights for these modules, so we could maintain them without having to bother a committer with each patch or improvement?D.On Sun, Oct 14, 2018 at 10:48 AM Reuven Lax <relax@xxxxxxxxxx> wrote:This is a brand new extension, so I don't think it's necessary for a Beam committer to review every line of this before merging. A committer should ensure that files are in the correct places, IP clearance is done, etc., and then I think it's fine to merge.I do think this code needs to be reviewed in detail, but I think it's sufficient to trust the Euphoria authors to do this review themselves. If the code has already been peer reviewed between the Euphoria authors, I feel like Beam's review before submit policy has been satisfied.ReuvenOn Wed, Oct 10, 2018 at 1:26 AM Plajt, Vaclav <Vaclav.Plajt@xxxxxxxxxxxxxxx> wrote:Hello Beam devs,
we finished our main goals in development of Euphoria DSL. It is Easy to use Java 8 API build on top of the Beam's Java SDK. API provides a high-level abstraction of data transformations, with focus on the Java 8 language features (e.g. lambdas and streams). It is fully inter-operable with existing Beam SDK and convertible back and forth. It allows fast prototyping through use of (optional) Kryo based coders and can be seamlessly integrated into existing Beam Pipelines.
Now we believe that it is the time to start discussion about it with the community. Which will hopefully lead to vote about adapting it into Apache Beam project. Most of main ideas and development goals were presented in Beam Summit in London .
We are looking for reviewers within the community. Please start with documentation  or design document . Our contribution is divided to two modules: `org.apache.beam:beam-sdks-java-extensions-euphoria` and `org.apache.beam:beam-sdks-java-extensions-kryo`. Rest of the code base remains untouched.
All the checks in MR  are passing with exception of "Website PreCommit". Which seems to be broken, little help here would be appreciated.
We are looking forward for your feedback.
 Beam Summit London presentation: https://docs.google.com/presentation/d/1SagpmzJ-tUQki5VsQOEEEUyi_LXRJdG_3OBLdjBKoh4/edit?usp=sharing
 Documentation: https://github.com/seznam/beam/blob/dsl-euphoria/website/src/documentation/sdks/euphoria.md
 Design Document: https://s.apache.org/beam-euphoria
 ASF Jira Issue: https://issues.apache.org/jira/browse/BEAM-3900
 Pull Request: https://github.com/apache/beam/pull/6601
 Original proposal: http://mail-archives.apache.org/mod_mbox/beam-dev/201712.mbox/%3cCAJJqkHNRP1Z8AtTEogmpFkQxRcjeANb3yKOWvVtNwyrvv_-HoA@xxxxxxxxxxxxxx%3e
Je dobré vědět, že tento e-mail a přílohy jsou důvěrné. Pokud spolu jednáme o uzavření obchodu, vyhrazujeme si právo naše jednání kdykoli ukončit. Pro fanoušky právní mluvy - vylučujeme tím ustanovení občanského zákoníku o předsmluvní odpovědnosti. Pravidla o tom, kdo u nás a jak vystupuje za společnost a kdo může co a jak podepsat naleznete zde
You should know that this e-mail and its attachments are confidential. If we are negotiating on the conclusion of a transaction, we reserve the right to terminate the negotiations at any time. For fans of legalese—we hereby exclude the provisions of the Civil Code on pre-contractual liability. The rules about who and how may act for the company and what are the signing procedures can be found here.