Hello Beam Dev!
The 2.26 branch has been cut [1] and is open for cherry pick requests.
Current open issues [2] are presently minimal, and I'll be triaging them in
earnest for inclusion into the release branch on Wednesday.
There's presently an issue I can use help with with the current nightly
On Mon, Nov 9, 2020 at 3:37 PM Brian Hulette wrote:
>
>
> On Mon, Nov 9, 2020 at 2:55 PM Ahmet Altay wrote:
>
>> This sounds reasonable. A few questions:
>> - Do we need to expand the test matrix every 3 months or so to add
>> support for different versions of pyarrow?
>>
>
> Yes I think so. If
On Mon, Nov 9, 2020 at 3:32 PM Valentyn Tymofieiev
wrote:
> I actually added a commit on that PR and it still didn't work:
> https://github.com/apache/beam/pull/13242/commits/b9a872b039b5ff27b2678365ec777b64acb18a0e
> .
> I'll try to clone the PR and trigger the seed job as a workaround.
>
The
On Mon, Nov 9, 2020 at 2:55 PM Ahmet Altay wrote:
> This sounds reasonable. A few questions:
> - Do we need to expand the test matrix every 3 months or so to add support
> for different versions of pyarrow?
>
Yes I think so. If there's a concern that this will become excessive we
might consider
I actually added a commit on that PR and it still didn't work:
https://github.com/apache/beam/pull/13242/commits/b9a872b039b5ff27b2678365ec777b64acb18a0e
.
I'll try to clone the PR and trigger the seed job as a workaround.
On Mon, Nov 9, 2020 at 10:46 AM Udi Meiri wrote:
> Yeah, I've had that
This sounds reasonable. A few questions:
- Do we need to expand the test matrix every 3 months or so to add support
for different versions of pyarrow?
- Which pyarrow version will we ship in the default container?
- Related to the LZ4 regression, how did we catch this? If this is a one
off that is
Hi everyone,
The Python SDK has a dependency on pyarrow [1], currently only used by
ParquetIO for its parquet reader and writer. The arrow project recently hit
a major milestone with their 1.0 release. They now make forward- and
backward- compatibility guarantees for the IPC format, which is very
I see. We do iterate over all configurations and try to force it to our dep
version [1]. Clearly this does not work as intended, perhaps when the dep
is only transitive and not immediate? Is that what you mean Ismaël?
As a workaround, if a user sets a version this should "win". But the
problem I
But users will still receive the bad 3.13.0 transitively, shouldn't
this be fixed for the next release?
Is there a JIRA?
On Mon, Nov 9, 2020 at 9:44 PM Kenneth Knowles wrote:
>
> The protobuf bug summarizes the issue well. It is built against Java 11
> bootclasspath even though it targets
The protobuf bug summarizes the issue well. It is built against Java 11
bootclasspath even though it targets bytecode compatibility with Java 8.
It seems like we intend to be at 3.12.0 by default:
Yeah, I've had that issue recently:
https://github.com/apache/beam/pull/13213 (seed job did not trigger)
I've personally never seen where this is configured, but it sounds like it.
What happens if you edit a file in the PR? It should make you a co-author.
On Mon, Nov 9, 2020 at 3:36 AM Kamil
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
86.0.4240.22.0
Has anyone noticed problems with running "run seed job" by committers when
the author of the Pull Request is NOT a committer? For example:
https://github.com/apache/beam/pull/13242. Neither I nor Valentyn could
trigger the job. Does it mean that it's an author's username that really
matters, not a
13 matches
Mail list logo
