Re: Dynamic timers now supported!

[Ismaël Mejía]

I had a discussion with Rehman last week and we discovered that the
TimersMap
related tests were not running for all runners because they were not tagged
as
part of the ValidatesRunner category. I opened a PR [1] to enable this, so
please someone help me with the review/merge.

I took a look just for curiosity and discovered that they are only passing
for
Direct runner and for the classic Flink runner in batch mode. They are not
passing for Dataflow [2][3] and for the Portable Flink runner, so probably
worth
to reopen the issue to investigate/fix.

[1] https://github.com/apache/beam/pull/10747
[2]
https://builds.apache.org/job/beam_PostCommit_Java_ValidatesRunner_Dataflow_PR/210/
[3]
https://builds.apache.org/job/beam_PostCommit_Java_ValidatesRunner_PortabilityApi_Dataflow_PR/76/


On Sat, Jan 25, 2020 at 1:26 AM Reuven Lax  wrote:

> Yes. For now we exclude the flink runner, but fixing this should be fairly
> trivial.
>
> On Fri, Jan 24, 2020 at 3:35 PM Maximilian Michels  wrote:
>
>> The Flink Runner was allowing to set a timer multiple times before we
>> made it comply with the Beam semantics of overwriting past invocations.
>> I wouldn't be surprised if the Spark Runner never addressed this. Flink
>> and Spark itself allow for a timer to be set to multiple times. In order
>> to fix this for Beam, the Flink Runner has to maintain a checkpointed
>> map which sits outside of its builtin TimerService.
>>
>> As far as I can see, multiple timer families are currently not supported
>> in the Flink Runner due to the map not taking the family name into
>> account. This can be easily fixed though.
>>
>> -Max
>>
>> On 24.01.20 21:31, Reuven Lax wrote:
>> > The new timer family is in the portability protos. I think
>> TimerReceiver
>> > needs to be updated to set it though (I think a 1-line change).
>> >
>> > The TimerInternals class that runners implement today already handles
>> > dynamic timers, so most of the work was in the Beam SDK  to provide an
>> > API that allows users to access this feature.
>> >
>> > The main work needed in the runner was to take in account the timer
>> > family. Beam semantics say that if a timer is set twice with the same
>> > id, then the second timer overwrites the first.  Several runners
>> > therefore had maps from timer id -> timer. However since the
>> > timer family scopes the timers, we now allow two timers with the same
>> id
>> > as long as the timer families are different. Runners had to be updated
>> > to include the timer family id in the map keys.
>> >
>> > Surprisingly, the new TimerMap tests seem to pass on Spark
>> > ValidatesRunner, even though the Spark runner wasn't updated! I wonder
>> > if this means that the Spark runner was incorrectly implementing the
>> > Beam semantics before, and setTimer was not overwriting timers with the
>> > same id?
>> >
>> > Reuven
>> >
>> > On Fri, Jan 24, 2020 at 7:31 AM Ismaël Mejía > > > wrote:
>> >
>> > This looks great, thanks for the contribution Rehman!
>> >
>> > I have some questions (note I have not looked at the code at all).
>> >
>> > - Is this working for both portable and non portable runners?
>> > - What do other runners need to implement to support this (e.g.
>> Spark)?
>> >
>> > Maybe worth to add this to the website Compatibility Matrix.
>> >
>> > Regards,
>> > Ismaël
>> >
>> >
>> > On Fri, Jan 24, 2020 at 8:42 AM Rehman Murad Ali
>> > > > > wrote:
>> >
>> > Thank you Reuven for the guidance throughout the development
>> > process. I am delighted to contribute my two cents to the Beam
>> > project.
>> >
>> > Looking forward to more active contributions.
>> >
>> > *
>> > *
>> >
>> > *Thanks & Regards*
>> >
>> >
>> >
>> > *Rehman Murad Ali*
>> > Software Engineer
>> > Mobile: +92 3452076766 <+92%20345%202076766>
>> 
>> > Skype: rehman.muradali
>> >
>> >
>> >
>> > On Thu, Jan 23, 2020 at 11:09 PM Reuven Lax > > > wrote:
>> >
>> > Thanks to a lot of hard work by Rehman, Beam now supports
>> > dynamic timers. As a reminder, this was discussed on the dev
>> > list some time back.
>> >
>> > As background, previously one had to statically declare all
>> > timers in your code. So if you wanted to have two timers,
>> > you needed to create two timer variables and two callbacks -
>> > one for each timer. A number of users kept hitting stumbling
>> > blocks where they needed a dynamic set of timers (often
>> > based on the element), which was not supported in Beam. The
>> > workarounds were quite ugly and complicated.
>> >
>> > The new support allows declaring a TimerMap, which is a map
>> > of timers. Each TimerMap is scoped by a family name, so you
>

Beam Dependency Check Report (2020-02-03)

[Apache Jenkins Server]

High Priority Dependency Updates Of Beam Python SDK:


  Dependency Name
  Current Version
  Latest Version
  Release Date Of the Current Used Version
  Release Date Of The Latest Release
  JIRA Issue
  
cachetools
3.1.1
4.0.0
2019-12-23
2019-12-23BEAM-9017
google-cloud-bigquery
1.17.1
1.23.1
2019-09-23
2019-12-23BEAM-5537
google-cloud-datastore
1.7.4
1.10.0
2019-05-27
2019-10-21BEAM-8443
httplib2
0.12.0
0.17.0
2018-12-10
2020-01-27BEAM-9018
mock
2.0.0
3.0.5
2019-05-20
2019-05-20BEAM-7369
oauth2client
3.0.0
4.1.3
2018-12-10
2018-12-10BEAM-6089
PyHamcrest
1.10.1
2.0.0
2020-01-20
2020-01-20BEAM-9155
pytest
4.6.9
5.3.5
2020-01-06
2020-02-03BEAM-8606
Sphinx
1.8.5
2.3.1
2019-05-20
2019-12-23BEAM-7370
tenacity
5.1.5
6.0.0
2019-11-11
2019-11-11BEAM-8607
High Priority Dependency Updates Of Beam Java SDK:


  Dependency Name
  Current Version
  Latest Version
  Release Date Of the Current Used Version
  Release Date Of The Latest Release
  JIRA Issue
  
com.alibaba:fastjson
1.2.49
1.2.62
2018-08-04
2019-10-07BEAM-8632
com.datastax.cassandra:cassandra-driver-core
3.8.0
4.0.0
2019-10-29
2019-03-18BEAM-8674
com.esotericsoftware:kryo
4.0.2
5.0.0-RC4
2018-03-20
2019-04-14BEAM-5809
com.esotericsoftware.kryo:kryo
2.21
2.24.0
2013-02-27
2014-05-04BEAM-5574
com.github.ben-manes.versions:com.github.ben-manes.versions.gradle.plugin
0.20.0
0.27.0
2019-02-11
2019-10-21BEAM-6645
com.github.luben:zstd-jni
1.3.8-3
1.4.4-7
2019-01-29
2020-01-24BEAM-9194
com.github.spotbugs:spotbugs
3.1.12
4.0.0-RC1
2019-03-01
2020-01-20BEAM-7792
com.github.spotbugs:spotbugs-annotations
3.1.12
4.0.0-RC1
2019-03-01
2020-01-20BEAM-6951
com.google.api.grpc:grpc-google-cloud-datacatalog-v1beta1
0.29.0-alpha
0.32.0
2019-10-25
2020-01-23BEAM-8853
com.google.api.grpc:grpc-google-common-protos
1.12.0
1.17.0
2018-06-29
2019-10-04BEAM-8633
com.google.api.grpc:proto-google-cloud-datacatalog-v1beta1
0.29.0-alpha
0.32.0
2019-10-25
2020-01-23BEAM-8854
com.google.api.grpc:proto-google-cloud-spanner-admin-database-v1
1.6.0
1.49.1
2019-01-23
2020-01-28BEAM-8682
com.google.api.grpc:proto-google-common-protos
1.12.0
1.17.0
2018-06-29
2019-10-04BEAM-6899
com.google.apis:google-api-services-bigquery
v2-rev20190917-1.30.3
v2-rev20191211-1.30.3
2019-10-09
2020-01-14BEAM-8684
com.google.apis:google-api-services-cloudresourcemanager
v1-rev20191206-1.30.3
v2-rev20191206-1.30.3
2019-12-17
2019-12-17BEAM-8751
com.google.apis:google-api-services-dataflow
v1b3-rev20190927-1.30.3
v1beta3-rev12-1.20.0
2019-10-11
2015-04-29BEAM-8752
com.google.apis:google-api-services-pubsub
v1-rev2019-1.30.3
v1-rev20191203-1.30.3
2019-11-26
2019-12-18BEAM-8753
com.google.cloud:google-cloud-spanner
1.6.0
1.49.1
2019-01-23
2020-01-28BEAM-8758
com.google.cloud.bigdataoss:gcsio
1.9.16
2.0.0
2019-02-25
2019-08-23BEAM-8689
com.google.cloud.bigdataoss:util
1.9.16
2.0.0
2019-02-25
2019-08-23BEAM-8759
com.google.cloud.bigtable:bigtable-client-core
1.8.0
1.13.0
2019-01-03
2020-01-21BEAM-8691
com.google.guava:guava
26.0-jre
28.2-jre
2018-08-01
2019-12-27BEAM-5559
com.google.guava:guava-testlib
25.1-jre
28.2-jre
2018-05-23
2019-12-27BEAM-8760
com.google.protobuf.nano:protobuf-javanano
3.0.0-alpha-5
3.2.0rc2
2016-01-06
2017-01-19BEAM-9098
com.hazelcast:hazelcast
3.12
4.0-BETA-2
2019-04-09
2019-12-17BEAM-8636
com.ning:compress-lzf
1.0.3
1.0.4
2014-08-16
2017-03-14BEAM-9100
com.pholser:junit-quickcheck-core
0.8
0.9.1
2018-03-08
2020-01-21BEAM-8699
io.netty:netty-handler
4.1.30.Final
  

[Go SDK] Apache Beam GroupByKey

[Anand Singh Kunwar]

Hi
I have been trying out the apache beam go SDK for running aggregation on
logs from kafka. I have been trying to write a kafka reader using ParDoFns
and aggregating the result using WindowInto and GroupByKey. However the
`GroupByKey`'s output only outputs result if I finish my kafka message
outputs. I am using the direct runner for testing these out. It seems like
a bug in the runner/GroupByKey implementation as it seems to assume that
the output is going to exhaust even in the case of windowed input.

Pipeline representation:
impulse -> kafka consumption ParDo(consumes kafka messages in a loop and
emits metric with beam.EventTime) -> add timestamp ParDo ->
WindowInto(fixed windows) -> Add window max Timestamp as key Pardo ->
*GroupByKey*

The *GroupByKey *gets stuck until first kafka consumption pardo exits. This
doesn't seem desired. I haven't been unable to pinpoint the exact line of
code why this gets stuck. Can someone help me out with this.

Thanks for your help.

Best
Anand Singh Kunwar

Re: New contributor to Beam documentation

[Chamikara Jayalath]

Welcome, Dave !!

On Fri, Jan 31, 2020, 3:23 PM Ahmet Altay  wrote:

> Welcome!
>
> On Fri, Jan 31, 2020 at 12:03 PM Kyle Weaver  wrote:
>
>> Hi Dave,
>>
>> Welcome to Beam! Looking forward to working with you :)
>>
>> Kyle
>>
>> On Fri, Jan 31, 2020 at 11:17 AM Dave Wrede  wrote:
>>
>>> Hi all,
>>>
>>> I'm Dave and I recently started working on Dataflow documentation. In
>>> addition, I will also be spending some of my time contributing to the Beam
>>> docs, when needed. I have a strong passion for great learning experiences
>>> and welcome feedback on how we can make Beam more approachable and useful
>>> for all audience types.
>>>
>>> Thanks and I look forward to working with you all!
>>>
>>> - Dave
>>>
>>>

Re: [Go SDK] Apache Beam GroupByKey

[Robert Burke]

The Go SDK doesn't currently have the ability to self split bundles. This
is being worked on as part of SplittableDoFns.

Unfortunately this means the only Source that works in streaming modes is
the Google PubSubIO source which only works on Dataflow, since that runner
replaces the  node with an internal implementation (same as Java and
Python).

With proper windowing, the Group By Key behaves as expected if once ParDos
can self checkpoint.

Another approach that will be worked on in the summer is supporting Cross
Language Transforms so that Go pipelines can re-use the Java IOs which
would also resolve this problem.

Thank you for understanding, as we work to get the Go SDK out of its
experimental state.



On Mon, Feb 3, 2020, 9:13 AM Anand Singh Kunwar 
wrote:

> Hi
> I have been trying out the apache beam go SDK for running aggregation on
> logs from kafka. I have been trying to write a kafka reader using ParDoFns
> and aggregating the result using WindowInto and GroupByKey. However the
> `GroupByKey`'s output only outputs result if I finish my kafka message
> outputs. I am using the direct runner for testing these out. It seems like
> a bug in the runner/GroupByKey implementation as it seems to assume that
> the output is going to exhaust even in the case of windowed input.
>
> Pipeline representation:
> impulse -> kafka consumption ParDo(consumes kafka messages in a loop and
> emits metric with beam.EventTime) -> add timestamp ParDo ->
> WindowInto(fixed windows) -> Add window max Timestamp as key Pardo ->
> *GroupByKey*
>
> The *GroupByKey *gets stuck until first kafka consumption pardo exits.
> This doesn't seem desired. I haven't been unable to pinpoint the exact line
> of code why this gets stuck. Can someone help me out with this.
>
> Thanks for your help.
>
> Best
> Anand Singh Kunwar
>

[RELEASE VOTE RESULT] Release 2.19.0, release candidate #1

[Boyuan Zhang]

I'm happy to announce that we have unanimously approved this release.

There are 5 approving votes, 4 of which are binging:
* Ahmet Altay
* Ismaël Mejía
* Jean-Baptiste Onofré
* Robert Bradshaw

There are no disapproving votes.

Thanks for everyone's help! I'm going to finalize the release and send out
the official release announcement later.

Re: [RELEASE VOTE RESULT] Release 2.19.0, release candidate #1

[Thomas Weise]

Impressive, probably the fastest/smoothest Beam release so far.

On Mon, Feb 3, 2020 at 10:45 AM Boyuan Zhang  wrote:

> I'm happy to announce that we have unanimously approved this release.
>
> There are 5 approving votes, 4 of which are binging:
> * Ahmet Altay
> * Ismaël Mejía
> * Jean-Baptiste Onofré
> * Robert Bradshaw
>
> There are no disapproving votes.
>
> Thanks for everyone's help! I'm going to finalize the release and send out
> the official release announcement later.
>

Re: [DISCUSSION] Improve release notes by adding a change list file

[Ahmet Altay]

On Sat, Feb 1, 2020 at 9:22 AM Chad Dombrova  wrote:

> In case it's of any use, there's a tool called towncrier[1] to help
> compile changelog fragments and compile them at time of delivery.
>

I would prefer not to have the complexity of multiple files and an added
tool to the release process. I do not have a strong opinion though. If
others prefer we can switch to this tool. One nice benefit of this tool
would be to avoid merge conflicts if many different PRs edit the change log
file all at the same time in a conflicting way.


>
> I came across this when working on the python-attrs[2] project, which has
> some good documentation for contributors on how to use it:
> https://www.attrs.org/en/stable/contributing.html#changelog
> 
>
>
> [1] https://github.com/hawkowl/towncrier
> [2] https://github.com/python-attrs/attrs
>
>
> On Fri, Jan 31, 2020 at 5:09 PM Ahmet Altay  wrote:
>
>> Thank you for the quick responses. I sent out
>> https://github.com/apache/beam/pull/10743 to make this change. Please
>> provide feedback or directly edit the PR.
>>
>
>> On Fri, Jan 31, 2020 at 3:58 PM Robert Bradshaw 
>> wrote:
>>
>>> Yes, yes, yes! This is the one model of release notes that I've
>>> actually seen work well at scale.
>>>
>>>
>>> https://lists.apache.org/thread.html/41e03ace17dbcccf7e267ba6d538736b2a99a8e73e7fb45702766b17%40%3Cdev.beam.apache.org%3E
>>>
>>> Let's make it happen.
>>>
>>> On Fri, Jan 31, 2020 at 3:47 PM Robert Burke  wrote:
>>> >
>>> > I like this suggestion, Jira titles and commit summaries don't
>>> necessarily reflect the user impact for a given change (or set of changes).
>>> Being able to see the Forest instead of the trees.
>>> >
>>> > On Fri, Jan 31, 2020, 3:37 PM Kenneth Knowles  wrote:
>>> >>
>>> >> +1
>>> >>
>>> >> This is a great idea. Hope it can lead to higher-value view of
>>> relevant changes.
>>> >>
>>> >> I like it being in the root of the repo, so it lives next to the code.
>>> >>
>>> >> Since the website is also markdown, it could be copied over directly
>>> at release time, so it can be browsed there, too.
>>> >>
>>> >> Kenn
>>> >>
>>> >> On Fri, Jan 31, 2020 at 3:16 PM Ahmet Altay  wrote:
>>> >>>
>>> >>> Hi all,
>>> >>>
>>> >>> We currently have two major ways to communicate changes in a release:
>>> >>> - A blog post, to highlight major changes in the release. (Example
>>> for 2.17: [1])
>>> >>> - JIRA release notes pages listing all issues tagged for a specific
>>> release. (Example for 2.17 [2]).
>>> >>>
>>> >>> There are a few issues with this process:
>>> >>> - It is difficult for the release manager to know what is important,
>>> what is a breaking change, what is dependency change etc. For example,
>>> there were more than 150 Jira issues tagged for 2.17 release.
>>> >>> - Release blog has many items, and does not necessarily communicate
>>> important changes. It is difficult for users to discover major changes
>>> short of going through a large list.
>>> >>> - People involved in authoring or reviewing a PRs usually have the
>>> most context about the change, and they are not necessarily involved in the
>>> release process to provide this additional information.
>>> >>>
>>> >>> Would it be helpful if we maintain a simple change list file and
>>> update it as part of the PRs with noteworthy changes? Release managers
>>> could use this information as is in their blog posts (or link to it). Users
>>> will have a single place to find highlights from various versions.
>>> >>>
>>> >>> Concretely, I am proposing:
>>> >>> - Adding a CHANGES file to the root of the repository. (Name could
>>> be anything, TFX uses RELEASE.md in their repo. [3])
>>> >>> - Ask PR authors to update this file as part of their PR whenever it
>>> makes sense
>>> >>> - Reference this file during the release process, and a new section
>>> for the next release after each release.
>>> >>>
>>> >>> Ahmet
>>> >>>
>>> >>> [1] https://beam.apache.org/blog/2020/01/06/beam-2.17.0.html
>>> >>> [2]
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12345970&projectId=12319527
>>> >>> [3] https://github.com/tensorflow/tfx/blob/master/RELEASE.md
>>>
>>

Re: [DISCUSSION] Improve release notes by adding a change list file

[Robert Bradshaw]

I would suggest we start with the simpler single file. If merge
conflicts become an issue, we could look at other options, but I think
it's worth keeping in mind that what we're trying to produce here is a
single, higher-level, cohesive summary of the release rather than a
1:1 listing of commits, pull request, or jira entries (which we can
link to). While new features often merit their own bullet points, this
will allow for entries such as "Several improvements to portability
including ..."

On Mon, Feb 3, 2020 at 1:55 PM Ahmet Altay  wrote:
>
>
>
> On Sat, Feb 1, 2020 at 9:22 AM Chad Dombrova  wrote:
>>
>> In case it's of any use, there's a tool called towncrier[1] to help compile 
>> changelog fragments and compile them at time of delivery.
>
>
> I would prefer not to have the complexity of multiple files and an added tool 
> to the release process. I do not have a strong opinion though. If others 
> prefer we can switch to this tool. One nice benefit of this tool would be to 
> avoid merge conflicts if many different PRs edit the change log file all at 
> the same time in a conflicting way.
>
>>
>>
>> I came across this when working on the python-attrs[2] project, which has 
>> some good documentation for contributors on how to use it: 
>> https://www.attrs.org/en/stable/contributing.html#changelog
>>
>>
>> [1] https://github.com/hawkowl/towncrier
>> [2] https://github.com/python-attrs/attrs
>>
>>
>> On Fri, Jan 31, 2020 at 5:09 PM Ahmet Altay  wrote:
>>>
>>> Thank you for the quick responses. I sent out 
>>> https://github.com/apache/beam/pull/10743 to make this change. Please 
>>> provide feedback or directly edit the PR.
>>>
>>>
>>> On Fri, Jan 31, 2020 at 3:58 PM Robert Bradshaw  wrote:

 Yes, yes, yes! This is the one model of release notes that I've
 actually seen work well at scale.

 https://lists.apache.org/thread.html/41e03ace17dbcccf7e267ba6d538736b2a99a8e73e7fb45702766b17%40%3Cdev.beam.apache.org%3E

 Let's make it happen.

 On Fri, Jan 31, 2020 at 3:47 PM Robert Burke  wrote:
 >
 > I like this suggestion, Jira titles and commit summaries don't 
 > necessarily reflect the user impact for a given change (or set of 
 > changes). Being able to see the Forest instead of the trees.
 >
 > On Fri, Jan 31, 2020, 3:37 PM Kenneth Knowles  wrote:
 >>
 >> +1
 >>
 >> This is a great idea. Hope it can lead to higher-value view of relevant 
 >> changes.
 >>
 >> I like it being in the root of the repo, so it lives next to the code.
 >>
 >> Since the website is also markdown, it could be copied over directly at 
 >> release time, so it can be browsed there, too.
 >>
 >> Kenn
 >>
 >> On Fri, Jan 31, 2020 at 3:16 PM Ahmet Altay  wrote:
 >>>
 >>> Hi all,
 >>>
 >>> We currently have two major ways to communicate changes in a release:
 >>> - A blog post, to highlight major changes in the release. (Example for 
 >>> 2.17: [1])
 >>> - JIRA release notes pages listing all issues tagged for a specific 
 >>> release. (Example for 2.17 [2]).
 >>>
 >>> There are a few issues with this process:
 >>> - It is difficult for the release manager to know what is important, 
 >>> what is a breaking change, what is dependency change etc. For example, 
 >>> there were more than 150 Jira issues tagged for 2.17 release.
 >>> - Release blog has many items, and does not necessarily communicate 
 >>> important changes. It is difficult for users to discover major changes 
 >>> short of going through a large list.
 >>> - People involved in authoring or reviewing a PRs usually have the 
 >>> most context about the change, and they are not necessarily involved 
 >>> in the release process to provide this additional information.
 >>>
 >>> Would it be helpful if we maintain a simple change list file and 
 >>> update it as part of the PRs with noteworthy changes? Release managers 
 >>> could use this information as is in their blog posts (or link to it). 
 >>> Users will have a single place to find highlights from various 
 >>> versions.
 >>>
 >>> Concretely, I am proposing:
 >>> - Adding a CHANGES file to the root of the repository. (Name could be 
 >>> anything, TFX uses RELEASE.md in their repo. [3])
 >>> - Ask PR authors to update this file as part of their PR whenever it 
 >>> makes sense
 >>> - Reference this file during the release process, and a new section 
 >>> for the next release after each release.
 >>>
 >>> Ahmet
 >>>
 >>> [1] https://beam.apache.org/blog/2020/01/06/beam-2.17.0.html
 >>> [2] 
 >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12345970&projectId=12319527
 >>> [3] https://github.com/tensorflow/tfx/blob/master/RELEASE.md

Re: More details about PR #9852: Add option to set a temp dataset in BigQueryIO

[Pablo Estrada]

Thanks Israel! I see Chamikara has reviewed it.

On Sun, Feb 2, 2020 at 7:55 AM Israel Herraiz  wrote:

> Hi all,
>
> I have updated and polished a pull request  I submitted some time ago, and
> I would like to bring it to the attention of this list, to see if I could
> get some feedback or review of the code.
>
> The PR is at https://github.com/apache/beam/pull/9852
>
> It adds a new option withQueryTempDataset to BigQueryIO.Read.
>
> Currently, if I want to read from a table with BigQueryIO, I need to
> assign the role bigquery.jobUser to the service account  of Apache Beam
> (e.g. Dataflow).
>
> However, if I try to read from a view using the same role, the pipeline
> will fail, because it needs to create a temporary dataset and table. The
> name of this dataset is chosen by Apache Beam.
>
> This in practice requires giving the service account the permission to
> create datasets (e.g. assigning the role bigquery.user, not
> bigquery.jobUser), which is a very broad permission.
>
> With the submitted PR, you can specify the temporary dataset used to read
> from queries (e.g. reading from a view). Thus you can just keep the role
> bigquery.jobUser in the Beam service account, and just provide additional
> permissions in that dataset to create temporary tables (confining any
> potential write activity to that dataset only).
>
> The destination dataset can even be in a different project than the data
> you are reading (something that is not possible with the currently
> available options), so you don't need to give write permissions in the same
> project where the data resides. In situations where there is a
> "untouchable" data project with authorized views, it is currently
> impossible to read from those authorized views with BigQueryIO, unless you
> give write permissions to Beam in the "untouchable" project. With this PR,
> you could confine those writes to another project and dataset.
>
> I hope the need for this option makes sense. Any thoughts?
>
> Kind regards,
> Israel
>

Re: Jenkins jobs not running for my PR 10438

[Tomo Suzuki]

Hi Beam committers,

I appreciate if you can trigger precommit checks for
https://github.com/apache/beam/pull/10756 .

Regards,
Tomo

Re: Jenkins jobs not running for my PR 10438

[Kyle Weaver]

> I appreciate if you can trigger precommit checks for
> https://github.com/apache/beam/pull/10756 .

Got it, thanks for the PR!

On Mon, Feb 3, 2020 at 2:58 PM Tomo Suzuki  wrote:

> Hi Beam committers,
>
> I appreciate if you can trigger precommit checks for
> https://github.com/apache/beam/pull/10756 .
>
> Regards,
> Tomo
>
>

Re: [RELEASE VOTE RESULT] Release 2.19.0, release candidate #1

[Ahmet Altay]

On Mon, Feb 3, 2020 at 1:22 PM Thomas Weise  wrote:

> Impressive, probably the fastest/smoothest Beam release so far.
>

I agree! Thank you, Boyuan!


>
> On Mon, Feb 3, 2020 at 10:45 AM Boyuan Zhang  wrote:
>
>> I'm happy to announce that we have unanimously approved this release.
>>
>> There are 5 approving votes, 4 of which are binging:
>> * Ahmet Altay
>> * Ismaël Mejía
>> * Jean-Baptiste Onofré
>> * Robert Bradshaw
>>
>> There are no disapproving votes.
>>
>> Thanks for everyone's help! I'm going to finalize the release and send
>> out the official release announcement later.
>>
>

Re: [DISCUSSION] Improve release notes by adding a change list file

[Ahmet Altay]

On Mon, Feb 3, 2020 at 2:09 PM Robert Bradshaw  wrote:

> I would suggest we start with the simpler single file. If merge
> conflicts become an issue, we could look at other options, but I think
> it's worth keeping in mind that what we're trying to produce here is a
> single, higher-level, cohesive summary of the release rather than a
> 1:1 listing of commits, pull request, or jira entries (which we can
> link to). While new features often merit their own bullet points, this
> will allow for entries such as "Several improvements to portability
> including ..."
>

I agree. If there are no objections I will go ahead with the PR I proposed.
It adds a single change log file to begin with.

We would need all committers to help after that by asking PR authors to
update this file whenever it makes sense.


>
> On Mon, Feb 3, 2020 at 1:55 PM Ahmet Altay  wrote:
> >
> >
> >
> > On Sat, Feb 1, 2020 at 9:22 AM Chad Dombrova  wrote:
> >>
> >> In case it's of any use, there's a tool called towncrier[1] to help
> compile changelog fragments and compile them at time of delivery.
> >
> >
> > I would prefer not to have the complexity of multiple files and an added
> tool to the release process. I do not have a strong opinion though. If
> others prefer we can switch to this tool. One nice benefit of this tool
> would be to avoid merge conflicts if many different PRs edit the change log
> file all at the same time in a conflicting way.
> >
> >>
> >>
> >> I came across this when working on the python-attrs[2] project, which
> has some good documentation for contributors on how to use it:
> https://www.attrs.org/en/stable/contributing.html#changelog
> >>
> >>
> >> [1] https://github.com/hawkowl/towncrier
> >> [2] https://github.com/python-attrs/attrs
> >>
> >>
> >> On Fri, Jan 31, 2020 at 5:09 PM Ahmet Altay  wrote:
> >>>
> >>> Thank you for the quick responses. I sent out
> https://github.com/apache/beam/pull/10743 to make this change. Please
> provide feedback or directly edit the PR.
> >>>
> >>>
> >>> On Fri, Jan 31, 2020 at 3:58 PM Robert Bradshaw 
> wrote:
> 
>  Yes, yes, yes! This is the one model of release notes that I've
>  actually seen work well at scale.
> 
> 
> https://lists.apache.org/thread.html/41e03ace17dbcccf7e267ba6d538736b2a99a8e73e7fb45702766b17%40%3Cdev.beam.apache.org%3E
> 
>  Let's make it happen.
> 
>  On Fri, Jan 31, 2020 at 3:47 PM Robert Burke 
> wrote:
>  >
>  > I like this suggestion, Jira titles and commit summaries don't
> necessarily reflect the user impact for a given change (or set of changes).
> Being able to see the Forest instead of the trees.
>  >
>  > On Fri, Jan 31, 2020, 3:37 PM Kenneth Knowles 
> wrote:
>  >>
>  >> +1
>  >>
>  >> This is a great idea. Hope it can lead to higher-value view of
> relevant changes.
>  >>
>  >> I like it being in the root of the repo, so it lives next to the
> code.
>  >>
>  >> Since the website is also markdown, it could be copied over
> directly at release time, so it can be browsed there, too.
>  >>
>  >> Kenn
>  >>
>  >> On Fri, Jan 31, 2020 at 3:16 PM Ahmet Altay 
> wrote:
>  >>>
>  >>> Hi all,
>  >>>
>  >>> We currently have two major ways to communicate changes in a
> release:
>  >>> - A blog post, to highlight major changes in the release.
> (Example for 2.17: [1])
>  >>> - JIRA release notes pages listing all issues tagged for a
> specific release. (Example for 2.17 [2]).
>  >>>
>  >>> There are a few issues with this process:
>  >>> - It is difficult for the release manager to know what is
> important, what is a breaking change, what is dependency change etc. For
> example, there were more than 150 Jira issues tagged for 2.17 release.
>  >>> - Release blog has many items, and does not necessarily
> communicate important changes. It is difficult for users to discover major
> changes short of going through a large list.
>  >>> - People involved in authoring or reviewing a PRs usually have
> the most context about the change, and they are not necessarily involved in
> the release process to provide this additional information.
>  >>>
>  >>> Would it be helpful if we maintain a simple change list file and
> update it as part of the PRs with noteworthy changes? Release managers
> could use this information as is in their blog posts (or link to it). Users
> will have a single place to find highlights from various versions.
>  >>>
>  >>> Concretely, I am proposing:
>  >>> - Adding a CHANGES file to the root of the repository. (Name
> could be anything, TFX uses RELEASE.md in their repo. [3])
>  >>> - Ask PR authors to update this file as part of their PR whenever
> it makes sense
>  >>> - Reference this file during the release process, and a new
> section for the next release after each release.
>  >>>
>  >>> Ahmet
>  >>>
>  >>> [1] https://beam.apache.org/blog/2020/0

Re: [DISCUSSION] Improve release notes by adding a change list file

[Robert Bradshaw]

On Mon, Feb 3, 2020 at 4:49 PM Ahmet Altay  wrote:
>
> On Mon, Feb 3, 2020 at 2:09 PM Robert Bradshaw  wrote:
>>
>> I would suggest we start with the simpler single file. If merge
>> conflicts become an issue, we could look at other options, but I think
>> it's worth keeping in mind that what we're trying to produce here is a
>> single, higher-level, cohesive summary of the release rather than a
>> 1:1 listing of commits, pull request, or jira entries (which we can
>> link to). While new features often merit their own bullet points, this
>> will allow for entries such as "Several improvements to portability
>> including ..."
>
> I agree. If there are no objections I will go ahead with the PR I proposed. 
> It adds a single change log file to begin with.
>
> We would need all committers to help after that by asking PR authors to 
> update this file whenever it makes sense.

Yes. Should we add it to the PR template checklist?

>> On Mon, Feb 3, 2020 at 1:55 PM Ahmet Altay  wrote:
>> >
>> >
>> >
>> > On Sat, Feb 1, 2020 at 9:22 AM Chad Dombrova  wrote:
>> >>
>> >> In case it's of any use, there's a tool called towncrier[1] to help 
>> >> compile changelog fragments and compile them at time of delivery.
>> >
>> >
>> > I would prefer not to have the complexity of multiple files and an added 
>> > tool to the release process. I do not have a strong opinion though. If 
>> > others prefer we can switch to this tool. One nice benefit of this tool 
>> > would be to avoid merge conflicts if many different PRs edit the change 
>> > log file all at the same time in a conflicting way.
>> >
>> >>
>> >>
>> >> I came across this when working on the python-attrs[2] project, which has 
>> >> some good documentation for contributors on how to use it: 
>> >> https://www.attrs.org/en/stable/contributing.html#changelog
>> >>
>> >>
>> >> [1] https://github.com/hawkowl/towncrier
>> >> [2] https://github.com/python-attrs/attrs
>> >>
>> >>
>> >> On Fri, Jan 31, 2020 at 5:09 PM Ahmet Altay  wrote:
>> >>>
>> >>> Thank you for the quick responses. I sent out 
>> >>> https://github.com/apache/beam/pull/10743 to make this change. Please 
>> >>> provide feedback or directly edit the PR.
>> >>>
>> >>>
>> >>> On Fri, Jan 31, 2020 at 3:58 PM Robert Bradshaw  
>> >>> wrote:
>> 
>>  Yes, yes, yes! This is the one model of release notes that I've
>>  actually seen work well at scale.
>> 
>>  https://lists.apache.org/thread.html/41e03ace17dbcccf7e267ba6d538736b2a99a8e73e7fb45702766b17%40%3Cdev.beam.apache.org%3E
>> 
>>  Let's make it happen.
>> 
>>  On Fri, Jan 31, 2020 at 3:47 PM Robert Burke  wrote:
>>  >
>>  > I like this suggestion, Jira titles and commit summaries don't 
>>  > necessarily reflect the user impact for a given change (or set of 
>>  > changes). Being able to see the Forest instead of the trees.
>>  >
>>  > On Fri, Jan 31, 2020, 3:37 PM Kenneth Knowles  wrote:
>>  >>
>>  >> +1
>>  >>
>>  >> This is a great idea. Hope it can lead to higher-value view of 
>>  >> relevant changes.
>>  >>
>>  >> I like it being in the root of the repo, so it lives next to the 
>>  >> code.
>>  >>
>>  >> Since the website is also markdown, it could be copied over directly 
>>  >> at release time, so it can be browsed there, too.
>>  >>
>>  >> Kenn
>>  >>
>>  >> On Fri, Jan 31, 2020 at 3:16 PM Ahmet Altay  wrote:
>>  >>>
>>  >>> Hi all,
>>  >>>
>>  >>> We currently have two major ways to communicate changes in a 
>>  >>> release:
>>  >>> - A blog post, to highlight major changes in the release. (Example 
>>  >>> for 2.17: [1])
>>  >>> - JIRA release notes pages listing all issues tagged for a specific 
>>  >>> release. (Example for 2.17 [2]).
>>  >>>
>>  >>> There are a few issues with this process:
>>  >>> - It is difficult for the release manager to know what is 
>>  >>> important, what is a breaking change, what is dependency change 
>>  >>> etc. For example, there were more than 150 Jira issues tagged for 
>>  >>> 2.17 release.
>>  >>> - Release blog has many items, and does not necessarily communicate 
>>  >>> important changes. It is difficult for users to discover major 
>>  >>> changes short of going through a large list.
>>  >>> - People involved in authoring or reviewing a PRs usually have the 
>>  >>> most context about the change, and they are not necessarily 
>>  >>> involved in the release process to provide this additional 
>>  >>> information.
>>  >>>
>>  >>> Would it be helpful if we maintain a simple change list file and 
>>  >>> update it as part of the PRs with noteworthy changes? Release 
>>  >>> managers could use this information as is in their blog posts (or 
>>  >>> link to it). Users will have a single place to find highlights from 
>>  >>> various versions.
>>  >>>
>>  >>> Concretely, I a

Re: [DISCUSSION] Improve release notes by adding a change list file

[Udi Meiri]

+1 to add this to the checklist

On Mon, Feb 3, 2020 at 4:57 PM Robert Bradshaw  wrote:

> On Mon, Feb 3, 2020 at 4:49 PM Ahmet Altay  wrote:
> >
> > On Mon, Feb 3, 2020 at 2:09 PM Robert Bradshaw 
> wrote:
> >>
> >> I would suggest we start with the simpler single file. If merge
> >> conflicts become an issue, we could look at other options, but I think
> >> it's worth keeping in mind that what we're trying to produce here is a
> >> single, higher-level, cohesive summary of the release rather than a
> >> 1:1 listing of commits, pull request, or jira entries (which we can
> >> link to). While new features often merit their own bullet points, this
> >> will allow for entries such as "Several improvements to portability
> >> including ..."
> >
> > I agree. If there are no objections I will go ahead with the PR I
> proposed. It adds a single change log file to begin with.
> >
> > We would need all committers to help after that by asking PR authors to
> update this file whenever it makes sense.
>
> Yes. Should we add it to the PR template checklist?
>
> >> On Mon, Feb 3, 2020 at 1:55 PM Ahmet Altay  wrote:
> >> >
> >> >
> >> >
> >> > On Sat, Feb 1, 2020 at 9:22 AM Chad Dombrova 
> wrote:
> >> >>
> >> >> In case it's of any use, there's a tool called towncrier[1] to help
> compile changelog fragments and compile them at time of delivery.
> >> >
> >> >
> >> > I would prefer not to have the complexity of multiple files and an
> added tool to the release process. I do not have a strong opinion though.
> If others prefer we can switch to this tool. One nice benefit of this tool
> would be to avoid merge conflicts if many different PRs edit the change log
> file all at the same time in a conflicting way.
> >> >
> >> >>
> >> >>
> >> >> I came across this when working on the python-attrs[2] project,
> which has some good documentation for contributors on how to use it:
> https://www.attrs.org/en/stable/contributing.html#changelog
> >> >>
> >> >>
> >> >> [1] https://github.com/hawkowl/towncrier
> >> >> [2] https://github.com/python-attrs/attrs
> >> >>
> >> >>
> >> >> On Fri, Jan 31, 2020 at 5:09 PM Ahmet Altay 
> wrote:
> >> >>>
> >> >>> Thank you for the quick responses. I sent out
> https://github.com/apache/beam/pull/10743 to make this change. Please
> provide feedback or directly edit the PR.
> >> >>>
> >> >>>
> >> >>> On Fri, Jan 31, 2020 at 3:58 PM Robert Bradshaw <
> rober...@google.com> wrote:
> >> 
> >>  Yes, yes, yes! This is the one model of release notes that I've
> >>  actually seen work well at scale.
> >> 
> >> 
> https://lists.apache.org/thread.html/41e03ace17dbcccf7e267ba6d538736b2a99a8e73e7fb45702766b17%40%3Cdev.beam.apache.org%3E
> >> 
> >>  Let's make it happen.
> >> 
> >>  On Fri, Jan 31, 2020 at 3:47 PM Robert Burke 
> wrote:
> >>  >
> >>  > I like this suggestion, Jira titles and commit summaries don't
> necessarily reflect the user impact for a given change (or set of changes).
> Being able to see the Forest instead of the trees.
> >>  >
> >>  > On Fri, Jan 31, 2020, 3:37 PM Kenneth Knowles 
> wrote:
> >>  >>
> >>  >> +1
> >>  >>
> >>  >> This is a great idea. Hope it can lead to higher-value view of
> relevant changes.
> >>  >>
> >>  >> I like it being in the root of the repo, so it lives next to
> the code.
> >>  >>
> >>  >> Since the website is also markdown, it could be copied over
> directly at release time, so it can be browsed there, too.
> >>  >>
> >>  >> Kenn
> >>  >>
> >>  >> On Fri, Jan 31, 2020 at 3:16 PM Ahmet Altay 
> wrote:
> >>  >>>
> >>  >>> Hi all,
> >>  >>>
> >>  >>> We currently have two major ways to communicate changes in a
> release:
> >>  >>> - A blog post, to highlight major changes in the release.
> (Example for 2.17: [1])
> >>  >>> - JIRA release notes pages listing all issues tagged for a
> specific release. (Example for 2.17 [2]).
> >>  >>>
> >>  >>> There are a few issues with this process:
> >>  >>> - It is difficult for the release manager to know what is
> important, what is a breaking change, what is dependency change etc. For
> example, there were more than 150 Jira issues tagged for 2.17 release.
> >>  >>> - Release blog has many items, and does not necessarily
> communicate important changes. It is difficult for users to discover major
> changes short of going through a large list.
> >>  >>> - People involved in authoring or reviewing a PRs usually have
> the most context about the change, and they are not necessarily involved in
> the release process to provide this additional information.
> >>  >>>
> >>  >>> Would it be helpful if we maintain a simple change list file
> and update it as part of the PRs with noteworthy changes? Release managers
> could use this information as is in their blog posts (or link to it). Users
> will have a single place to find highlights from various versions.
> >>  >>>
> >> >

Re: [RELEASE VOTE RESULT] Release 2.19.0, release candidate #1

[Udi Meiri]

Thank you Boyuan!

On Mon, Feb 3, 2020 at 3:40 PM Ahmet Altay  wrote:

> On Mon, Feb 3, 2020 at 1:22 PM Thomas Weise  wrote:
>
>> Impressive, probably the fastest/smoothest Beam release so far.
>>
>
> I agree! Thank you, Boyuan!
>
>
>>
>> On Mon, Feb 3, 2020 at 10:45 AM Boyuan Zhang  wrote:
>>
>>> I'm happy to announce that we have unanimously approved this release.
>>>
>>> There are 5 approving votes, 4 of which are binging:
>>> * Ahmet Altay
>>> * Ismaël Mejía
>>> * Jean-Baptiste Onofré
>>> * Robert Bradshaw
>>>
>>> There are no disapproving votes.
>>>
>>> Thanks for everyone's help! I'm going to finalize the release and send
>>> out the official release announcement later.
>>>
>>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [DISCUSSION] Improve release notes by adding a change list file

[Ahmet Altay]

Done, updated the PR template checklist as well.

On Mon, Feb 3, 2020 at 5:05 PM Udi Meiri  wrote:

> +1 to add this to the checklist
>
> On Mon, Feb 3, 2020 at 4:57 PM Robert Bradshaw 
> wrote:
>
>> On Mon, Feb 3, 2020 at 4:49 PM Ahmet Altay  wrote:
>> >
>> > On Mon, Feb 3, 2020 at 2:09 PM Robert Bradshaw 
>> wrote:
>> >>
>> >> I would suggest we start with the simpler single file. If merge
>> >> conflicts become an issue, we could look at other options, but I think
>> >> it's worth keeping in mind that what we're trying to produce here is a
>> >> single, higher-level, cohesive summary of the release rather than a
>> >> 1:1 listing of commits, pull request, or jira entries (which we can
>> >> link to). While new features often merit their own bullet points, this
>> >> will allow for entries such as "Several improvements to portability
>> >> including ..."
>> >
>> > I agree. If there are no objections I will go ahead with the PR I
>> proposed. It adds a single change log file to begin with.
>> >
>> > We would need all committers to help after that by asking PR authors to
>> update this file whenever it makes sense.
>>
>> Yes. Should we add it to the PR template checklist?
>>
>> >> On Mon, Feb 3, 2020 at 1:55 PM Ahmet Altay  wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Sat, Feb 1, 2020 at 9:22 AM Chad Dombrova 
>> wrote:
>> >> >>
>> >> >> In case it's of any use, there's a tool called towncrier[1] to help
>> compile changelog fragments and compile them at time of delivery.
>> >> >
>> >> >
>> >> > I would prefer not to have the complexity of multiple files and an
>> added tool to the release process. I do not have a strong opinion though.
>> If others prefer we can switch to this tool. One nice benefit of this tool
>> would be to avoid merge conflicts if many different PRs edit the change log
>> file all at the same time in a conflicting way.
>> >> >
>> >> >>
>> >> >>
>> >> >> I came across this when working on the python-attrs[2] project,
>> which has some good documentation for contributors on how to use it:
>> https://www.attrs.org/en/stable/contributing.html#changelog
>> >> >>
>> >> >>
>> >> >> [1] https://github.com/hawkowl/towncrier
>> >> >> [2] https://github.com/python-attrs/attrs
>> >> >>
>> >> >>
>> >> >> On Fri, Jan 31, 2020 at 5:09 PM Ahmet Altay 
>> wrote:
>> >> >>>
>> >> >>> Thank you for the quick responses. I sent out
>> https://github.com/apache/beam/pull/10743 to make this change. Please
>> provide feedback or directly edit the PR.
>> >> >>>
>> >> >>>
>> >> >>> On Fri, Jan 31, 2020 at 3:58 PM Robert Bradshaw <
>> rober...@google.com> wrote:
>> >> 
>> >>  Yes, yes, yes! This is the one model of release notes that I've
>> >>  actually seen work well at scale.
>> >> 
>> >> 
>> https://lists.apache.org/thread.html/41e03ace17dbcccf7e267ba6d538736b2a99a8e73e7fb45702766b17%40%3Cdev.beam.apache.org%3E
>> >> 
>> >>  Let's make it happen.
>> >> 
>> >>  On Fri, Jan 31, 2020 at 3:47 PM Robert Burke 
>> wrote:
>> >>  >
>> >>  > I like this suggestion, Jira titles and commit summaries don't
>> necessarily reflect the user impact for a given change (or set of changes).
>> Being able to see the Forest instead of the trees.
>> >>  >
>> >>  > On Fri, Jan 31, 2020, 3:37 PM Kenneth Knowles 
>> wrote:
>> >>  >>
>> >>  >> +1
>> >>  >>
>> >>  >> This is a great idea. Hope it can lead to higher-value view of
>> relevant changes.
>> >>  >>
>> >>  >> I like it being in the root of the repo, so it lives next to
>> the code.
>> >>  >>
>> >>  >> Since the website is also markdown, it could be copied over
>> directly at release time, so it can be browsed there, too.
>> >>  >>
>> >>  >> Kenn
>> >>  >>
>> >>  >> On Fri, Jan 31, 2020 at 3:16 PM Ahmet Altay 
>> wrote:
>> >>  >>>
>> >>  >>> Hi all,
>> >>  >>>
>> >>  >>> We currently have two major ways to communicate changes in a
>> release:
>> >>  >>> - A blog post, to highlight major changes in the release.
>> (Example for 2.17: [1])
>> >>  >>> - JIRA release notes pages listing all issues tagged for a
>> specific release. (Example for 2.17 [2]).
>> >>  >>>
>> >>  >>> There are a few issues with this process:
>> >>  >>> - It is difficult for the release manager to know what is
>> important, what is a breaking change, what is dependency change etc. For
>> example, there were more than 150 Jira issues tagged for 2.17 release.
>> >>  >>> - Release blog has many items, and does not necessarily
>> communicate important changes. It is difficult for users to discover major
>> changes short of going through a large list.
>> >>  >>> - People involved in authoring or reviewing a PRs usually
>> have the most context about the change, and they are not necessarily
>> involved in the release process to provide this additional information.
>> >>  >>>
>> >>  >>> Would it be helpful if we maintain a simple change list file
>> and update it as 

Re: [RELEASE VOTE RESULT] Release 2.19.0, release candidate #1

[Ankur Goenka]

Thanks Boyuan!
A record has been set :)

On Mon, Feb 3, 2020 at 5:05 PM Udi Meiri  wrote:

> Thank you Boyuan!
>
> On Mon, Feb 3, 2020 at 3:40 PM Ahmet Altay  wrote:
>
>> On Mon, Feb 3, 2020 at 1:22 PM Thomas Weise  wrote:
>>
>>> Impressive, probably the fastest/smoothest Beam release so far.
>>>
>>
>> I agree! Thank you, Boyuan!
>>
>>
>>>
>>> On Mon, Feb 3, 2020 at 10:45 AM Boyuan Zhang  wrote:
>>>
 I'm happy to announce that we have unanimously approved this release.

 There are 5 approving votes, 4 of which are binging:
 * Ahmet Altay
 * Ismaël Mejía
 * Jean-Baptiste Onofré
 * Robert Bradshaw

 There are no disapproving votes.

 Thanks for everyone's help! I'm going to finalize the release and send
 out the official release announcement later.

>>>

Re: [RELEASE VOTE RESULT] Release 2.19.0, release candidate #1

[Yichi Zhang]

Thanks, Boyuan!

On Mon, Feb 3, 2020 at 5:14 PM Ankur Goenka  wrote:

> Thanks Boyuan!
> A record has been set :)
>
> On Mon, Feb 3, 2020 at 5:05 PM Udi Meiri  wrote:
>
>> Thank you Boyuan!
>>
>> On Mon, Feb 3, 2020 at 3:40 PM Ahmet Altay  wrote:
>>
>>> On Mon, Feb 3, 2020 at 1:22 PM Thomas Weise  wrote:
>>>
 Impressive, probably the fastest/smoothest Beam release so far.

>>>
>>> I agree! Thank you, Boyuan!
>>>
>>>

 On Mon, Feb 3, 2020 at 10:45 AM Boyuan Zhang 
 wrote:

> I'm happy to announce that we have unanimously approved this release.
>
> There are 5 approving votes, 4 of which are binging:
> * Ahmet Altay
> * Ismaël Mejía
> * Jean-Baptiste Onofré
> * Robert Bradshaw
>
> There are no disapproving votes.
>
> Thanks for everyone's help! I'm going to finalize the release and send
> out the official release announcement later.
>