Oh, I just missed it then :)
Thank you Lukasz for connecting us.
Yeah, the two TimerReceiverTest tests fail reliably for me.
On Tue, 2 Apr 2019 at 23:53, Lukasz Cwik wrote:
> +Ahmed
>
> I have added you as a contributor.
>
> It seems as though Ahmed had just picked up BEAM-3489 yesterday.
Agree that a coder URN defines the encoding. I see that string UTF-8 was
added to the proto enum, but it needs a written spec of the encoding.
Ideally some test data that different languages can use to drive compliance
testing.
Kenn
On Wed, Apr 3, 2019 at 6:21 PM Robert Burke wrote:
> String
This all makes me think that we should rethink how we ship experimental
features. My experience is also that (1) users don't know if something is
experimental or don't think hard about it and (2) we don't use experimental
time period to gather feedback and make changes.
How can we change both of
Hi,
Our Jenkins are in a bad condition. 8 agents are down at this time, and
they are not going to be restored because of some bad errors happened on
the Puppet server due to the consistent re-provisioning. There are several
discussions in the recent weeks between the ASF Infra and us. In general,
String UTF8 was recently added as a "standard coder " URN in the protos,
but I don't think that developed beyond Java, so adding it to Python would
be reasonable in my opinion.
The Go SDK handles Strings as "custom coders" presently which for Go are
always length prefixed (and reported to the
I think a release version with Experimental flag makes sense.
In addition, I think many of our user start to rely on experimental
features because they are not even aware that these features are
experimental and its really hard to find the experimental features used
without giving a good look at
I mean, +1 for removing support for old Kafka versions after next LTS
What the cut off should be for 'old' version is can be discussed then. My
choice would be 0.11.
Raghu.
On Wed, Apr 3, 2019 at 4:36 PM Raghu Angadi wrote:
> +1 for next LTS.
>
> On Wed, Apr 3, 2019 at 2:30 PM Ismaël Mejía
Our Experimental annotation has become almost useless. Many core,
widely-used parts of the API (e.g. triggers) are still all marked as
experimental. So many users use these features that we couldn't really
change them (in a backwards-incompatible) without hurting many users, so
the fact they are
I suggest keeping the bug open until the cherry-pick is complete. That
makes tracking the burndown easier and is more accurate treatment of Fix
Version.
And from the other direction, a good practice is to check not only the Jira
burndown [1] and also search for pull requests targeting the release
> We might also want to get in the habit of reviewing if something should
no longer be experimental.
+1
Kyle Weaver | Software Engineer | kcwea...@google.com | +1650203
On Wed, Apr 3, 2019 at 3:53 PM Kenneth Knowles wrote:
> I think option 2 with n=1 minor version seems OK. So users
I think option 2 with n=1 minor version seems OK. So users get the message
for one release and it is gone the next. We should make sure the
deprecation warning says "this is an experimental feature, so it will be
removed after 1 minor version". And we need a process for doing it so it
doesn't sit
When we did the first stable release of Beam (2.0.0) we decided to
annotate most of the Beam IOs as @Experimental because we were
cautious about not getting the APIs right in the first try. This was a
really good decision because we could do serious improvements and
refactorings to them in the
We should focus on the main reason to remove the Kafka 0.9 support. I
have the impression that this is mostly to ease the maintenance, but
from the current status (and the removal PR [1]), it does not seem
like it is a burden to continue supporting 0.9. In any case I am +1 to
remove the support
Hi All
Initially the ASF as an organisation was planning to apply as a
mentoring organisation for Google Season of Docs on behalf of all Apache
projects but if accepted the maximum number of technical writers we
could allocated is two. Two technical writers would probably not be
enough to
-1
The release misses a cherry pick [1] that fixes an important issue in
Cassandra, without this users won't be able to write to Cassandra. I
know at least 3 users who are waiting for this release to have this
fixed.
[1] https://github.com/apache/beam/pull/8198/files
On Wed, Apr 3, 2019 at 8:34
I believe this is where the metrics are supplied:
https://github.com/apache/beam/blob/master/sdks/python/apache_beam/runners/worker/operations.py
git grep process_bundle_msecs yields results for dataflow worker only
There isn't any test coverage for the Flink runner:
Hi everyone,
Please review and vote on the release candidate #1 for the version 2.12.0,
as follows:
[ ] +1, Approve the release
[ ] -1, Do not approve the release (please provide specific comments)
The complete staging area is available for your review, which includes:
* JIRA release notes [1],
Turns out much of the work was completed to populate and consume the urn +
payloads.
I have deprecated the single "url" field in enviornment with
https://github.com/apache/beam/pull/8213 which will allow us to close of
BEAM-5433.
On Mon, Apr 1, 2019 at 1:48 PM Lukasz Cwik wrote:
> Yes, need to
Should have added- I'm using Python sdk, Flink runner
On Wed, Apr 3, 2019 at 10:32 AM Akshay Balwally wrote:
> Hi,
> I'm hoping to get metrics on the amount of time spent on each operator, so
> it seams like the stat
>
>
>
Hi,
I'm hoping to get metrics on the amount of time spent on each operator, so
it seams like the stat
{organization_specific_prefix}.operator.beam-metric-pardo_execution_time-process_bundle_msecs-v1.gauge.mean
would be pretty helpful. But in practice, this stat always shows 0, which I
interpret
On Wed, Apr 3, 2019 at 5:46 AM David Morávek
wrote:
> I'd say that APIs we use in KafkaIO are pretty much stable since 0.10
> release, all reflection based compatibility adapters seem to be aimed for
> 0.9 release (which is 8 major releases behind current Kafka release).
>
> We may take an
Hi Pasan!
Thanks for the proposal. I'll try to take a look in the next few hours and
give some feedback.
Best
--P.
On Wed, Apr 3, 2019, 8:53 AM Ahmet Altay wrote:
> +Pablo Estrada
>
> On Wed, Apr 3, 2019 at 8:46 AM Lukasz Cwik wrote:
>
>> +dev
>>
>> On Wed, Apr 3, 2019 at 2:03 AM Pasan
As a minor point, we do have some cross language dependencies, for example:
* the portability related proto projects are intended to be consumed by Go,
Java and Python
* the docker container gradle projects contain other applications (e.g. go
boot code) that are placed inside the docker container
+Pablo Estrada
On Wed, Apr 3, 2019 at 8:46 AM Lukasz Cwik wrote:
> +dev
>
> On Wed, Apr 3, 2019 at 2:03 AM Pasan Kamburugamuwa <
> pasankamburugamu...@gmail.com> wrote:
>
>> Hi ,
>>
>> I have completed a proposal to implementation an S3 file system for
>> python SDK for the google summer of
+dev
On Wed, Apr 3, 2019 at 2:03 AM Pasan Kamburugamuwa <
pasankamburugamu...@gmail.com> wrote:
> Hi ,
>
> I have completed a proposal to implementation an S3 file system for python
> SDK for the google summer of Code 2019. Please can you guys review this
> proposal and if there is any issues
+1
On 02.04.19 22:56, Mikhail Gryzykhin wrote:
+1 to suppress warnings globally. If we care about an issue, it should
be error.
On Tue, Apr 2, 2019 at 5:38 AM Alexey Romanenko
mailto:aromanenko@gmail.com>> wrote:
+1 to suppress such warnings globally. IMO, usually, meaningful
I'd say that APIs we use in KafkaIO are pretty much stable since 0.10
release, all reflection based compatibility adapters seem to be aimed for
0.9 release (which is 8 major releases behind current Kafka release).
We may take an inspiration from Flink's kafka connector
27 matches
Mail list logo
