Re: Beam deploy uploads some artifacts twice

Moving to: BEAM-1717 to be handled as a ticket now. On Tue, Mar 14, 2017 at 4:11 PM Amit Sela wrote: > It seems like there is more than one duplicate issue here. > > First one is a double javadoc, which fails in fn-api

Re: [VOTE] Release 0.6.0, release candidate #2

+1 (binding) Contingent on adding NOTICE and LICENSE files into "apache-beam-0.6.0-python.zip", just as they are present in the "apache-beam-0.6.0-source-release.zip". On Tue, Mar 14, 2017 at 10:02 AM, Aljoscha Krettek wrote: > +1 (binding) > > - verified release signature

Re: [VOTE] Release 0.6.0, release candidate #2

Thank you for the comments. Added the LICENSE and NOTICE files to the python ZIP file (also updates, hashes and signature.) Will add this to the release guide as well. If everyone is comfortable with this change I will proceed. Thank you, Ahmet On Tue, Mar 14, 2017 at 10:38 AM, Davor Bonaci

[RESULT] [VOTE] Release 0.6.0, release candidate #2

I'm happy to announce that we have unanimously approved this release. There are 7 approving votes, 4 of which are binding: * Aljoscha Krettek * Davor Bonaci * Ismaël Mejía * Jean-Baptiste Onofré * Robert Bradshaw * Ted Yu * Tibor Kiss There are no disapproving votes. Thanks everyone! Ahmet

Default shading configuration and opting out

Hi all, https://github.com/apache/beam/pull/2096 introduced a common shading configuration for all of the modules in the project. The reason for this is that modules which are dependent on Guava may leak this dependency to the user and this could conflict with the version of Guava they require.

Re: Splittable DoFn for Python SDK

+1, I think this is a natural extension of the SDF to Python. On Tue, Mar 14, 2017 at 1:19 PM, Chamikara Jayalath wrote: > Thanks Eugene. Will keep you cc'd. > > - Cham > > On Tue, Mar 14, 2017 at 1:15 PM Eugene Kirpichov > wrote: > >> Thanks Cham!

Re: Splittable DoFn for Python SDK

Thanks Eugene. Will keep you cc'd. - Cham On Tue, Mar 14, 2017 at 1:15 PM Eugene Kirpichov wrote: > Thanks Cham! Agreed that this is a clean way to add SDF API to Python. > And agreed that it's a good idea to follow as similar path to Java - > direct runner first. The

Re: Style: how much testing for transform builder classes?

Thanks all. Looks like people are on board with the general direction though it remains to refine it to concrete guidelines to go into style guide. Ismaël, can you give more details about the situation you described in the first paragraph? Is it perhaps that really a RunnableOnService test was

Re: Default shading configuration and opting out

Thanks for working on this. Working in IO, I see us having to continually catch and fix missing guava shading, so it seems deserved. S On Tue, Mar 14, 2017 at 2:13 PM Aviem Zur wrote: > Hi all, > > https://github.com/apache/beam/pull/2096 introduced a common shading >

Re: Splittable DoFn for Python SDK

Thanks for the comments. I think we have enough agreement here to move detailed discussions to JIRA and PRs. I'll update this thread about the progress. I'll be happy to address any further comments/concerns in this thread or in the design doc as well. Thanks, Cham On Tue, Mar 14, 2017 at 1:21

Re: Call for help: let's add Splittable DoFn to Spark, Flink and Apex runners

Hi Eugene, This would work for me also. Please let me know if you want to keep the Apex related discussion separate or want me to join this call. Thanks, Thomas On Tue, Mar 14, 2017 at 1:56 PM, Eugene Kirpichov < kirpic...@google.com.invalid> wrote: > Sure, Friday morning sounds good. How

Re: Docker image dependencies

Hi Stephen, 1. About the docker repositories, we now have official Docker repo at Apache. So, for the Apache projects, I would recommend the Apache official repo. Anyway, generally speaking, I would recommend the official repo (from the projects). 2. To avoid "unpredictable" breaking change,

Re: Call for help: let's add Splittable DoFn to Spark, Flink and Apex runners

Hi! Please feel free to join this call, but I think we'd be mostly discussing how to do it in the Spark runner in particular; so we'll probably need another call for Apex anyway. On Tue, Mar 14, 2017 at 6:54 PM Thomas Weise wrote: > Hi Eugene, > > This would work for me also.

Docker image dependencies

hi! as part of doing the work to enable IO ITs, we decided we want to use docker. As part of that, we need to run docker images and they'll probably be pulled from a docker repository. Questions: * What docker repositories (and users on docker hub) do we as a group allow for images we'll run for

Re: Style: how much testing for transform builder classes?

Yes, what I meant is: Necessary tests are ones that blocks users if not present. Trivial or non-trivial shouldn't be the issue in such cases. Some of the boilerplate code and tests is because IO PTransforms are returned to the user before they are fully constructed and actual validation happens

Jenkins build became unstable: beam_SeedJob #165

See

Jenkins build is back to stable : beam_SeedJob #166

See

Re: Jenkins build became unstable: beam_SeedJob #165

Manual build, ignore. On Tue, Mar 14, 2017 at 10:37 PM, Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See > > -- --- Jason Kuster Apache Beam / Google Cloud Dataflow

Re: Beam deploy uploads some artifacts twice

It seems like there is more than one duplicate issue here. First one is a double javadoc, which fails in fn-api because the "beam-parent.xml" contained a maven-javadoc-plugin execution id called "javadoc" while apache parent uses "attach-javadocs" - keeping the same name as apache-parent seemed

Re: Style: how much testing for transform builder classes?

​+0.5 I used to think that some of those tests were not worth, for example testBuildRead and testBuildReadAlt. However the reality is that these tests allowed me to find bugs both during the development of HBaseIO and just yesterday when I tried to test the write support for the emulator with

Jenkins build became unstable: beam_Release_NightlySnapshot #356

See

Re: [VOTE] Release 0.6.0, release candidate #2

+1 (binding) - verified release signature and hashes - mvn install -Prelease runs smoothly - created a Quickstart against the staging repo - ran Quickstart with Flink local mode - ran Quickstart against a Flink 1.2 cluster On Tue, Mar 14, 2017, at 01:44, Eugene Kirpichov wrote: > Conclusion