Ideally one (or all) of you can become committers [1], which I think should be the goal. While for the time being this would involve the overhead of getting existing committers to sign off on PRs (which can be reviewed by others as well), this can actually be beneficial as it will be a forcing function for others to get to know the code better and, perhaps more importantly, make it possible to establish a history of the kind of support and community participation that leads to an easy case for committership.
While we all have our areas of interest, expertise, and ownership, it's good to not have any part of the project be in its own silo. Of course merging communities generally takes more time than merging code, but is worth striving for. Welcome to Apache Beam! [1] https://beam.apache.org/contribute/become-a-committer/ On Tue, Oct 16, 2018 at 12:56 AM Reuven Lax <re...@google.com> wrote: > > There isn't currently a concept of a partial committer - you are either a > committer or you aren't. Figuring out the best way forward here is a question > for the wider community. > > Reuven > > On Sun, Oct 14, 2018 at 2:41 AM David Morávek <david.mora...@gmail.com> wrote: >> >> 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 <re...@google.com> 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. >>> >>> Reuven >>> >>> On Wed, Oct 10, 2018 at 1:26 AM Plajt, Vaclav >>> <vaclav.pl...@firma.seznam.cz> 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 [1]. >>>> >>>> We are looking for reviewers within the community. Please start with >>>> documentation [2] or design document [3]. 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 [5] are passing with exception of "Website >>>> PreCommit". Which seems to be broken, little help here would be >>>> appreciated. >>>> >>>> Thank you >>>> We are looking forward for your feedback. >>>> {david.moravek,vaclav.plajt,marek.simunek}@firma.seznam.cz >>>> >>>> Resources: >>>> [1] Beam Summit London presentation: >>>> https://docs.google.com/presentation/d/1SagpmzJ-tUQki5VsQOEEEUyi_LXRJdG_3OBLdjBKoh4/edit?usp=sharing >>>> [2] Documentation: >>>> https://github.com/seznam/beam/blob/dsl-euphoria/website/src/documentation/sdks/euphoria.md >>>> [3] Design Document: https://s.apache.org/beam-euphoria >>>> [4] ASF Jira Issue: https://issues.apache.org/jira/browse/BEAM-3900 >>>> [5] Pull Request: https://github.com/apache/beam/pull/6601 >>>> [6] Original proposal: >>>> http://mail-archives.apache.org/mod_mbox/beam-dev/201712.mbox/%3ccajjqkhnrp1z8atteogmpfkqxrcjeanb3ykowvvtnwyrvv_-...@mail.gmail.com%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.
