I spoke too soon. We will be doing an rc2
On Mon, Sep 27, 2021 at 1:29 PM Udi Meiri wrote:
> I'm happy to announce that we have unanimously approved this release.
>
> There are 8 approving votes, 4 of which are binding:
> * Ahmet Altay
> * Alexey Romanenko
> * Robert Bradshaw
> * Chamikara Jayal
Ah, thanks for the correction. AfterProcessingTime and AfterCount should
both be flagged, as should AfterEvery, and AfterAny. AfterEach is
different, since if any of the sequenced triggers never finish, the whole
thing will never finish.
Kenn
On Mon, Sep 27, 2021 at 3:51 PM Zachary Houfek wrote:
This was discovered because Repeatedly(AfterProcessingTime(n)) does require
the workaround, because AfterProcessingTime(n) does terminate and that is
propagated by the Repeatedly implementation.
Kenn
On Mon, Sep 27, 2021 at 2:49 PM Robert Bradshaw wrote:
> On Mon, Sep 27, 2021 at 2:42 PM Kennet
True. It is the use case of Repeatedly(ProcessingTime(n)) that I would
guess to be the primary case of concern.
Kenn
On Mon, Sep 27, 2021 at 2:38 PM Robert Bradshaw wrote:
> As I read the code, it's only pipelines that use a Repeatedly trigger
> that wrap an already lossy trigger that are decla
My concern is that the error message is incorrect and every user of 2.33.0
may be educated wrong, or be worried about data loss in Beam, or fail to
find the blog post or CHANGES, etc.
Kenn
On Mon, Sep 27, 2021 at 2:16 PM Udi Meiri wrote:
> I don't know how rare it is, but there is a flag docume
I guess my vote is -0 since I don't have enough context on this issue. A
number of people with more awareness of how severe this is have voted +1 so
I will not try to block the release.
Kenn
On Mon, Sep 27, 2021 at 2:11 PM Kenneth Knowles wrote:
> I have to disagree with the other PMC members h
I have to disagree with the other PMC members here, or at least dig in to
the question: every pipeline that uses a Repeatedly trigger at the top
level will be rejected. Is this so rare in Python that it is OK?
Kenn
On Mon, Sep 27, 2021 at 1:56 PM Robert Burke wrote:
> On it. Thanks!
>
> On Mon,
I'm happy to announce that we have unanimously approved this release.
There are 8 approving votes, 4 of which are binding:
* Ahmet Altay
* Alexey Romanenko
* Robert Bradshaw
* Chamikara Jayalath
There are no disapproving votes.
Thanks everyone!
This is your daily summary of Beam's current flaky tests
(https://issues.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20statusCategory%20!%3D%20Done%20AND%20labels%20%3D%20flake)
These are P1 issues because they have a major negative impact on the community
and make it hard to determin
We should probably add something to the wiki for that.
On Mon, Sep 27, 2021, 10:42 AM Brian Hulette wrote:
> I don't think there's any policy in place for controlling access to the
> apache-beam-testing project. I think in general PMC members are owners and
> committers are editors, but it looks
This is your daily summary of Beam's current P1 issues, not including flaky
tests
(https://issues.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20statusCategory%20!%3D%20Done%20AND%20priority%20%3D%20P1%20AND%20(labels%20is%20EMPTY%20OR%20labels%20!%3D%20flake).
See https://beam.apache.
This is your daily summary of Beam's current outages. See
https://beam.apache.org/contribute/jira-priorities/#p0-outage for the meaning
and expectations around P0 issues.
BEAM-12959: Dataflow error in CombinePerKey operation
(https://issues.apache.org/jira/browse/BEAM-12959)
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
chromedriver-binary
93.0.4577.63.0
95.0.46
13 matches
Mail list logo
