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
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
Hey everyone,
I appreciate that the Beam community is having another look at this.
I don't have any strong opinions on these options, but think
that extracting Avro in its own extension is the better choice.
I've already given a stab at extracting Avro in its own module (PR: 12748
[1]). The way
Thanks so much for all these pointers, Alexey. Having that context really helps!
Skimming through the past conversations, this one key consideration hasn’t
changed and seems still critical:
AvroCoder is the de facto standard for encoding complex user types (with
SchemaCoder still being
Hi,
Thanks Alexey for bringing this topic up.
I'd be in favor of 3
Best
Etienne
Le 12/05/2022 à 23:21, Brian Hulette a écrit :
Regarding Option (3) "but keep and shade Avro for “core” needs as
v.1.8.2 (still have an issue with CVEs)"
Do we actually need to keep avro in core for any
Hi Jack,
Silencing info logs for that class during IT tests would be a quick fix, but
also removing logging there entirely shouldn’t hurt.
If the S3 filesystem is used it’ll fail on first usage and the issue should be
fairly obvious…
Though wondering, this is logged once when file systems are
