[FYI] How to disable Dependabot spam on your fork

[Danny McCormick via dev]

GitHub just shipped a feature to disable Dependabot updates on your
forks[1]. If you're like me, you've found Dependabot opening PRs on your
Beam fork annoying; to fix this, go to https://github.com//beam/settings/security_analysis and disable Dependabot version
updates.

This will automatically get applied to any new forks.

Thanks,
Danny

[1]
https://github.com/dependabot/dependabot-core/issues/2804#issuecomment-1306143227

Re: Pipleline portable proto visualizaiton

[Matt Casters]

Apache Hop pipelines are actually just XML files. So if you know how the
source pipeline looks you can convert it and visualize and edit it using
the Hop GUI.

On Mon, Nov 7, 2022 at 6:19 PM Valentyn Tymofieiev via dev <
dev@beam.apache.org> wrote:

> I'd like to visualize a DAG for a Beam portable pipeline, from a .pb file
> or a textproto representation.
>
> Is some runner's UI readily available to make it possible (without
> executing the job)? I was thinking perhaps Apache Hop integration (if we
> have one) might be able to do that.
>
> If not, it should be fairly simple to convert the pipeline to dot format
> and use graphviz.
>
> Thanks,
> Valentyn
>


-- 
Neo4j Chief Solutions Architect
*✉   *matt.cast...@neo4j.com

Re: [DISCUSS] Jenkins -> GitHub Actions ?

[Kenneth Knowles]

OK, it seems like there is general consensus. Not too much action on the
document. I will summarize the gaps that don't have an answer in the doc,
and my new opinion of how important they are:

 - [required] Run specific non-default workflow on PR
 - [required] View history of a workflow
 - [required] Publish nightly snapshots
 - [required] Run workflow on dedicated worker pool for performance testing
 - [important but not required] Summarize flakiness statistics of one or
all workflows
 - [important but not required] History of all/many workflows in a single
view
 - [nice to have] History of specific test case (not just the workflow
level)

Do any of these seem like I got the importance wrong?

Kenn

On Mon, Nov 7, 2022 at 9:09 AM Austin Bennett  wrote:

> +1
>
> Also would help address a good amount of what concerns me that was [sorta]
> raised by https://lists.apache.org/thread/7jr99nc5xsb3ft1d75kb0ml32bzw89rv
>
>
>
> Once we think this is something we want to do, but might be
> blocked/concerned because of lack of definitively comparable features, I'd
> be happy to take a look at what exists in the wider ecosystem or could be
> built.
>
> Cheers -
>
>
>
> On Fri, Oct 21, 2022 at 11:10 AM Ismaël Mejía  wrote:
>
>> +1 Github Actions are more intuitive and easy to modify and test for
>> everyone.
>> Also Beam wins because that makes one less system to maintain.
>>
>> Regards,
>> Ismaël
>>
>> On Wed, Oct 19, 2022 at 5:50 PM Danny McCormick via dev
>>  wrote:
>> >
>> > Thanks for kicking this conversation off. I'm +1 on migrating, but only
>> once we've found a specific replacement for easy observability (which
>> workflows have been failing lately, and how often) and trigger phrases (for
>> retries and workflows that aren't automatically kicked off but should be
>> run for extra validation, e.g. postcommits). Until we have viable
>> replacements, I don't think we should make the move. Publishing nightly
>> snapshots is eventually also a must to fully migrate, but probably doesn't
>> need to block us from making progress here.
>> >
>> > With those caveats, the reason that I'm +1 on moving is that our
>> Jenkins reliability has been rough. Since I joined the project in January,
>> I can think of 3 different incidents that significantly harmed our ability
>> to do work.
>> >
>> > 1. Jenkins triggers cause multi-day outage - this led to a multi-day
>> code freeze, and we lost our trigger functionality for days afterwards.
>> Investigating/restoring our state ate up a pretty full week for me.
>> > 2. Jenkins plugin cause multi-day outage - this led to multiple days of
>> Jenkins downtime before eventually being resolved by Infra.
>> > 3. Cert issues cause many workers to go down - I don't have a thread
>> for this because I handled most of the investigation the day of, but many
>> of our workers went down for around a day and nobody noticed until queue
>> time reached 6+ hours for each workflow.
>> >
>> > There may be others that I'm overlooking.
>> >
>> > GitHub Actions isn't a magic bullet to fix these problems, but it
>> minimizes the amount of infra that we're maintaining ourselves, increases
>> the isolation between workflows (catastrophic failure is less likely), has
>> uptime guarantees, and is more likely to receive investment going forward
>> (we're likely to get increasing benefits over time for free). We've also
>> done a lot of exploration in this area already, so we're not starting from
>> scratch.
>> >
>> > Thanks,
>> > Danny
>> >
>> > On Wed, Oct 19, 2022 at 11:32 AM Kenneth Knowles 
>> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> As you probably noticed, there's a lot of work going on around adding
>> more GitHub Actions workflows.
>> >>
>> >> Can we fully migrate to GitHub Actions? Similar to our GitHub Issues
>> migration (but less user-facing) it would bring us on to "default"
>> infrastructure that more people understand and is maintained by GitHub.
>> >>
>> >> So far we have hit some serious roadblocks. It isn't just a simple
>> migration. We have to weigh doing the work to get there.
>> >>
>> >> I started a document with a table of the things we get from Jenkins
>> that we need to be sure to have for GitHub Actions before we could think
>> about migrating:
>> >>
>> >> https://s.apache.org/beam-jenkins-to-gha
>> >>
>> >> Can you please help me by adding things that we get from Jenkins, and
>> if you know how to get them from GitHub Actions add that too.
>> >>
>> >> Thanks!
>> >>
>> >> Kenn
>>
>

Re: Pipleline portable proto visualizaiton

[Valentyn Tymofieiev via dev]

Thanks a lot, sounds like that would help avoid reinventing the wheel.

On Mon, Nov 7, 2022 at 9:28 AM Robert Bradshaw  wrote:

> I've got one I use in Python too (including drilling down into
> composites). It's a portable runner. I should clean it up and make it
> generally available.
>
> On Mon, Nov 7, 2022 at 9:25 AM Robert Burke  wrote:
> >
> > The Go SDK has a "dot" runner to visualize pipeline protos as a dot
> graph but it's it's not set up as a portable runner. Probably wouldn't be
> too hard to get it to operate as a stand alone tool, for someone motivated
> enough.
> >
> > On Mon, Nov 7, 2022, 9:19 AM Valentyn Tymofieiev via dev <
> dev@beam.apache.org> wrote:
> >>
> >> I'd like to visualize a DAG for a Beam portable pipeline, from a .pb
> file or a textproto representation.
> >>
> >> Is some runner's UI readily available to make it possible (without
> executing the job)? I was thinking perhaps Apache Hop integration (if we
> have one) might be able to do that.
> >>
> >> If not, it should be fairly simple to convert the pipeline to dot
> format and use graphviz.
> >>
> >> Thanks,
> >> Valentyn
>

Re: Pipleline portable proto visualizaiton

[Robert Bradshaw via dev]

I've got one I use in Python too (including drilling down into
composites). It's a portable runner. I should clean it up and make it
generally available.

On Mon, Nov 7, 2022 at 9:25 AM Robert Burke  wrote:
>
> The Go SDK has a "dot" runner to visualize pipeline protos as a dot graph but 
> it's it's not set up as a portable runner. Probably wouldn't be too hard to 
> get it to operate as a stand alone tool, for someone motivated enough.
>
> On Mon, Nov 7, 2022, 9:19 AM Valentyn Tymofieiev via dev 
>  wrote:
>>
>> I'd like to visualize a DAG for a Beam portable pipeline, from a .pb file or 
>> a textproto representation.
>>
>> Is some runner's UI readily available to make it possible (without executing 
>> the job)? I was thinking perhaps Apache Hop integration (if we have one) 
>> might be able to do that.
>>
>> If not, it should be fairly simple to convert the pipeline to dot format and 
>> use graphviz.
>>
>> Thanks,
>> Valentyn

Re: Pipleline portable proto visualizaiton

[Robert Burke]

The Go SDK has a "dot" runner to visualize pipeline protos as a dot graph
but it's it's not set up as a portable runner. Probably wouldn't be too
hard to get it to operate as a stand alone tool, for someone motivated
enough.

On Mon, Nov 7, 2022, 9:19 AM Valentyn Tymofieiev via dev <
dev@beam.apache.org> wrote:

> I'd like to visualize a DAG for a Beam portable pipeline, from a .pb file
> or a textproto representation.
>
> Is some runner's UI readily available to make it possible (without
> executing the job)? I was thinking perhaps Apache Hop integration (if we
> have one) might be able to do that.
>
> If not, it should be fairly simple to convert the pipeline to dot format
> and use graphviz.
>
> Thanks,
> Valentyn
>

Pipleline portable proto visualizaiton

[Valentyn Tymofieiev via dev]

I'd like to visualize a DAG for a Beam portable pipeline, from a .pb file
or a textproto representation.

Is some runner's UI readily available to make it possible (without
executing the job)? I was thinking perhaps Apache Hop integration (if we
have one) might be able to do that.

If not, it should be fairly simple to convert the pipeline to dot format
and use graphviz.

Thanks,
Valentyn

Re: [DISCUSS] Jenkins -> GitHub Actions ?

[Austin Bennett]

+1

Also would help address a good amount of what concerns me that was [sorta]
raised by https://lists.apache.org/thread/7jr99nc5xsb3ft1d75kb0ml32bzw89rv


Once we think this is something we want to do, but might be
blocked/concerned because of lack of definitively comparable features, I'd
be happy to take a look at what exists in the wider ecosystem or could be
built.

Cheers -



On Fri, Oct 21, 2022 at 11:10 AM Ismaël Mejía  wrote:

> +1 Github Actions are more intuitive and easy to modify and test for
> everyone.
> Also Beam wins because that makes one less system to maintain.
>
> Regards,
> Ismaël
>
> On Wed, Oct 19, 2022 at 5:50 PM Danny McCormick via dev
>  wrote:
> >
> > Thanks for kicking this conversation off. I'm +1 on migrating, but only
> once we've found a specific replacement for easy observability (which
> workflows have been failing lately, and how often) and trigger phrases (for
> retries and workflows that aren't automatically kicked off but should be
> run for extra validation, e.g. postcommits). Until we have viable
> replacements, I don't think we should make the move. Publishing nightly
> snapshots is eventually also a must to fully migrate, but probably doesn't
> need to block us from making progress here.
> >
> > With those caveats, the reason that I'm +1 on moving is that our Jenkins
> reliability has been rough. Since I joined the project in January, I can
> think of 3 different incidents that significantly harmed our ability to do
> work.
> >
> > 1. Jenkins triggers cause multi-day outage - this led to a multi-day
> code freeze, and we lost our trigger functionality for days afterwards.
> Investigating/restoring our state ate up a pretty full week for me.
> > 2. Jenkins plugin cause multi-day outage - this led to multiple days of
> Jenkins downtime before eventually being resolved by Infra.
> > 3. Cert issues cause many workers to go down - I don't have a thread for
> this because I handled most of the investigation the day of, but many of
> our workers went down for around a day and nobody noticed until queue time
> reached 6+ hours for each workflow.
> >
> > There may be others that I'm overlooking.
> >
> > GitHub Actions isn't a magic bullet to fix these problems, but it
> minimizes the amount of infra that we're maintaining ourselves, increases
> the isolation between workflows (catastrophic failure is less likely), has
> uptime guarantees, and is more likely to receive investment going forward
> (we're likely to get increasing benefits over time for free). We've also
> done a lot of exploration in this area already, so we're not starting from
> scratch.
> >
> > Thanks,
> > Danny
> >
> > On Wed, Oct 19, 2022 at 11:32 AM Kenneth Knowles 
> wrote:
> >>
> >> Hi all,
> >>
> >> As you probably noticed, there's a lot of work going on around adding
> more GitHub Actions workflows.
> >>
> >> Can we fully migrate to GitHub Actions? Similar to our GitHub Issues
> migration (but less user-facing) it would bring us on to "default"
> infrastructure that more people understand and is maintained by GitHub.
> >>
> >> So far we have hit some serious roadblocks. It isn't just a simple
> migration. We have to weigh doing the work to get there.
> >>
> >> I started a document with a table of the things we get from Jenkins
> that we need to be sure to have for GitHub Actions before we could think
> about migrating:
> >>
> >> https://s.apache.org/beam-jenkins-to-gha
> >>
> >> Can you please help me by adding things that we get from Jenkins, and
> if you know how to get them from GitHub Actions add that too.
> >>
> >> Thanks!
> >>
> >> Kenn
>

Re: [Python][Bikeshed] typehint vs. type-hint vs. "type hint"

[Jack McCluskey via dev]

I'm in agreement that how we refer to type hints in documentation should be
standardized across the board. It's a good practice for both style and
clarity. Seems like it wouldn't be too hard to update our docstrings
either, based on a quick search of the repo.

On Mon, Nov 7, 2022 at 9:00 AM Brian Hulette via dev 
wrote:

> Hi everyone,
>
> In a recent code review we noticed that we are not consistent when
> describing python type hints in documentation. Depending on who wrote the
> patch, we switch between typehint, type-hint, and "type hint" [1].
>
> I think we should standardize on "type hint" as this is what Guido used in
> PEP 484 [2]. Please comment on the issue in the next few days if you
> disagree with this approach.
>
> Note this is orthogonal to how we refer to type hints in _code_, in our
> public APIs. In general we use "type" in that context (e.g.
> `with_input_types`), and there doesn't seem to be a consistency issue.
>
> [1] https://github.com/apache/beam/issues/23950
> [2] https://peps.python.org/pep-0484/
>

Re: Beam starter projects dependency updates

[Brian Hulette via dev]

These have all been addressed. I went through and merged all of them,
except for the slf4j-jdk14 dependency in Java and Kotlin. After consulting
with Luke [1] I told dependabot to ignore this dependency.

[1]
https://github.com/apache/beam-starter-java/pull/26#issuecomment-130263Java9941


On Wed, Nov 2, 2022 at 10:58 AM David Cavazos  wrote:

> Hi, I just opened some PRs to auto-assign dependabot PRs.
>
> Java: https://github.com/apache/beam-starter-java/pull/29
> Python: https://github.com/apache/beam-starter-python/pull/11
> Go: https://github.com/apache/beam-starter-go/pull/7
> Kotlin: https://github.com/apache/beam-starter-kotlin/pull/9
>
> For the existing dependabot PRs, can someone help me batch merge them? All
> tests are passing on all of them, so they should all be safe to merge.
>
> On Thu, Oct 27, 2022 at 1:56 PM Brian Hulette  wrote:
>
>> Could we just use the same set of reviewers as pr-bot in the main repo
>> [1]? I don't think that we could avoid duplicating the data though.
>>
>> [1]
>> https://github.com/apache/beam/blob/728e8ecc8a40d3d578ada7773b77eca2b3c68d03/.github/REVIEWERS.yml
>>
>> On Thu, Oct 27, 2022 at 12:20 PM David Cavazos via dev <
>> dev@beam.apache.org> wrote:
>>
>>> Hi everyone!
>>>
>>> We want to make sure the Beam starter projects always come with the
>>> latest (compatible) versions for every dependency. I enabled Dependabot on
>>> all of them to automate this as much as possible, and we have automated
>>> tests to make sure everything works as expected.
>>>
>>> However, we still need someone to merge Dependabot's PRs. The good news
>>> is that since the starter projects are so simple, if tests pass they're
>>> most likely safe to merge, and tests only take a couple minutes to run.
>>>
>>> We could either batch update all dependencies as part of the release
>>> process, or have people check them periodically (like an owner per
>>> language).
>>>
>>> These are all the repos we have to keep an eye to:
>>>
>>>- https://github.com/apache/beam-starter-java -- 9 updates, all
>>>tests passing
>>>- https://github.com/apache/beam-starter-python -- 2 updates, all
>>>tests passing
>>>- https://github.com/apache/beam-starter-go -- 0 updates
>>>- https://github.com/apache/beam-starter-kotlin -- 3 updates, all
>>>tests passing
>>>- https://github.com/apache/beam-starter-scala -- not done yet, but
>>>keep an eye
>>>
>>>

[Python][Bikeshed] typehint vs. type-hint vs. "type hint"

[Brian Hulette via dev]

Hi everyone,

In a recent code review we noticed that we are not consistent when
describing python type hints in documentation. Depending on who wrote the
patch, we switch between typehint, type-hint, and "type hint" [1].

I think we should standardize on "type hint" as this is what Guido used in
PEP 484 [2]. Please comment on the issue in the next few days if you
disagree with this approach.

Note this is orthogonal to how we refer to type hints in _code_, in our
public APIs. In general we use "type" in that context (e.g.
`with_input_types`), and there doesn't seem to be a consistency issue.

[1] https://github.com/apache/beam/issues/23950
[2] https://peps.python.org/pep-0484/

Beam High Priority Issue Report (61)

[beamactions]

This is your daily summary of Beam's current high priority issues that may need 
attention.

See https://beam.apache.org/contribute/issue-priorities for the meaning and 
expectations around issue priorities.

Unassigned P1 Issues:

https://github.com/apache/beam/issues/23982 [Bug]: Could not find a version 
that matches protobuf
https://github.com/apache/beam/issues/23974 [Bug]: The top tesult for "Beam 
godocs" in Google points to an old Godocs page of Beam
https://github.com/apache/beam/issues/23944  beam_PreCommit_Python_Cron 
regularily failing - test_pardo_large_input flaky
https://github.com/apache/beam/issues/23940 beam_PostCommit_Py_ValCont failing
https://github.com/apache/beam/issues/23815 [Bug]: Neo4j tests failing
https://github.com/apache/beam/issues/23745 [Bug]: Samza 
AsyncDoFnRunnerTest.testSimplePipeline is flaky
https://github.com/apache/beam/issues/23709 [Flake]: Spark batch flakes in 
ParDoLifecycleTest.testTeardownCalledAfterExceptionInProcessElement and 
ParDoLifecycleTest.testTeardownCalledAfterExceptionInStartBundle
https://github.com/apache/beam/issues/22969 Discrepancy in behavior of 
`DoFn.process()` when `yield` is combined with `return` statement, or vice versa
https://github.com/apache/beam/issues/22913 [Bug]: 
beam_PostCommit_Java_ValidatesRunner_Flink is flakes in 
org.apache.beam.sdk.transforms.GroupByKeyTest$BasicTests.testAfterProcessingTimeContinuationTriggerUsingState
https://github.com/apache/beam/issues/22321 
PortableRunnerTestWithExternalEnv.test_pardo_large_input is regularly failing 
on jenkins
https://github.com/apache/beam/issues/21713 404s in BigQueryIO don't get output 
to Failed Inserts PCollection
https://github.com/apache/beam/issues/21561 
ExternalPythonTransformTest.trivialPythonTransform flaky
https://github.com/apache/beam/issues/21469 beam_PostCommit_XVR_Flink flaky: 
Connection refused
https://github.com/apache/beam/issues/21462 Flake in 
org.apache.beam.sdk.io.mqtt.MqttIOTest.testReadObject: Address already in use
https://github.com/apache/beam/issues/21261 
org.apache.beam.runners.dataflow.worker.fn.logging.BeamFnLoggingServiceTest.testMultipleClientsFailingIsHandledGracefullyByServer
 is flaky
https://github.com/apache/beam/issues/21260 Python DirectRunner does not emit 
data at GC time
https://github.com/apache/beam/issues/21123 Multiple jobs running on Flink 
session cluster reuse the persistent Python environment.
https://github.com/apache/beam/issues/21113 
testTwoTimersSettingEachOtherWithCreateAsInputBounded flaky
https://github.com/apache/beam/issues/20976 
apache_beam.runners.portability.flink_runner_test.FlinkRunnerTestOptimized.test_flink_metrics
 is flaky
https://github.com/apache/beam/issues/20975 
org.apache.beam.runners.flink.ReadSourcePortableTest.testExecution[streaming: 
false] is flaky
https://github.com/apache/beam/issues/20974 Python GHA PreCommits flake with 
grpc.FutureTimeoutError on SDK harness startup
https://github.com/apache/beam/issues/20689 Kafka commitOffsetsInFinalize OOM 
on Flink
https://github.com/apache/beam/issues/20108 Python direct runner doesn't emit 
empty pane when it should
https://github.com/apache/beam/issues/19814 Flink streaming flakes in 
ParDoLifecycleTest.testTeardownCalledAfterExceptionInStartBundleStateful and 
ParDoLifecycleTest.testTeardownCalledAfterExceptionInProcessElementStateful
https://github.com/apache/beam/issues/19734 
WatchTest.testMultiplePollsWithManyResults flake: Outputs must be in timestamp 
order (sickbayed)
https://github.com/apache/beam/issues/19241 Python Dataflow integration tests 
should export the pipeline Job ID and console output to Jenkins Test Result 
section


P1 Issues with no update in the last week:

https://github.com/apache/beam/issues/23875 [Bug]: beam.Row.__eq__ returns true 
for unequal rows
https://github.com/apache/beam/issues/23855 [FLAKY-WORKFLOW] [10535797]: THIS 
IS A TEST, PLEASE IGNORE #1
https://github.com/apache/beam/issues/23627 [Bug]: Website precommit flaky
https://github.com/apache/beam/issues/23525 [Bug]: Default PubsubMessage coder 
will drop message id and orderingKey
https://github.com/apache/beam/issues/23489 [Bug]: add DebeziumIO to the 
connectors page
https://github.com/apache/beam/issues/23306 [Bug]: BigQueryBatchFileLoads in 
python loses data when using WRITE_TRUNCATE
https://github.com/apache/beam/issues/23286 [Bug]: 
beam_PerformanceTests_InfluxDbIO_IT Flaky > 50 % Fail 
https://github.com/apache/beam/issues/22891 [Bug]: 
beam_PostCommit_XVR_PythonUsingJavaDataflow is flaky
https://github.com/apache/beam/issues/22605 [Bug]: Beam Python failure for 
dataflow_exercise_metrics_pipeline_test.ExerciseMetricsPipelineTest.test_metrics_it
https://github.com/apache/beam/issues/22299 [Bug]: JDBCIO Write freeze at 
getConnection() in WriteFn
https://github.com/apache/beam/issues/22115 [Bug]: 
apache_beam.runners.portability.portable_runner_test.PortableRunnerTestWithSubprocesses
 is flaky
https://github.com/apache/beam/issues/22011 [Bug]: 

Re: [ANNOUNCE] New committer: Ritesh Ghorse

[Moritz Mack]

Congrats, Ritesh 

On 05.11.22, 03:08, "Ahmet Altay via dev"  wrote:

Congratulations Ritesh! On Fri, Nov 4, 2022 at 12: 18 PM Ritesh Ghorse via dev 
 wrote: Thanks everyone! I'm glad to be a part of this 
community and I look forward to making more contributions in whatever ways I

Congratulations Ritesh!

On Fri, Nov 4, 2022 at 12:18 PM Ritesh Ghorse via dev 
mailto:dev@beam.apache.org>> wrote:
Thanks everyone! I'm glad to be a part of this community and I look forward to 
making more contributions in whatever ways I can.

On Fri, Nov 4, 2022 at 12:36 PM Chamikara Jayalath via dev 
mailto:dev@beam.apache.org>> wrote:
Congrats, Ritesh!

On Fri, Nov 4, 2022 at 9:34 AM John Casey via dev 
mailto:dev@beam.apache.org>> wrote:
Congrats!

On Fri, Nov 4, 2022 at 10:36 AM Ahmed Abualsaud via dev 
mailto:dev@beam.apache.org>> wrote:
Congrats Ritesh!

On Fri, Nov 4, 2022 at 10:29 AM Andy Ye via dev 
mailto:dev@beam.apache.org>> wrote:
Congrats Ritesh!

On Fri, Nov 4, 2022 at 9:26 AM Kerry Donny-Clark via dev 
mailto:dev@beam.apache.org>> wrote:
Congratulations Ritesh, I'm happy to see your hard work and community spirit 
recognized!

On Fri, Nov 4, 2022 at 10:16 AM Jack McCluskey via dev 
mailto:dev@beam.apache.org>> wrote:
Congrats Ritesh!

On Thu, Nov 3, 2022 at 10:12 PM Danny McCormick via dev 
mailto:dev@beam.apache.org>> wrote:
Congrats Ritesh! This is definitely well deserved!

On Thu, Nov 3, 2022 at 8:08 PM Robert Burke 
mailto:rob...@frantil.com>> wrote:
Woohoo! Well done Ritesh! :D

On Thu, Nov 3, 2022, 5:04 PM Anand Inguva via dev 
mailto:dev@beam.apache.org>> wrote:
Congratulations Ritesh.

On Thu, Nov 3, 2022 at 7:51 PM Yi Hu via dev 
mailto:dev@beam.apache.org>> wrote:
Congratulations Ritesh!

On Thu, Nov 3, 2022 at 7:23 PM Byron Ellis via dev 
mailto:dev@beam.apache.org>> wrote:
Congratulations!

On Thu, Nov 3, 2022 at 4:21 PM Austin Bennett 
mailto:whatwouldausti...@gmail.com>> wrote:
Congratulations, and Thanks 
@riteshgho...@apache.org!

On Thu, Nov 3, 2022 at 4:17 PM Sachin Agarwal via dev 
mailto:dev@beam.apache.org>> wrote:
Congrats Ritesh!

On Thu, Nov 3, 2022 at 4:16 PM Kenneth Knowles 
mailto:k...@apache.org>> wrote:
Hi all,

Please join me and the rest of the Beam PMC in welcoming a new committer: 
Ritesh Ghorse (riteshgho...@apache.org)
Ritesh started contributing to Beam in mid-2021 and has contributed immensely 
to bringin the Go SDK to fruition, in addition to contributions to Java and 
Python and release validation.

Considering their contributions to the project over this timeframe, the Beam 
PMC trusts Ritesh with the responsibilities of a Beam committer. [1]

Thank you Ritesh! And we are looking to see more of your contributions!

Kenn, on behalf of the Apache Beam PMC

[1]
https://beam.apache.org/contribute/become-a-committer/#an-apache-beam-committer

As a recipient of an email from Talend, your contact personal data will be on 
our systems. Please see our privacy notice.