Re: Proposal: Watch: a transform for watching growth of sets

2017-07-19 Thread Eugene Kirpichov
Hi all, A PR for this is in review https://github.com/apache/beam/pull/3565 I'm very excited about this, because: - I think it turned out to be a very neat API and I'm looking forward to people coming up with more use cases for it - I was pleasantly surprised by being able to come up with a good

Re: [NEED HELP] how to revert a PR in branch DSL_SQL

2017-07-19 Thread Kai Jiang
Or another option is solve merge conflict. This might not be the best way. Because once master branch has some changes, we still need to do this same way. I tried merge locally. We could solve conflict files and open PR for that. conflict files are: both modified:

[NEED HELP] how to revert a PR in branch DSL_SQL

2017-07-19 Thread Mingmin Xu
Hi there, It seems branch DSL_SQL is broken after #3553 , as I cannot create a PR to master branch with error message '*Can’t automatically merge.*'. Googled and find two solutions: 1. submit a revert PR with Git

Re: How to test a transform against an inaccessible ValueProvider?

2017-07-19 Thread Kenneth Knowles
I think (3) sounds good for BEAM-2644. I think keep them both open since one is to develop the capability and the other is to use it. On Wed, Jul 19, 2017 at 12:32 PM, Ben Chambers wrote: > I also reported something similar to this as >

Re: How to test a transform against an inaccessible ValueProvider?

2017-07-19 Thread Ben Chambers
I also reported something similar to this as https://issues.apache.org/jira/browse/BEAM-2577. That issue was reported because we don't have any tests that use a runner and attempt to pass ValueProviders in. This means that we've found bugs such as NestedValueProviders used with non-serializable

How to test a transform against an inaccessible ValueProvider?

2017-07-19 Thread Eugene Kirpichov
Hi, Just filed JIRA https://issues.apache.org/jira/browse/BEAM-2644 Many transforms that take ValueProvider's have different codepaths for when the provider is accessible or not. However, as far as I can tell, there is no good way to construct a pipeline with PipelineOptions containing an

Re: [DISCUSS] Coder semantics

2017-07-19 Thread Lukasz Cwik
+1 to what Kenn said. Moving to a single encoding for all data types will alleviate many problems with cross language communication. For backwards compatibility, we still have the outer encoding/decoding on coders, no one is required to invoke them but may still choose to do so until they are

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

2017-07-19 Thread Kenneth Knowles
+1 to the RC Relating to Aviem's question, I think we need a release verification guide, at the least as a section of the Release Guide. But if we follow through on the prior thread of having a validation matrix with manual steps people sign up for, that is even better, and saves repeated work.

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

2017-07-19 Thread Jean-Baptiste Onofré
I don't understand as all jars are on the Nexus staging repository. The zip are also on staging repository. Regards JB On Jul 19, 2017, 18:47, at 18:47, Aviem Zur wrote: >@JB > >Hi, yes I saw that link, however those appear to be just the sources, >not >jars. >Do we have

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

2017-07-19 Thread Aviem Zur
@JB Hi, yes I saw that link, however those appear to be just the sources, not jars. Do we have built RC jars us to validate which are then deployed as is to dist (renamed to remove -RC and so forth) or do we each compile these manually and are assured that the sources in the dist are the actual

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

2017-07-19 Thread Ahmet Altay
Yes, +1 on RC2. On Wed, Jul 19, 2017 at 5:10 AM, Jean-Baptiste Onofré wrote: > Hi Aviem, > > as mentioned in the first e-mail: > > - Distributions are available here: > https://dist.apache.org/repos/dist/dev/beam/2.1.0/ > > - Artifacts are on the staging repository: >

Jenkins build is back to normal : beam_Release_NightlySnapshot #482

2017-07-19 Thread Apache Jenkins Server
See

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

2017-07-19 Thread Aviem Zur
Have the jars for RC2 been uploaded somewhere? On Wed, Jul 19, 2017 at 10:19 AM Jean-Baptiste Onofré wrote: > So, I guess you are voting +1 on RC2, correct (just for the tracking) ? > > Thanks, > Regards > JB > > On 07/19/2017 08:00 AM, Ahmet Altay wrote: > > Thank you JB. >

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

2017-07-19 Thread Jean-Baptiste Onofré
So, I guess you are voting +1 on RC2, correct (just for the tracking) ? Thanks, Regards JB On 07/19/2017 08:00 AM, Ahmet Altay wrote: Thank you JB. I validated python wordcount and mobile gaming examples on Linux. Found one issue (https://issues.apache.org/jira/browse/BEAM-2636). This does

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

2017-07-19 Thread Ahmet Altay
Thank you JB. I validated python wordcount and mobile gaming examples on Linux. Found one issue (https://issues.apache.org/jira/browse/BEAM-2636). This does not need to be a blocking issue for RC2, but if we end up having a RC3 we should consider fixing this issue. Ahmet On Tue, Jul 18, 2017 at