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
88.0.4324.96.0
+1
On Tue, Jun 15, 2021 at 12:31 AM Aizhamal Nurmamat kyzy
wrote:
> Thank you all! Based on the feedback, I will set up a session for a couple
> open source groups. Will share more details soon. Stay tuned.
>
> On Mon, Jun 7, 2021 at 4:42 PM Kenneth Knowles wrote:
>
>> Yes please!
>>
>> On
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
Thank you all! Based on the feedback, I will set up a session for a couple
open source groups. Will share more details soon. Stay tuned.
On Mon, Jun 7, 2021 at 4:42 PM Kenneth Knowles wrote:
> Yes please!
>
> On Thu, Jun 3, 2021, 18:32 Ratnakar Malla wrote:
>
>> +1
>>
>>
>>
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
Filed with INFRA:
https://issues.apache.org/jira/browse/INFRA-21995
On 2021/06/10 15:11:51, Robert Burke wrote:
> Ok. I'll fill a ticket with Infra tomorrow once the objection period has
> passed. Thanks!
>
> On Wed, Jun 9, 2021, 12:51 PM Kenneth Knowles wrote:
>
> > Great idea. I think
Enhancements to the SDK which allow for greater declaration of intent would
be useful but the overall issue is that the SDK can send multiple read
requests through the use of readLater() and then block on read() without
the runner being aware that the SDK is blocked.
The runner could implement
Hi there,
I'm not on your PMC but I took a look at your release and noticed something
that you might want to look into and correct:
There a couple of item include in the release that are not mentioned in your
LICENSE file:
./beam-2.30.0/website/www/site/static/js/bootstrap.js
The third approach prevents you from batching across state keys which would
be the most common type of batching.
On Thu, May 6, 2021 at 3:13 PM Rui Wang wrote:
> At this moment, the third approach in the doc is preferred. To recap, the
> third approach is the one that only changes FnApi by
I didn't see user API or SDK changes that I would expect in this proposal.
Maybe I missed it? The main big win for state batching in the runners core
trigger & window implementation is batching requests across a whole bundle.
Certainly across elements. This probably requires something like either:
All release blocking issues are now resolved. I will start building RC1
tomorrow.
On Mon, Jun 7, 2021 at 2:11 PM Andrew Pilloud wrote:
> The 2.31.0 release branch was cut based on the last commit on June 2nd and
> is now available for cherry-picks[1]. There are currently 3 open release
>
This is done. We should be unable to delete release branches accidentally.
Thanks everyone.
On 2021/06/14 19:45:24, Robert Burke wrote:
> Filed with INFRA:
> https://issues.apache.org/jira/browse/INFRA-21995
>
> On 2021/06/10 15:11:51, Robert Burke wrote:
> > Ok. I'll fill a ticket with
The doc needs to be updated: for the third approach, it should also have a
BatchStateRequets which contains a repeated GetStateRequest field to do
cross state keys batching.
-Rui
On Mon, Jun 14, 2021 at 2:46 PM Luke Cwik wrote:
> The third approach prevents you from batching across state keys
13 matches
Mail list logo
