RE: [DISCUSS] Contribution of Multi Cluster Kafka Source

[Ryan van Huuksloot]

Hi Mason,

First off, thanks for putting this FLIP together! Sorry for the delay. Full
disclosure Mason and I chatted a little bit at Flink Forward 2022 but I
have tried to capture the questions I had for him then.

I'll start the conversation with a few questions:

1. The concept of streamIds is not clear to me in the proposal and could
use some more information. If I understand correctly, they will be used in
the MetadataService to link KafkaClusters to ones you want to use? If you
assign stream ids using `setStreamIds`, how can you dynamically increase
the number of clusters you consume if the list of StreamIds is static? I am
basing this off of your example .setStreamIds(List.of("my-stream-1",
"my-stream-2")) so I could be off base with my assumption. If you don't
mind clearing up the intention, that would be great!

2. How would offsets work if you wanted to use this MultiClusterKafkaSource
with a file based backfill? In the case I am thinking of, you have a bucket
backed archive of Kafka data per cluster. and you want to pick up from the
last offset in the archived system, how would you set OffsetInitializers
"per cluster" potentially as a function or are you limited to setting an
OffsetInitializer for the entire Source?

3. Just to make sure - because this system will layer on top of Flink-27
and use KafkaSource for some aspects under the hood, the watermark
alignment that was introduced in FLIP-182 / Flink 1.15 would be possible
across multiple clusters if you assign them to the same alignment group?

Thanks!
Ryan

On 2022/06/24 01:43:38 Mason Chen wrote:
> Hi community,
>
> We have been working on a Multi Cluster Kafka Source and are looking to
> contribute it upstream. I've given a talk about the features and design at
> a Flink meetup: https://youtu.be/H1SYOuLcUTI.
>
> The main features that it provides is:
> 1. Reading multiple Kafka clusters within a single source.
> 2. Adjusting the clusters and topics the source consumes from dynamically,
> without Flink job restart.
>
> Some of the challenging use cases that these features solve are:
> 1. Transparent Kafka cluster migration without Flink job restart.
> 2. Transparent Kafka topic migration without Flink job restart.
> 3. Direct integration with Hybrid Source.
>
> In addition, this is designed with wrapping and managing the existing
> KafkaSource components to enable these features, so it can continue to
> benefit from KafkaSource improvements and bug fixes. It can be considered
> as a form of a composite source.
>
> I think the contribution of this source could benefit a lot of users who
> have asked in the mailing list about Flink handling Kafka migrations and
> removing topics in the past. I would love to hear and address your
thoughts
> and feedback, and if possible drive a FLIP!
>
> Best,
> Mason
>

Re: [DISCUSS] Contribution of Multi Cluster Kafka Source

[Mason Chen]

Hi all,

Circling back on this--I have created a first draft document in confluence:
https://cwiki.apache.org/confluence/display/FLINK/FLIP-246%3A+Multi+Cluster+Kafka+Source
.

Looking forward to hear all your feedback in this email thread!

Best,
Mason

On Thu, Jun 30, 2022 at 6:57 AM Thomas Weise  wrote:

> Hi Mason,
>
> I added mason6345 to the Flink confluence space, you should be able to
> add a FLIP now.
>
> Looking forward to the contribution!
>
> Thomas
>
> On Thu, Jun 30, 2022 at 9:25 AM Martijn Visser 
> wrote:
> >
> > Hi Mason,
> >
> > I'm sure there's a PMC (*hint*) out there who can grant you access to
> > create a FLIP. Looking forward to it, this sounds like an improvement
> that
> > users are looking forward to.
> >
> > Best regards,
> >
> > Martijn
> >
> > Op di 28 jun. 2022 om 09:21 schreef Mason Chen :
> >
> > > Hi all,
> > >
> > > Thanks for the feedback! I'm adding the users, who responded in the
> user
> > > mailing list, to this thread.
> > >
> > > @Qingsheng - Yes, I would prefer to reuse the existing Kafka connector
> > > module. It makes a lot of sense since the dependencies are the same
> and the
> > > implementation can also extend and improve some of the test utilities
> you
> > > have been working on for the FLIP 27 Kafka Source. I will enumerate the
> > > migration steps in the FLIP template.
> > >
> > > @Ryan - I don't have a public branch available yet, but I would
> appreciate
> > > your review on the FLIP design! When the FLIP design is approved by
> devs
> > > and the community, I can start to commit our implementation to a fork.
> > >
> > > @Andrew - Yup, one of the requirements of the connector is to read
> > > multiple clusters within a single source, so it should be able to work
> well
> > > with your use case.
> > >
> > > @Devs - what do I need to get started on the FLIP design? I see the
> FLIP
> > > template and I have an account (mason6345), but I don't have access to
> > > create a page.
> > >
> > > Best,
> > > Mason
> > >
> > >
> > >
> > >
> > > On Sun, Jun 26, 2022 at 8:08 PM Qingsheng Ren 
> wrote:
> > >
> > >> Hi Mason,
> > >>
> > >> It sounds like an exciting enhancement to the Kafka source and will
> > >> benefit a lot of users I believe.
> > >>
> > >> Would you prefer to reuse the existing flink-connector-kafka module or
> > >> create a new one for the new multi-cluster feature? Personally I
> prefer the
> > >> former one because users won’t need to introduce another dependency
> module
> > >> to their projects in order to use the feature.
> > >>
> > >> Thanks for the effort on this and looking forward to your FLIP!
> > >>
> > >> Best,
> > >> Qingsheng
> > >>
> > >> > On Jun 24, 2022, at 09:43, Mason Chen 
> wrote:
> > >> >
> > >> > Hi community,
> > >> >
> > >> > We have been working on a Multi Cluster Kafka Source and are
> looking to
> > >> > contribute it upstream. I've given a talk about the features and
> design
> > >> at
> > >> > a Flink meetup: https://youtu.be/H1SYOuLcUTI.
> > >> >
> > >> > The main features that it provides is:
> > >> > 1. Reading multiple Kafka clusters within a single source.
> > >> > 2. Adjusting the clusters and topics the source consumes from
> > >> dynamically,
> > >> > without Flink job restart.
> > >> >
> > >> > Some of the challenging use cases that these features solve are:
> > >> > 1. Transparent Kafka cluster migration without Flink job restart.
> > >> > 2. Transparent Kafka topic migration without Flink job restart.
> > >> > 3. Direct integration with Hybrid Source.
> > >> >
> > >> > In addition, this is designed with wrapping and managing the
> existing
> > >> > KafkaSource components to enable these features, so it can continue
> to
> > >> > benefit from KafkaSource improvements and bug fixes. It can be
> > >> considered
> > >> > as a form of a composite source.
> > >> >
> > >> > I think the contribution of this source could benefit a lot of
> users who
> > >> > have asked in the mailing list about Flink handling Kafka
> migrations and
> > >> > removing topics in the past. I would love to hear and address your
> > >> thoughts
> > >> > and feedback, and if possible drive a FLIP!
> > >> >
> > >> > Best,
> > >> > Mason
> > >>
> > >>
>

Re: [DISCUSS] Contribution of Multi Cluster Kafka Source

[Thomas Weise]

Hi Mason,

I added mason6345 to the Flink confluence space, you should be able to
add a FLIP now.

Looking forward to the contribution!

Thomas

On Thu, Jun 30, 2022 at 9:25 AM Martijn Visser  wrote:
>
> Hi Mason,
>
> I'm sure there's a PMC (*hint*) out there who can grant you access to
> create a FLIP. Looking forward to it, this sounds like an improvement that
> users are looking forward to.
>
> Best regards,
>
> Martijn
>
> Op di 28 jun. 2022 om 09:21 schreef Mason Chen :
>
> > Hi all,
> >
> > Thanks for the feedback! I'm adding the users, who responded in the user
> > mailing list, to this thread.
> >
> > @Qingsheng - Yes, I would prefer to reuse the existing Kafka connector
> > module. It makes a lot of sense since the dependencies are the same and the
> > implementation can also extend and improve some of the test utilities you
> > have been working on for the FLIP 27 Kafka Source. I will enumerate the
> > migration steps in the FLIP template.
> >
> > @Ryan - I don't have a public branch available yet, but I would appreciate
> > your review on the FLIP design! When the FLIP design is approved by devs
> > and the community, I can start to commit our implementation to a fork.
> >
> > @Andrew - Yup, one of the requirements of the connector is to read
> > multiple clusters within a single source, so it should be able to work well
> > with your use case.
> >
> > @Devs - what do I need to get started on the FLIP design? I see the FLIP
> > template and I have an account (mason6345), but I don't have access to
> > create a page.
> >
> > Best,
> > Mason
> >
> >
> >
> >
> > On Sun, Jun 26, 2022 at 8:08 PM Qingsheng Ren  wrote:
> >
> >> Hi Mason,
> >>
> >> It sounds like an exciting enhancement to the Kafka source and will
> >> benefit a lot of users I believe.
> >>
> >> Would you prefer to reuse the existing flink-connector-kafka module or
> >> create a new one for the new multi-cluster feature? Personally I prefer the
> >> former one because users won’t need to introduce another dependency module
> >> to their projects in order to use the feature.
> >>
> >> Thanks for the effort on this and looking forward to your FLIP!
> >>
> >> Best,
> >> Qingsheng
> >>
> >> > On Jun 24, 2022, at 09:43, Mason Chen  wrote:
> >> >
> >> > Hi community,
> >> >
> >> > We have been working on a Multi Cluster Kafka Source and are looking to
> >> > contribute it upstream. I've given a talk about the features and design
> >> at
> >> > a Flink meetup: https://youtu.be/H1SYOuLcUTI.
> >> >
> >> > The main features that it provides is:
> >> > 1. Reading multiple Kafka clusters within a single source.
> >> > 2. Adjusting the clusters and topics the source consumes from
> >> dynamically,
> >> > without Flink job restart.
> >> >
> >> > Some of the challenging use cases that these features solve are:
> >> > 1. Transparent Kafka cluster migration without Flink job restart.
> >> > 2. Transparent Kafka topic migration without Flink job restart.
> >> > 3. Direct integration with Hybrid Source.
> >> >
> >> > In addition, this is designed with wrapping and managing the existing
> >> > KafkaSource components to enable these features, so it can continue to
> >> > benefit from KafkaSource improvements and bug fixes. It can be
> >> considered
> >> > as a form of a composite source.
> >> >
> >> > I think the contribution of this source could benefit a lot of users who
> >> > have asked in the mailing list about Flink handling Kafka migrations and
> >> > removing topics in the past. I would love to hear and address your
> >> thoughts
> >> > and feedback, and if possible drive a FLIP!
> >> >
> >> > Best,
> >> > Mason
> >>
> >>

Re: [DISCUSS] Contribution of Multi Cluster Kafka Source

[Martijn Visser]

Hi Mason,

I'm sure there's a PMC (*hint*) out there who can grant you access to
create a FLIP. Looking forward to it, this sounds like an improvement that
users are looking forward to.

Best regards,

Martijn

Op di 28 jun. 2022 om 09:21 schreef Mason Chen :

> Hi all,
>
> Thanks for the feedback! I'm adding the users, who responded in the user
> mailing list, to this thread.
>
> @Qingsheng - Yes, I would prefer to reuse the existing Kafka connector
> module. It makes a lot of sense since the dependencies are the same and the
> implementation can also extend and improve some of the test utilities you
> have been working on for the FLIP 27 Kafka Source. I will enumerate the
> migration steps in the FLIP template.
>
> @Ryan - I don't have a public branch available yet, but I would appreciate
> your review on the FLIP design! When the FLIP design is approved by devs
> and the community, I can start to commit our implementation to a fork.
>
> @Andrew - Yup, one of the requirements of the connector is to read
> multiple clusters within a single source, so it should be able to work well
> with your use case.
>
> @Devs - what do I need to get started on the FLIP design? I see the FLIP
> template and I have an account (mason6345), but I don't have access to
> create a page.
>
> Best,
> Mason
>
>
>
>
> On Sun, Jun 26, 2022 at 8:08 PM Qingsheng Ren  wrote:
>
>> Hi Mason,
>>
>> It sounds like an exciting enhancement to the Kafka source and will
>> benefit a lot of users I believe.
>>
>> Would you prefer to reuse the existing flink-connector-kafka module or
>> create a new one for the new multi-cluster feature? Personally I prefer the
>> former one because users won’t need to introduce another dependency module
>> to their projects in order to use the feature.
>>
>> Thanks for the effort on this and looking forward to your FLIP!
>>
>> Best,
>> Qingsheng
>>
>> > On Jun 24, 2022, at 09:43, Mason Chen  wrote:
>> >
>> > Hi community,
>> >
>> > We have been working on a Multi Cluster Kafka Source and are looking to
>> > contribute it upstream. I've given a talk about the features and design
>> at
>> > a Flink meetup: https://youtu.be/H1SYOuLcUTI.
>> >
>> > The main features that it provides is:
>> > 1. Reading multiple Kafka clusters within a single source.
>> > 2. Adjusting the clusters and topics the source consumes from
>> dynamically,
>> > without Flink job restart.
>> >
>> > Some of the challenging use cases that these features solve are:
>> > 1. Transparent Kafka cluster migration without Flink job restart.
>> > 2. Transparent Kafka topic migration without Flink job restart.
>> > 3. Direct integration with Hybrid Source.
>> >
>> > In addition, this is designed with wrapping and managing the existing
>> > KafkaSource components to enable these features, so it can continue to
>> > benefit from KafkaSource improvements and bug fixes. It can be
>> considered
>> > as a form of a composite source.
>> >
>> > I think the contribution of this source could benefit a lot of users who
>> > have asked in the mailing list about Flink handling Kafka migrations and
>> > removing topics in the past. I would love to hear and address your
>> thoughts
>> > and feedback, and if possible drive a FLIP!
>> >
>> > Best,
>> > Mason
>>
>>

Re: [DISCUSS] Contribution of Multi Cluster Kafka Source

[Mason Chen]

Hi all,

Thanks for the feedback! I'm adding the users, who responded in the user
mailing list, to this thread.

@Qingsheng - Yes, I would prefer to reuse the existing Kafka connector
module. It makes a lot of sense since the dependencies are the same and the
implementation can also extend and improve some of the test utilities you
have been working on for the FLIP 27 Kafka Source. I will enumerate the
migration steps in the FLIP template.

@Ryan - I don't have a public branch available yet, but I would appreciate
your review on the FLIP design! When the FLIP design is approved by devs
and the community, I can start to commit our implementation to a fork.

@Andrew - Yup, one of the requirements of the connector is to read multiple
clusters within a single source, so it should be able to work well with
your use case.

@Devs - what do I need to get started on the FLIP design? I see the FLIP
template and I have an account (mason6345), but I don't have access to
create a page.

Best,
Mason




On Sun, Jun 26, 2022 at 8:08 PM Qingsheng Ren  wrote:

> Hi Mason,
>
> It sounds like an exciting enhancement to the Kafka source and will
> benefit a lot of users I believe.
>
> Would you prefer to reuse the existing flink-connector-kafka module or
> create a new one for the new multi-cluster feature? Personally I prefer the
> former one because users won’t need to introduce another dependency module
> to their projects in order to use the feature.
>
> Thanks for the effort on this and looking forward to your FLIP!
>
> Best,
> Qingsheng
>
> > On Jun 24, 2022, at 09:43, Mason Chen  wrote:
> >
> > Hi community,
> >
> > We have been working on a Multi Cluster Kafka Source and are looking to
> > contribute it upstream. I've given a talk about the features and design
> at
> > a Flink meetup: https://youtu.be/H1SYOuLcUTI.
> >
> > The main features that it provides is:
> > 1. Reading multiple Kafka clusters within a single source.
> > 2. Adjusting the clusters and topics the source consumes from
> dynamically,
> > without Flink job restart.
> >
> > Some of the challenging use cases that these features solve are:
> > 1. Transparent Kafka cluster migration without Flink job restart.
> > 2. Transparent Kafka topic migration without Flink job restart.
> > 3. Direct integration with Hybrid Source.
> >
> > In addition, this is designed with wrapping and managing the existing
> > KafkaSource components to enable these features, so it can continue to
> > benefit from KafkaSource improvements and bug fixes. It can be considered
> > as a form of a composite source.
> >
> > I think the contribution of this source could benefit a lot of users who
> > have asked in the mailing list about Flink handling Kafka migrations and
> > removing topics in the past. I would love to hear and address your
> thoughts
> > and feedback, and if possible drive a FLIP!
> >
> > Best,
> > Mason
>
>

RE: Re: [DISCUSS] Contribution of Multi Cluster Kafka Source

[Ryan van Huuksloot]

Hi Mason,

Thanks for starting this discussion! The proposed Source sounds awesome and
we would be interested in taking a look at the source code and evaluating
our use cases. We can provide information and review on a potential FLIP
based on other use cases.

Do you have a fork/branch that you are working with that is public? Could
you attach that so we can start looking at it?

Let us know if you need anything from us to help move this forward.

Thanks!

Ryan van Huuksloot
Data Developer | Data Platform Engineering | Streaming Capabilities
[image: Shopify]

Re: [DISCUSS] Contribution of Multi Cluster Kafka Source

[Qingsheng Ren]

Hi Mason,

It sounds like an exciting enhancement to the Kafka source and will benefit a 
lot of users I believe. 

Would you prefer to reuse the existing flink-connector-kafka module or create a 
new one for the new multi-cluster feature? Personally I prefer the former one 
because users won’t need to introduce another dependency module to their 
projects in order to use the feature. 

Thanks for the effort on this and looking forward to your FLIP!

Best, 
Qingsheng

> On Jun 24, 2022, at 09:43, Mason Chen  wrote:
> 
> Hi community,
> 
> We have been working on a Multi Cluster Kafka Source and are looking to
> contribute it upstream. I've given a talk about the features and design at
> a Flink meetup: https://youtu.be/H1SYOuLcUTI.
> 
> The main features that it provides is:
> 1. Reading multiple Kafka clusters within a single source.
> 2. Adjusting the clusters and topics the source consumes from dynamically,
> without Flink job restart.
> 
> Some of the challenging use cases that these features solve are:
> 1. Transparent Kafka cluster migration without Flink job restart.
> 2. Transparent Kafka topic migration without Flink job restart.
> 3. Direct integration with Hybrid Source.
> 
> In addition, this is designed with wrapping and managing the existing
> KafkaSource components to enable these features, so it can continue to
> benefit from KafkaSource improvements and bug fixes. It can be considered
> as a form of a composite source.
> 
> I think the contribution of this source could benefit a lot of users who
> have asked in the mailing list about Flink handling Kafka migrations and
> removing topics in the past. I would love to hear and address your thoughts
> and feedback, and if possible drive a FLIP!
> 
> Best,
> Mason

[DISCUSS] Contribution of Multi Cluster Kafka Source

[Mason Chen]

Hi community,

We have been working on a Multi Cluster Kafka Source and are looking to
contribute it upstream. I've given a talk about the features and design at
a Flink meetup: https://youtu.be/H1SYOuLcUTI.

The main features that it provides is:
1. Reading multiple Kafka clusters within a single source.
2. Adjusting the clusters and topics the source consumes from dynamically,
without Flink job restart.

Some of the challenging use cases that these features solve are:
1. Transparent Kafka cluster migration without Flink job restart.
2. Transparent Kafka topic migration without Flink job restart.
3. Direct integration with Hybrid Source.

In addition, this is designed with wrapping and managing the existing
KafkaSource components to enable these features, so it can continue to
benefit from KafkaSource improvements and bug fixes. It can be considered
as a form of a composite source.

I think the contribution of this source could benefit a lot of users who
have asked in the mailing list about Flink handling Kafka migrations and
removing topics in the past. I would love to hear and address your thoughts
and feedback, and if possible drive a FLIP!

Best,
Mason

[jira] [Created] (FLINK-26078) Initial Kubernetes Operator Prototype contribution

[Gyula Fora (Jira)]

Gyula Fora created FLINK-26078:
--

 Summary: Initial Kubernetes Operator Prototype contribution
 Key: FLINK-26078
 URL: https://issues.apache.org/jira/browse/FLINK-26078
 Project: Flink
  Issue Type: Sub-task
Reporter: Gyula Fora
Assignee: Gyula Fora


This issue tracks the initial code contribution for the Flink Kubernetes 
operator and any questions or concerns that might arise



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: First contribution - FLINK-24389

[Nikolay Izhikov]

> I have assigned this ticket to you.

Thanks, Jark.

Patch [1] for the issue is ready.
Please, review.

[1] https://github.com/apache/flink/pull/17438

> 8 окт. 2021 г., в 12:01, Jark Wu  написал(а):
> 
> Hi Nikolay,
> 
> I have assigned this ticket to you. Welcome contribution.
> 
> Usually, you can comment under the JIRA issue, and committer will assign
> the issue to you.
> 
> Best,
> Jark
> 
> On Fri, 8 Oct 2021 at 16:32, Nikolay Izhikov  wrote:
> 
>> Hello.
>> 
>> I want to contribute to the Flink.
>> 
>> FLINK-24389 [1] looks link good ticket to start.
>> Can commiter, please, assign ticket to me?
>> Jira ID - nizhikov.
>> 
>> [1] https://issues.apache.org/jira/browse/FLINK-24389
>> 

Re: First contribution - FLINK-24389

[Jark Wu]

Hi Nikolay,

I have assigned this ticket to you. Welcome contribution.

Usually, you can comment under the JIRA issue, and committer will assign
the issue to you.

Best,
Jark

On Fri, 8 Oct 2021 at 16:32, Nikolay Izhikov  wrote:

> Hello.
>
> I want to contribute to the Flink.
>
> FLINK-24389 [1] looks link good ticket to start.
> Can commiter, please, assign ticket to me?
> Jira ID - nizhikov.
>
> [1] https://issues.apache.org/jira/browse/FLINK-24389
>

First contribution - FLINK-24389

[Nikolay Izhikov]

Hello.

I want to contribute to the Flink.

FLINK-24389 [1] looks link good ticket to start.
Can commiter, please, assign ticket to me?
Jira ID - nizhikov.

[1] https://issues.apache.org/jira/browse/FLINK-24389

[jira] [Created] (FLINK-18454) Add a code contribution section about how to look for what to contribute

[Andrey Zagrebin (Jira)]

Andrey Zagrebin created FLINK-18454:
---

 Summary: Add a code contribution section about how to look for 
what to contribute
 Key: FLINK-18454
 URL: https://issues.apache.org/jira/browse/FLINK-18454
 Project: Flink
  Issue Type: Task
  Components: Project Website
Reporter: Andrey Zagrebin
Assignee: Andrey Zagrebin


This section is to give general advices about browsing open Jira issues and 
starter tasks.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Google Season of Docs Contribution

[Marta Paes Moreira]

Hi, Aman!

Thanks for reaching out and for your interest in Google Season of Docs
(GSoD)! To participate, you have to first submit an application with your
project proposal(s) [1]. Just to shed a bit more light on what we are
looking for:

*"Restructure the Table API & SQL Documentation*



*Right now the Table / SQL documentation is very technical and dry to read.
It is more like a technical specification than documentation that a new
user could read. This project is to take the existing content and
rewrite/reorganize it to make what the community already has more
approachable.*
*Extend the Table API & SQL Documentation*

*This is to add brand new content. This could be tutorials and walkthroughs
to help onboard new users or expanding an under-documented section such as
Hive interoperability."*

The applications are open as of tomorrow (June 9th) and you can learn more
about the process of applying to GSoD in [2,3].

Let me know if you have any other questions!

Thanks,

Marta

[1]
https://developers.google.com/season-of-docs/docs/tech-writer-application-hints#project_proposal

[2] https://developers.google.com/season-of-docs/docs/timeline
[3]
https://developers.google.com/season-of-docs/docs/tech-writer-application-hints

On Mon, Jun 8, 2020 at 9:27 AM Aman Singal  wrote:

> Respected Sir,
>
> I am Aman Singal, I am a 2nd Year undergraduate student. I really would
> like to contribute in your esteemed organization in writing documentation.
> I have read and understood the requirement of the project "Extend the Table
> API & SQL Documentation"
>
> I request you to please share the details and guide me the path to get
> started.
>
> Yours Sincerely
> Aman Singal
>

Google Season of Docs Contribution

[Aman Singal]

Respected Sir,

I am Aman Singal, I am a 2nd Year undergraduate student. I really would
like to contribute in your esteemed organization in writing documentation.
I have read and understood the requirement of the project "Extend the Table
API & SQL Documentation"

I request you to please share the details and guide me the path to get
started.

Yours Sincerely
Aman Singal

Re: Contribution

[Caizhi Weng]

Hi Manish!

Glad to hear that you're willing to contribute! All of our current tasks
are on the JIRA issue list (
https://issues.apache.org/jira/projects/FLINK/issues). Feel free to pick
what you like and start discussing and coding.

Manish G  于2020年4月23日周四 下午7:35写道：

> Hi All,
>
> I have just joined the dev list.
>
> I would like to contribute in my capacity as a programmer.
>
> Please let me know if I can be helpful to any of the current task.
>
> Manish
>

Contribution

[Manish G]

Hi All,

I have just joined the dev list.

I would like to contribute in my capacity as a programmer.

Please let me know if I can be helpful to any of the current task.

Manish

[jira] [Created] (FLINK-15765) Contributing section in README should point to contribution guide

[Chesnay Schepler (Jira)]

Chesnay Schepler created FLINK-15765:


 Summary: Contributing section in README should point to 
contribution guide
 Key: FLINK-15765
 URL: https://issues.apache.org/jira/browse/FLINK-15765
 Project: Flink
  Issue Type: Improvement
  Components: Stateful Functions
Affects Versions: statefun-1.1
Reporter: Chesnay Schepler


The "Contributing" section in the statefun readme encourages people to 
contribute, but does not provide adequate guidance on how to to so (Where to 
file issues, how to provide PRs, etc. )



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Stateful Functions - Contribution Details

[Stephan Ewen]

 That's great!
Thanks, Robert

On Tue, Dec 3, 2019 at 2:31 PM Robert Metzger  wrote:

> No concerns were raised. I created a repository:
> https://github.com/apache/flink-statefun
>
> Looking forward to the first PRs :)
>
> On Wed, Nov 20, 2019 at 2:43 AM tison  wrote:
>
> > Thanks for your summary Stephan. All entries make sense to me. Let's play
> > statefun :-)
> >
> > Best,
> > tison.
> >
> >
> > Stephan Ewen  于2019年11月20日周三 上午12:53写道：
> >
> > > I am also fine with skipping a FLIP, if no one objects.
> > >
> > > The discussion seemed rather converged (or stalled). There was a
> concern
> > > about the name, but in the absence of another candidate for the name, I
> > > would go ahead with the current one.
> > > For the other aspects, we seem to have converged in the discussion.
> > >
> > > Summary
> > >   - Repository name: "flink-statefun"
> > >   - Maven modules:
> > >  - group id: org.apache.flink
> > >  -  artifact ids: "statefun-*".
> > >  - Java package name: org.apache.flink.statefun.*
> > >  - Reuse the dev and user mailing lists of Flink
> > >  - Flink JIRA, with dedicated component
> > >
> > > Maybe one more point, which might have been implicit, but let me state
> it
> > > here explicitly:
> > >   - Because this is a regular part of the Flink project, common
> processes
> > > (like PRs, reviews, etc.) should be the same unless we find a reason to
> > > diverge.
> > >   - We could simplify the PR template (omit the flink-core specific
> > > checklist for serializers, public API, etc.)
> > >
> > > Please raise concerns soon, otherwise we would go ahead with this
> > proposal
> > > in a few days.
> > >
> > > Best,
> > > Stephan
> > >
> > >
> > > On Tue, Nov 19, 2019 at 3:44 PM Igal Shilman 
> wrote:
> > >
> > > > Hi Robert,
> > > > Your proposal skipping FLIP and the vote sounds reasonable to me.
> > > >
> > > > The project is currently built (with tests, shading, spotbugs etc')
> in
> > > > around 2-3 minutes, but since it will reside in its own repository,
> it
> > > will
> > > > not affect Flink
> > > > build time.
> > > >
> > > > Thanks,
> > > > Igal
> > > >
> > > > On Tue, Nov 19, 2019 at 3:36 PM Robert Metzger 
> > > > wrote:
> > > >
> > > > > +1 on what has been decided so far in this thread (including using
> > the
> > > > same
> > > > > ML, and sticking to the statefun name).
> > > > >
> > > > > I'm not 100% sure if we need a FLIP for this, as we have VOTEd
> > already
> > > > with
> > > > > a 2/3 majority on accepting this contribution, and there are no
> > changes
> > > > to
> > > > > the Flink codebase, or user-facing APIs. I would be fine adding
> this
> > > > > without a FLIP.
> > > > >
> > > > > Is this contribution going to add substantial additional build time
> > > > > (especially tests)?
> > > > >
> > > > >
> > > > > On Tue, Nov 12, 2019 at 10:56 AM Stephan Ewen 
> > > wrote:
> > > > >
> > > > > > As mentioned before, the name was mainly chosen to resonate with
> > > > > developers
> > > > > > form a different background (applications / services) and we
> > checked
> > > it
> > > > > > with some users. Unrelated to Flink and Stream Processing, it
> > seemed
> > > to
> > > > > > describe the target use case pretty well.
> > > > > >
> > > > > > What would you use as a name instead?
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Nov 12, 2019 at 10:10 AM Chesnay Schepler <
> > > ches...@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > I'm concerned both about the abbreviation and full name.
> > > > > > >
> > > > > > > a) It's not distinguishing enough from existing APIs,
> > specifically
> > > > the
> > > > > > > Streaming API, which already features stateful functions.
> > > > > > > b) It doesn't descr

Re: [DISCUSS] Stateful Functions - Contribution Details

[Robert Metzger]

No concerns were raised. I created a repository:
https://github.com/apache/flink-statefun

Looking forward to the first PRs :)

On Wed, Nov 20, 2019 at 2:43 AM tison  wrote:

> Thanks for your summary Stephan. All entries make sense to me. Let's play
> statefun :-)
>
> Best,
> tison.
>
>
> Stephan Ewen  于2019年11月20日周三 上午12:53写道：
>
> > I am also fine with skipping a FLIP, if no one objects.
> >
> > The discussion seemed rather converged (or stalled). There was a concern
> > about the name, but in the absence of another candidate for the name, I
> > would go ahead with the current one.
> > For the other aspects, we seem to have converged in the discussion.
> >
> > Summary
> >   - Repository name: "flink-statefun"
> >   - Maven modules:
> >  - group id: org.apache.flink
> >  -  artifact ids: "statefun-*".
> >  - Java package name: org.apache.flink.statefun.*
> >  - Reuse the dev and user mailing lists of Flink
> >  - Flink JIRA, with dedicated component
> >
> > Maybe one more point, which might have been implicit, but let me state it
> > here explicitly:
> >   - Because this is a regular part of the Flink project, common processes
> > (like PRs, reviews, etc.) should be the same unless we find a reason to
> > diverge.
> >   - We could simplify the PR template (omit the flink-core specific
> > checklist for serializers, public API, etc.)
> >
> > Please raise concerns soon, otherwise we would go ahead with this
> proposal
> > in a few days.
> >
> > Best,
> > Stephan
> >
> >
> > On Tue, Nov 19, 2019 at 3:44 PM Igal Shilman  wrote:
> >
> > > Hi Robert,
> > > Your proposal skipping FLIP and the vote sounds reasonable to me.
> > >
> > > The project is currently built (with tests, shading, spotbugs etc') in
> > > around 2-3 minutes, but since it will reside in its own repository, it
> > will
> > > not affect Flink
> > > build time.
> > >
> > > Thanks,
> > > Igal
> > >
> > > On Tue, Nov 19, 2019 at 3:36 PM Robert Metzger 
> > > wrote:
> > >
> > > > +1 on what has been decided so far in this thread (including using
> the
> > > same
> > > > ML, and sticking to the statefun name).
> > > >
> > > > I'm not 100% sure if we need a FLIP for this, as we have VOTEd
> already
> > > with
> > > > a 2/3 majority on accepting this contribution, and there are no
> changes
> > > to
> > > > the Flink codebase, or user-facing APIs. I would be fine adding this
> > > > without a FLIP.
> > > >
> > > > Is this contribution going to add substantial additional build time
> > > > (especially tests)?
> > > >
> > > >
> > > > On Tue, Nov 12, 2019 at 10:56 AM Stephan Ewen 
> > wrote:
> > > >
> > > > > As mentioned before, the name was mainly chosen to resonate with
> > > > developers
> > > > > form a different background (applications / services) and we
> checked
> > it
> > > > > with some users. Unrelated to Flink and Stream Processing, it
> seemed
> > to
> > > > > describe the target use case pretty well.
> > > > >
> > > > > What would you use as a name instead?
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Nov 12, 2019 at 10:10 AM Chesnay Schepler <
> > ches...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > I'm concerned both about the abbreviation and full name.
> > > > > >
> > > > > > a) It's not distinguishing enough from existing APIs,
> specifically
> > > the
> > > > > > Streaming API, which already features stateful functions.
> > > > > > b) It doesn't describe use-cases that the existing APIs cannot
> > > satisfy.
> > > > > >
> > > > > > On 11/11/2019 15:28, Stephan Ewen wrote:
> > > > > > > Thanks, all for the discussion!
> > > > > > >
> > > > > > > About the name:
> > > > > > >
> > > > > > >- Like Igal mentioned, the name "Stateful Functions" and the
> > > > > > abbreviation
> > > > > > > "statefun" underwent some iterations and testing with a small
> > > sample
> > > > of
&

Re: [DISCUSS] Stateful Functions - Contribution Details

[tison]

Thanks for your summary Stephan. All entries make sense to me. Let's play
statefun :-)

Best,
tison.


Stephan Ewen  于2019年11月20日周三 上午12:53写道：

> I am also fine with skipping a FLIP, if no one objects.
>
> The discussion seemed rather converged (or stalled). There was a concern
> about the name, but in the absence of another candidate for the name, I
> would go ahead with the current one.
> For the other aspects, we seem to have converged in the discussion.
>
> Summary
>   - Repository name: "flink-statefun"
>   - Maven modules:
>  - group id: org.apache.flink
>  -  artifact ids: "statefun-*".
>  - Java package name: org.apache.flink.statefun.*
>  - Reuse the dev and user mailing lists of Flink
>  - Flink JIRA, with dedicated component
>
> Maybe one more point, which might have been implicit, but let me state it
> here explicitly:
>   - Because this is a regular part of the Flink project, common processes
> (like PRs, reviews, etc.) should be the same unless we find a reason to
> diverge.
>   - We could simplify the PR template (omit the flink-core specific
> checklist for serializers, public API, etc.)
>
> Please raise concerns soon, otherwise we would go ahead with this proposal
> in a few days.
>
> Best,
> Stephan
>
>
> On Tue, Nov 19, 2019 at 3:44 PM Igal Shilman  wrote:
>
> > Hi Robert,
> > Your proposal skipping FLIP and the vote sounds reasonable to me.
> >
> > The project is currently built (with tests, shading, spotbugs etc') in
> > around 2-3 minutes, but since it will reside in its own repository, it
> will
> > not affect Flink
> > build time.
> >
> > Thanks,
> > Igal
> >
> > On Tue, Nov 19, 2019 at 3:36 PM Robert Metzger 
> > wrote:
> >
> > > +1 on what has been decided so far in this thread (including using the
> > same
> > > ML, and sticking to the statefun name).
> > >
> > > I'm not 100% sure if we need a FLIP for this, as we have VOTEd already
> > with
> > > a 2/3 majority on accepting this contribution, and there are no changes
> > to
> > > the Flink codebase, or user-facing APIs. I would be fine adding this
> > > without a FLIP.
> > >
> > > Is this contribution going to add substantial additional build time
> > > (especially tests)?
> > >
> > >
> > > On Tue, Nov 12, 2019 at 10:56 AM Stephan Ewen 
> wrote:
> > >
> > > > As mentioned before, the name was mainly chosen to resonate with
> > > developers
> > > > form a different background (applications / services) and we checked
> it
> > > > with some users. Unrelated to Flink and Stream Processing, it seemed
> to
> > > > describe the target use case pretty well.
> > > >
> > > > What would you use as a name instead?
> > > >
> > > >
> > > >
> > > > On Tue, Nov 12, 2019 at 10:10 AM Chesnay Schepler <
> ches...@apache.org>
> > > > wrote:
> > > >
> > > > > I'm concerned both about the abbreviation and full name.
> > > > >
> > > > > a) It's not distinguishing enough from existing APIs, specifically
> > the
> > > > > Streaming API, which already features stateful functions.
> > > > > b) It doesn't describe use-cases that the existing APIs cannot
> > satisfy.
> > > > >
> > > > > On 11/11/2019 15:28, Stephan Ewen wrote:
> > > > > > Thanks, all for the discussion!
> > > > > >
> > > > > > About the name:
> > > > > >
> > > > > >- Like Igal mentioned, the name "Stateful Functions" and the
> > > > > abbreviation
> > > > > > "statefun" underwent some iterations and testing with a small
> > sample
> > > of
> > > > > > developers from a few companies.
> > > > > >  If anyone has an amazing suggestion for another name, please
> > > > share.
> > > > > > Would be great to also test it with a small sample of developers
> > > from a
> > > > > few
> > > > > > companies, just to make sure we have at least a bit of outside
> > > > feedback.
> > > > > >
> > > > > >- fun vs. fn vs. func: I think these are more or less
> > equivalent,
> > > > > there
> > > > > > are examples of each one in some language. Working with the code
> > over
> > > > the
> >

Re: [DISCUSS] Stateful Functions - Contribution Details

[Stephan Ewen]

I am also fine with skipping a FLIP, if no one objects.

The discussion seemed rather converged (or stalled). There was a concern
about the name, but in the absence of another candidate for the name, I
would go ahead with the current one.
For the other aspects, we seem to have converged in the discussion.

Summary
  - Repository name: "flink-statefun"
  - Maven modules:
 - group id: org.apache.flink
 -  artifact ids: "statefun-*".
 - Java package name: org.apache.flink.statefun.*
 - Reuse the dev and user mailing lists of Flink
 - Flink JIRA, with dedicated component

Maybe one more point, which might have been implicit, but let me state it
here explicitly:
  - Because this is a regular part of the Flink project, common processes
(like PRs, reviews, etc.) should be the same unless we find a reason to
diverge.
  - We could simplify the PR template (omit the flink-core specific
checklist for serializers, public API, etc.)

Please raise concerns soon, otherwise we would go ahead with this proposal
in a few days.

Best,
Stephan


On Tue, Nov 19, 2019 at 3:44 PM Igal Shilman  wrote:

> Hi Robert,
> Your proposal skipping FLIP and the vote sounds reasonable to me.
>
> The project is currently built (with tests, shading, spotbugs etc') in
> around 2-3 minutes, but since it will reside in its own repository, it will
> not affect Flink
> build time.
>
> Thanks,
> Igal
>
> On Tue, Nov 19, 2019 at 3:36 PM Robert Metzger 
> wrote:
>
> > +1 on what has been decided so far in this thread (including using the
> same
> > ML, and sticking to the statefun name).
> >
> > I'm not 100% sure if we need a FLIP for this, as we have VOTEd already
> with
> > a 2/3 majority on accepting this contribution, and there are no changes
> to
> > the Flink codebase, or user-facing APIs. I would be fine adding this
> > without a FLIP.
> >
> > Is this contribution going to add substantial additional build time
> > (especially tests)?
> >
> >
> > On Tue, Nov 12, 2019 at 10:56 AM Stephan Ewen  wrote:
> >
> > > As mentioned before, the name was mainly chosen to resonate with
> > developers
> > > form a different background (applications / services) and we checked it
> > > with some users. Unrelated to Flink and Stream Processing, it seemed to
> > > describe the target use case pretty well.
> > >
> > > What would you use as a name instead?
> > >
> > >
> > >
> > > On Tue, Nov 12, 2019 at 10:10 AM Chesnay Schepler 
> > > wrote:
> > >
> > > > I'm concerned both about the abbreviation and full name.
> > > >
> > > > a) It's not distinguishing enough from existing APIs, specifically
> the
> > > > Streaming API, which already features stateful functions.
> > > > b) It doesn't describe use-cases that the existing APIs cannot
> satisfy.
> > > >
> > > > On 11/11/2019 15:28, Stephan Ewen wrote:
> > > > > Thanks, all for the discussion!
> > > > >
> > > > > About the name:
> > > > >
> > > > >- Like Igal mentioned, the name "Stateful Functions" and the
> > > > abbreviation
> > > > > "statefun" underwent some iterations and testing with a small
> sample
> > of
> > > > > developers from a few companies.
> > > > >  If anyone has an amazing suggestion for another name, please
> > > share.
> > > > > Would be great to also test it with a small sample of developers
> > from a
> > > > few
> > > > > companies, just to make sure we have at least a bit of outside
> > > feedback.
> > > > >
> > > > >- fun vs. fn vs. func: I think these are more or less
> equivalent,
> > > > there
> > > > > are examples of each one in some language. Working with the code
> over
> > > the
> > > > > last months, we found "statefun" to be somehow appealing.
> > > > >  Maybe as a datapoint, Beam uses "DoFn" but pronounces it
> > > "doo-fun".
> > > > So,
> > > > > why not go with "fun" directly?
> > > > >
> > > > > About mailing lists:
> > > > >
> > > > >- There are pros and cons for separating the mailing lists or
> not
> > to
> > > > do
> > > > > that.
> > > > >- Having the same mailing lists gives synergies around questions
> > for
> > > > > operating the system.
> > > &g

Re: [DISCUSS] Stateful Functions - Contribution Details

[Igal Shilman]

Hi Robert,
Your proposal skipping FLIP and the vote sounds reasonable to me.

The project is currently built (with tests, shading, spotbugs etc') in
around 2-3 minutes, but since it will reside in its own repository, it will
not affect Flink
build time.

Thanks,
Igal

On Tue, Nov 19, 2019 at 3:36 PM Robert Metzger  wrote:

> +1 on what has been decided so far in this thread (including using the same
> ML, and sticking to the statefun name).
>
> I'm not 100% sure if we need a FLIP for this, as we have VOTEd already with
> a 2/3 majority on accepting this contribution, and there are no changes to
> the Flink codebase, or user-facing APIs. I would be fine adding this
> without a FLIP.
>
> Is this contribution going to add substantial additional build time
> (especially tests)?
>
>
> On Tue, Nov 12, 2019 at 10:56 AM Stephan Ewen  wrote:
>
> > As mentioned before, the name was mainly chosen to resonate with
> developers
> > form a different background (applications / services) and we checked it
> > with some users. Unrelated to Flink and Stream Processing, it seemed to
> > describe the target use case pretty well.
> >
> > What would you use as a name instead?
> >
> >
> >
> > On Tue, Nov 12, 2019 at 10:10 AM Chesnay Schepler 
> > wrote:
> >
> > > I'm concerned both about the abbreviation and full name.
> > >
> > > a) It's not distinguishing enough from existing APIs, specifically the
> > > Streaming API, which already features stateful functions.
> > > b) It doesn't describe use-cases that the existing APIs cannot satisfy.
> > >
> > > On 11/11/2019 15:28, Stephan Ewen wrote:
> > > > Thanks, all for the discussion!
> > > >
> > > > About the name:
> > > >
> > > >- Like Igal mentioned, the name "Stateful Functions" and the
> > > abbreviation
> > > > "statefun" underwent some iterations and testing with a small sample
> of
> > > > developers from a few companies.
> > > >  If anyone has an amazing suggestion for another name, please
> > share.
> > > > Would be great to also test it with a small sample of developers
> from a
> > > few
> > > > companies, just to make sure we have at least a bit of outside
> > feedback.
> > > >
> > > >- fun vs. fn vs. func: I think these are more or less equivalent,
> > > there
> > > > are examples of each one in some language. Working with the code over
> > the
> > > > last months, we found "statefun" to be somehow appealing.
> > > >  Maybe as a datapoint, Beam uses "DoFn" but pronounces it
> > "doo-fun".
> > > So,
> > > > why not go with "fun" directly?
> > > >
> > > > About mailing lists:
> > > >
> > > >- There are pros and cons for separating the mailing lists or not
> to
> > > do
> > > > that.
> > > >- Having the same mailing lists gives synergies around questions
> for
> > > > operating the system.
> > > >- Having the same mailing lists can create confusion. For example,
> > > > statefun uses a simpler, more restrictive, easier to understand
> > > > serialization scheme. Answers coming from serialization in Flink core
> > can
> > > > easily be confusing there.
> > > >- Having the same mailing lists can be overwhelming for developers
> > > that
> > > > are new and only interested in that particular angle.
> > > >- Having a different dev mailing list makes only sense if we use a
> > > > different Jira project, because FLINK-X issue creation is linked
> to
> > > the
> > > > mailing list.
> > > >
> > > >=> I think it is fine to start with the same mailing list and
> > observe
> > > > first. If we find it problematic, we can separate the mailing lists.
> > > >
> > > > About the repository name:
> > > >
> > > >- The project is still called "Stateful Functions", but it is a
> > mouth
> > > > full, so it would be nice to have something more concise for the repo
> > > name,
> > > > hence the suggestion for "statefun".
> > > >- @Chesnay - Are you concerned about the project name (Stateful
> > > > Functions) or the abbreviation (statefun) ?
> > > >
> > > > Best,
> > > > Stephan
> > > >
> > > 

Re: [DISCUSS] Stateful Functions - Contribution Details

[Robert Metzger]

+1 on what has been decided so far in this thread (including using the same
ML, and sticking to the statefun name).

I'm not 100% sure if we need a FLIP for this, as we have VOTEd already with
a 2/3 majority on accepting this contribution, and there are no changes to
the Flink codebase, or user-facing APIs. I would be fine adding this
without a FLIP.

Is this contribution going to add substantial additional build time
(especially tests)?


On Tue, Nov 12, 2019 at 10:56 AM Stephan Ewen  wrote:

> As mentioned before, the name was mainly chosen to resonate with developers
> form a different background (applications / services) and we checked it
> with some users. Unrelated to Flink and Stream Processing, it seemed to
> describe the target use case pretty well.
>
> What would you use as a name instead?
>
>
>
> On Tue, Nov 12, 2019 at 10:10 AM Chesnay Schepler 
> wrote:
>
> > I'm concerned both about the abbreviation and full name.
> >
> > a) It's not distinguishing enough from existing APIs, specifically the
> > Streaming API, which already features stateful functions.
> > b) It doesn't describe use-cases that the existing APIs cannot satisfy.
> >
> > On 11/11/2019 15:28, Stephan Ewen wrote:
> > > Thanks, all for the discussion!
> > >
> > > About the name:
> > >
> > >- Like Igal mentioned, the name "Stateful Functions" and the
> > abbreviation
> > > "statefun" underwent some iterations and testing with a small sample of
> > > developers from a few companies.
> > >  If anyone has an amazing suggestion for another name, please
> share.
> > > Would be great to also test it with a small sample of developers from a
> > few
> > > companies, just to make sure we have at least a bit of outside
> feedback.
> > >
> > >- fun vs. fn vs. func: I think these are more or less equivalent,
> > there
> > > are examples of each one in some language. Working with the code over
> the
> > > last months, we found "statefun" to be somehow appealing.
> > >  Maybe as a datapoint, Beam uses "DoFn" but pronounces it
> "doo-fun".
> > So,
> > > why not go with "fun" directly?
> > >
> > > About mailing lists:
> > >
> > >- There are pros and cons for separating the mailing lists or not to
> > do
> > > that.
> > >- Having the same mailing lists gives synergies around questions for
> > > operating the system.
> > >- Having the same mailing lists can create confusion. For example,
> > > statefun uses a simpler, more restrictive, easier to understand
> > > serialization scheme. Answers coming from serialization in Flink core
> can
> > > easily be confusing there.
> > >- Having the same mailing lists can be overwhelming for developers
> > that
> > > are new and only interested in that particular angle.
> > >- Having a different dev mailing list makes only sense if we use a
> > > different Jira project, because FLINK-X issue creation is linked to
> > the
> > > mailing list.
> > >
> > >=> I think it is fine to start with the same mailing list and
> observe
> > > first. If we find it problematic, we can separate the mailing lists.
> > >
> > > About the repository name:
> > >
> > >- The project is still called "Stateful Functions", but it is a
> mouth
> > > full, so it would be nice to have something more concise for the repo
> > name,
> > > hence the suggestion for "statefun".
> > >- @Chesnay - Are you concerned about the project name (Stateful
> > > Functions) or the abbreviation (statefun) ?
> > >
> > > Best,
> > > Stephan
> > >
> > >
> > >
> > >
> > > On Mon, Nov 11, 2019 at 6:21 AM tison  wrote:
> > >
> > >> I second Chesnay's opinions, which I'd like to pick up is that I
> highly
> > >> recommend
> > >> reuse existing mailing lists. We can always build a separated list
> when
> > the
> > >> specific
> > >> community grows, but it is hard to do it in the contract direction.
> > >>
> > >> I don't stick to the name but vote my coin to "statefun". Playing with
> > >> statefun will be
> > >> fun, I think :-) (Generally, Erlang uses "fun", Go uses "func" and
> Rust
> > >> uses "fn", I
> > >> don't find a strong reason that "

Re: [DISCUSS] Stateful Functions - Contribution Details

[Stephan Ewen]

%2BAMoVN4VqGU_Hykb1N7J8ng%40mail.gmail.com%3E
> >>>> 1) There is no relevant post, this is the name that is currently used
> >>> both
> >>>> for the website and internally.
> >>>> The name is not the original name, and it evolved out of internal
> >>>> discussions and a/b-testing with few early users, this name
> >>>> was able to "position" the project at the correct place better than
> >>> others.
> >>>> If more people would feel unconvinced, or you would strongly oppose to
> >>> it,
> >>>> then we can create a separate discussion thread.
> >>>>
> >>>> 4)  Ok, I will change the proposal to option (b).
> >>>>
> >>>> Kind regards,
> >>>> Igal.
> >>>>
> >>>> On Thu, Nov 7, 2019 at 5:29 PM Chesnay Schepler 
> >>>> wrote:
> >>>>
> >>>>> [1] Does not directly link to the voting thread.
> >>>>>
> >>>>> 1) I skimmed all 3 threads about the stateful functions proposal and
> >>>>> could not find a rational for the repository name, I'd appreciate a
> >>>>> direct link to the relevant post.
> >>>>>
> >>>>> 2.1) +1 as we use o.a.f also for flink-shaded
> >>>>>
> >>>>> 3) +1 as it follows the existing package conventions for libraries.
> >>>>>
> >>>>> 4) b; I see no reason why we would isolate mailing lists when we
> >>> haven't
> >>>>> done so for the myriad of other components that are largely
> >> independent
> >>>>> from each other (like SQL).
> >>>>> There are some practical issues here with having a separate dev ML,
> >> for
> >>>>> example where to send FLIPs or release threads and ensuring they
> >> reach
> >>> a
> >>>>> large enough audience, which a dedicated ML would likely hinder.
> >>>>> I'm currently also assuming that builds/commits also go to the
> >> general
> >>>>> flink MLs, making it even weirder if just dev were spliced out.
> >>>>>
> >>>>> 5) separate component, like "API / Statefun"
> >>>>>
> >>>>> Personally I'm not sold on the "statefun" name, has this been a
> >>>>> discussion item in one of the other threads?
> >>>>>
> >>>>> On 07/11/2019 17:10, Igal Shilman wrote:
> >>>>>> Hello everyone!
> >>>>>>
> >>>>>> Following the successful vote to accept Stateful Functions into
> >> Flink
> >>>>> [1],
> >>>>>> I would like to start a discussion regarding the technical aspects
> >> of
> >>>> the
> >>>>>> contribution.
> >>>>>> Once the discussion will finalize I will summarize the results
> >> into a
> >>>>> FLIP
> >>>>>> and bring it up to a vote.
> >>>>>>
> >>>>>> 1) External repository name - Following the discussion conclusion
> >> of
> >>>> [2]
> >>>>> we
> >>>>>> need a name for an external repository.
> >>>>>>
> >>>>>> proposal: flink-statefun
> >>>>>> rational: discussed in the other thread.
> >>>>>>
> >>>>>> 2) Maven modules proposal:
> >>>>>> 2.1) group id: org.apache.flink
> >>>>>> 2.2) artifact ids: replace "stateful-functions-*" with
> >> "statefun-*".
> >>>>>> 3) Java package name: org.apache.flink.statefun.*
> >>>>>>
> >>>>>> 4) Mailing list - should we reuse the existing mailing list or
> >> have a
> >>>>>> dedicated mailing list for stateful functions?
> >>>>>> options:
> >>>>>> a) Completely separate mailing list for statefun developers and
> >>> users (
> >>>>>> dev-state...@flink.apache.org and user-state...@flink.apache.org)
> >>>>>> b) Reuse the dev and user mailing lists of Flink
> >>>>>> c) Reuse Flink's user mailing list, but create a dedicated mailing
> >>> list
> >>>>> for
> >>>>>> development.
> >>>>>> d) Have a separate single list for developers and users of
> >> statefun (
> >>>>>> state...@flink.apache.org)
> >>>>>>
> >>>>>> proposal: (c) separate dev list: "dev-state...@flink.apache.org"
> >> and
> >>>>> reuse
> >>>>>> the Flink user mailing list.
> >>>>>> rational: It is very likely that stateful functions users would
> >>>> encounter
> >>>>>> the same operational issues as regular Flink users, therefore
> >>>>>> it might be beneficial to reuse the Flink user list.
> >>>>>>
> >>>>>> 5) separate JIRA project or just component / tag?
> >>>>>> proposal: use separate component for statefun.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Igal
> >>>>>>
> >>>>>> [1]
> >> http://mail-archives.apache.org/mod_mbox/flink-dev/201911.mbox/browser
> >>>>>> [2]
> >>>>>>
> >>
> http://mail-archives.apache.org/mod_mbox/flink-dev/201910.mbox/%3CCANC1h_vRPWs1PnRPuDe602zhX=3j713fanz0wn2dw9pzf_t...@mail.gmail.com%3E
> >>>>>
> >>>
> >>> --
> >>> Xuefu Zhang
> >>>
> >>> "In Honey We Trust!"
> >>>
>
>

Re: [DISCUSS] Stateful Functions - Contribution Details

[Chesnay Schepler]

 like "API / Statefun"

Personally I'm not sold on the "statefun" name, has this been a
discussion item in one of the other threads?

On 07/11/2019 17:10, Igal Shilman wrote:

Hello everyone!

Following the successful vote to accept Stateful Functions into

Flink

[1],

I would like to start a discussion regarding the technical aspects

of

the

contribution.
Once the discussion will finalize I will summarize the results

into a

FLIP

and bring it up to a vote.

1) External repository name - Following the discussion conclusion

of

[2]

we

need a name for an external repository.

proposal: flink-statefun
rational: discussed in the other thread.

2) Maven modules proposal:
2.1) group id: org.apache.flink
2.2) artifact ids: replace "stateful-functions-*" with

"statefun-*".

3) Java package name: org.apache.flink.statefun.*

4) Mailing list - should we reuse the existing mailing list or

have a

dedicated mailing list for stateful functions?
options:
a) Completely separate mailing list for statefun developers and

users (

dev-state...@flink.apache.org and user-state...@flink.apache.org)
b) Reuse the dev and user mailing lists of Flink
c) Reuse Flink's user mailing list, but create a dedicated mailing

list

for

development.
d) Have a separate single list for developers and users of

statefun (

state...@flink.apache.org)

proposal: (c) separate dev list: "dev-state...@flink.apache.org"

and

reuse

the Flink user mailing list.
rational: It is very likely that stateful functions users would

encounter

the same operational issues as regular Flink users, therefore
it might be beneficial to reuse the Flink user list.

5) separate JIRA project or just component / tag?
proposal: use separate component for statefun.

Thanks,
Igal

[1]

http://mail-archives.apache.org/mod_mbox/flink-dev/201911.mbox/browser

[2]


http://mail-archives.apache.org/mod_mbox/flink-dev/201910.mbox/%3CCANC1h_vRPWs1PnRPuDe602zhX=3j713fanz0wn2dw9pzf_t...@mail.gmail.com%3E




--
Xuefu Zhang

"In Honey We Trust!"

Re: [DISCUSS] Stateful Functions - Contribution Details

[Stephan Ewen]

for the myriad of other components that are largely
> independent
> > > > from each other (like SQL).
> > > > There are some practical issues here with having a separate dev ML,
> for
> > > > example where to send FLIPs or release threads and ensuring they
> reach
> > a
> > > > large enough audience, which a dedicated ML would likely hinder.
> > > > I'm currently also assuming that builds/commits also go to the
> general
> > > > flink MLs, making it even weirder if just dev were spliced out.
> > > >
> > > > 5) separate component, like "API / Statefun"
> > > >
> > > > Personally I'm not sold on the "statefun" name, has this been a
> > > > discussion item in one of the other threads?
> > > >
> > > > On 07/11/2019 17:10, Igal Shilman wrote:
> > > > > Hello everyone!
> > > > >
> > > > > Following the successful vote to accept Stateful Functions into
> Flink
> > > > [1],
> > > > > I would like to start a discussion regarding the technical aspects
> of
> > > the
> > > > > contribution.
> > > > > Once the discussion will finalize I will summarize the results
> into a
> > > > FLIP
> > > > > and bring it up to a vote.
> > > > >
> > > > > 1) External repository name - Following the discussion conclusion
> of
> > > [2]
> > > > we
> > > > > need a name for an external repository.
> > > > >
> > > > > proposal: flink-statefun
> > > > > rational: discussed in the other thread.
> > > > >
> > > > > 2) Maven modules proposal:
> > > > > 2.1) group id: org.apache.flink
> > > > > 2.2) artifact ids: replace "stateful-functions-*" with
> "statefun-*".
> > > > >
> > > > > 3) Java package name: org.apache.flink.statefun.*
> > > > >
> > > > > 4) Mailing list - should we reuse the existing mailing list or
> have a
> > > > > dedicated mailing list for stateful functions?
> > > > > options:
> > > > > a) Completely separate mailing list for statefun developers and
> > users (
> > > > > dev-state...@flink.apache.org and user-state...@flink.apache.org)
> > > > > b) Reuse the dev and user mailing lists of Flink
> > > > > c) Reuse Flink's user mailing list, but create a dedicated mailing
> > list
> > > > for
> > > > > development.
> > > > > d) Have a separate single list for developers and users of
> statefun (
> > > > > state...@flink.apache.org)
> > > > >
> > > > > proposal: (c) separate dev list: "dev-state...@flink.apache.org"
> and
> > > > reuse
> > > > > the Flink user mailing list.
> > > > > rational: It is very likely that stateful functions users would
> > > encounter
> > > > > the same operational issues as regular Flink users, therefore
> > > > > it might be beneficial to reuse the Flink user list.
> > > > >
> > > > > 5) separate JIRA project or just component / tag?
> > > > > proposal: use separate component for statefun.
> > > > >
> > > > > Thanks,
> > > > > Igal
> > > > >
> > > > > [1]
> > > >
> http://mail-archives.apache.org/mod_mbox/flink-dev/201911.mbox/browser
> > > > > [2]
> > > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/flink-dev/201910.mbox/%3CCANC1h_vRPWs1PnRPuDe602zhX=3j713fanz0wn2dw9pzf_t...@mail.gmail.com%3E
> > > > >
> > > >
> > > >
> > >
> >
> >
> > --
> > Xuefu Zhang
> >
> > "In Honey We Trust!"
> >
>

Re: [DISCUSS] Stateful Functions - Contribution Details

[tison]

I second Chesnay's opinions, which I'd like to pick up is that I highly
recommend
reuse existing mailing lists. We can always build a separated list when the
specific
community grows, but it is hard to do it in the contract direction.

I don't stick to the name but vote my coin to "statefun". Playing with
statefun will be
fun, I think :-) (Generally, Erlang uses "fun", Go uses "func" and Rust
uses "fn", I
don't find a strong reason that "func" is an objective better choice

Best,
tison.


Xuefu Z  于2019年11月9日周六 上午4:16写道：

> Regarding the package name, etc:
>
> statefun certainly sounds more interesting, but it's confusing in my
> opinion and doesn't reflect its true nature. A letter "c" at the end may
> helps as "func" is more used as a short for "function" in CS.
>
> Thanks,
> Xuefu
>
> On Fri, Nov 8, 2019 at 3:52 AM Igal Shilman  wrote:
>
> > Hi Chesnay,
> >
> > The correct link for [1] is:
> >
> >
> http://mail-archives.apache.org/mod_mbox/flink-dev/201911.mbox/%3CCANC1h_vicBWQSGws6Q%2BTXJXde0K%2BAMoVN4VqGU_Hykb1N7J8ng%40mail.gmail.com%3E
> >
> > 1) There is no relevant post, this is the name that is currently used
> both
> > for the website and internally.
> > The name is not the original name, and it evolved out of internal
> > discussions and a/b-testing with few early users, this name
> > was able to "position" the project at the correct place better than
> others.
> > If more people would feel unconvinced, or you would strongly oppose to
> it,
> > then we can create a separate discussion thread.
> >
> > 4)  Ok, I will change the proposal to option (b).
> >
> > Kind regards,
> > Igal.
> >
> > On Thu, Nov 7, 2019 at 5:29 PM Chesnay Schepler 
> > wrote:
> >
> > > [1] Does not directly link to the voting thread.
> > >
> > > 1) I skimmed all 3 threads about the stateful functions proposal and
> > > could not find a rational for the repository name, I'd appreciate a
> > > direct link to the relevant post.
> > >
> > > 2.1) +1 as we use o.a.f also for flink-shaded
> > >
> > > 3) +1 as it follows the existing package conventions for libraries.
> > >
> > > 4) b; I see no reason why we would isolate mailing lists when we
> haven't
> > > done so for the myriad of other components that are largely independent
> > > from each other (like SQL).
> > > There are some practical issues here with having a separate dev ML, for
> > > example where to send FLIPs or release threads and ensuring they reach
> a
> > > large enough audience, which a dedicated ML would likely hinder.
> > > I'm currently also assuming that builds/commits also go to the general
> > > flink MLs, making it even weirder if just dev were spliced out.
> > >
> > > 5) separate component, like "API / Statefun"
> > >
> > > Personally I'm not sold on the "statefun" name, has this been a
> > > discussion item in one of the other threads?
> > >
> > > On 07/11/2019 17:10, Igal Shilman wrote:
> > > > Hello everyone!
> > > >
> > > > Following the successful vote to accept Stateful Functions into Flink
> > > [1],
> > > > I would like to start a discussion regarding the technical aspects of
> > the
> > > > contribution.
> > > > Once the discussion will finalize I will summarize the results into a
> > > FLIP
> > > > and bring it up to a vote.
> > > >
> > > > 1) External repository name - Following the discussion conclusion of
> > [2]
> > > we
> > > > need a name for an external repository.
> > > >
> > > > proposal: flink-statefun
> > > > rational: discussed in the other thread.
> > > >
> > > > 2) Maven modules proposal:
> > > > 2.1) group id: org.apache.flink
> > > > 2.2) artifact ids: replace "stateful-functions-*" with "statefun-*".
> > > >
> > > > 3) Java package name: org.apache.flink.statefun.*
> > > >
> > > > 4) Mailing list - should we reuse the existing mailing list or have a
> > > > dedicated mailing list for stateful functions?
> > > > options:
> > > > a) Completely separate mailing list for statefun developers and
> users (
> > > > dev-state...@flink.apache.org and user-state...@flink.apache.org)
> > > > b) Reuse the dev and user mailing lists of Flink
> > > > c)

Re: [DISCUSS] Stateful Functions - Contribution Details

[Xuefu Z]

Regarding the package name, etc:

statefun certainly sounds more interesting, but it's confusing in my
opinion and doesn't reflect its true nature. A letter "c" at the end may
helps as "func" is more used as a short for "function" in CS.

Thanks,
Xuefu

On Fri, Nov 8, 2019 at 3:52 AM Igal Shilman  wrote:

> Hi Chesnay,
>
> The correct link for [1] is:
>
> http://mail-archives.apache.org/mod_mbox/flink-dev/201911.mbox/%3CCANC1h_vicBWQSGws6Q%2BTXJXde0K%2BAMoVN4VqGU_Hykb1N7J8ng%40mail.gmail.com%3E
>
> 1) There is no relevant post, this is the name that is currently used both
> for the website and internally.
> The name is not the original name, and it evolved out of internal
> discussions and a/b-testing with few early users, this name
> was able to "position" the project at the correct place better than others.
> If more people would feel unconvinced, or you would strongly oppose to it,
> then we can create a separate discussion thread.
>
> 4)  Ok, I will change the proposal to option (b).
>
> Kind regards,
> Igal.
>
> On Thu, Nov 7, 2019 at 5:29 PM Chesnay Schepler 
> wrote:
>
> > [1] Does not directly link to the voting thread.
> >
> > 1) I skimmed all 3 threads about the stateful functions proposal and
> > could not find a rational for the repository name, I'd appreciate a
> > direct link to the relevant post.
> >
> > 2.1) +1 as we use o.a.f also for flink-shaded
> >
> > 3) +1 as it follows the existing package conventions for libraries.
> >
> > 4) b; I see no reason why we would isolate mailing lists when we haven't
> > done so for the myriad of other components that are largely independent
> > from each other (like SQL).
> > There are some practical issues here with having a separate dev ML, for
> > example where to send FLIPs or release threads and ensuring they reach a
> > large enough audience, which a dedicated ML would likely hinder.
> > I'm currently also assuming that builds/commits also go to the general
> > flink MLs, making it even weirder if just dev were spliced out.
> >
> > 5) separate component, like "API / Statefun"
> >
> > Personally I'm not sold on the "statefun" name, has this been a
> > discussion item in one of the other threads?
> >
> > On 07/11/2019 17:10, Igal Shilman wrote:
> > > Hello everyone!
> > >
> > > Following the successful vote to accept Stateful Functions into Flink
> > [1],
> > > I would like to start a discussion regarding the technical aspects of
> the
> > > contribution.
> > > Once the discussion will finalize I will summarize the results into a
> > FLIP
> > > and bring it up to a vote.
> > >
> > > 1) External repository name - Following the discussion conclusion of
> [2]
> > we
> > > need a name for an external repository.
> > >
> > > proposal: flink-statefun
> > > rational: discussed in the other thread.
> > >
> > > 2) Maven modules proposal:
> > > 2.1) group id: org.apache.flink
> > > 2.2) artifact ids: replace "stateful-functions-*" with "statefun-*".
> > >
> > > 3) Java package name: org.apache.flink.statefun.*
> > >
> > > 4) Mailing list - should we reuse the existing mailing list or have a
> > > dedicated mailing list for stateful functions?
> > > options:
> > > a) Completely separate mailing list for statefun developers and users (
> > > dev-state...@flink.apache.org and user-state...@flink.apache.org)
> > > b) Reuse the dev and user mailing lists of Flink
> > > c) Reuse Flink's user mailing list, but create a dedicated mailing list
> > for
> > > development.
> > > d) Have a separate single list for developers and users of statefun (
> > > state...@flink.apache.org)
> > >
> > > proposal: (c) separate dev list: "dev-state...@flink.apache.org" and
> > reuse
> > > the Flink user mailing list.
> > > rational: It is very likely that stateful functions users would
> encounter
> > > the same operational issues as regular Flink users, therefore
> > > it might be beneficial to reuse the Flink user list.
> > >
> > > 5) separate JIRA project or just component / tag?
> > > proposal: use separate component for statefun.
> > >
> > > Thanks,
> > > Igal
> > >
> > > [1]
> > http://mail-archives.apache.org/mod_mbox/flink-dev/201911.mbox/browser
> > > [2]
> > >
> >
> http://mail-archives.apache.org/mod_mbox/flink-dev/201910.mbox/%3CCANC1h_vRPWs1PnRPuDe602zhX=3j713fanz0wn2dw9pzf_t...@mail.gmail.com%3E
> > >
> >
> >
>


-- 
Xuefu Zhang

"In Honey We Trust!"

Re: [DISCUSS] Stateful Functions - Contribution Details

[Igal Shilman]

Hi Chesnay,

The correct link for [1] is:
http://mail-archives.apache.org/mod_mbox/flink-dev/201911.mbox/%3CCANC1h_vicBWQSGws6Q%2BTXJXde0K%2BAMoVN4VqGU_Hykb1N7J8ng%40mail.gmail.com%3E

1) There is no relevant post, this is the name that is currently used both
for the website and internally.
The name is not the original name, and it evolved out of internal
discussions and a/b-testing with few early users, this name
was able to "position" the project at the correct place better than others.
If more people would feel unconvinced, or you would strongly oppose to it,
then we can create a separate discussion thread.

4)  Ok, I will change the proposal to option (b).

Kind regards,
Igal.

On Thu, Nov 7, 2019 at 5:29 PM Chesnay Schepler  wrote:

> [1] Does not directly link to the voting thread.
>
> 1) I skimmed all 3 threads about the stateful functions proposal and
> could not find a rational for the repository name, I'd appreciate a
> direct link to the relevant post.
>
> 2.1) +1 as we use o.a.f also for flink-shaded
>
> 3) +1 as it follows the existing package conventions for libraries.
>
> 4) b; I see no reason why we would isolate mailing lists when we haven't
> done so for the myriad of other components that are largely independent
> from each other (like SQL).
> There are some practical issues here with having a separate dev ML, for
> example where to send FLIPs or release threads and ensuring they reach a
> large enough audience, which a dedicated ML would likely hinder.
> I'm currently also assuming that builds/commits also go to the general
> flink MLs, making it even weirder if just dev were spliced out.
>
> 5) separate component, like "API / Statefun"
>
> Personally I'm not sold on the "statefun" name, has this been a
> discussion item in one of the other threads?
>
> On 07/11/2019 17:10, Igal Shilman wrote:
> > Hello everyone!
> >
> > Following the successful vote to accept Stateful Functions into Flink
> [1],
> > I would like to start a discussion regarding the technical aspects of the
> > contribution.
> > Once the discussion will finalize I will summarize the results into a
> FLIP
> > and bring it up to a vote.
> >
> > 1) External repository name - Following the discussion conclusion of [2]
> we
> > need a name for an external repository.
> >
> > proposal: flink-statefun
> > rational: discussed in the other thread.
> >
> > 2) Maven modules proposal:
> > 2.1) group id: org.apache.flink
> > 2.2) artifact ids: replace "stateful-functions-*" with "statefun-*".
> >
> > 3) Java package name: org.apache.flink.statefun.*
> >
> > 4) Mailing list - should we reuse the existing mailing list or have a
> > dedicated mailing list for stateful functions?
> > options:
> > a) Completely separate mailing list for statefun developers and users (
> > dev-state...@flink.apache.org and user-state...@flink.apache.org)
> > b) Reuse the dev and user mailing lists of Flink
> > c) Reuse Flink's user mailing list, but create a dedicated mailing list
> for
> > development.
> > d) Have a separate single list for developers and users of statefun (
> > state...@flink.apache.org)
> >
> > proposal: (c) separate dev list: "dev-state...@flink.apache.org" and
> reuse
> > the Flink user mailing list.
> > rational: It is very likely that stateful functions users would encounter
> > the same operational issues as regular Flink users, therefore
> > it might be beneficial to reuse the Flink user list.
> >
> > 5) separate JIRA project or just component / tag?
> > proposal: use separate component for statefun.
> >
> > Thanks,
> > Igal
> >
> > [1]
> http://mail-archives.apache.org/mod_mbox/flink-dev/201911.mbox/browser
> > [2]
> >
> http://mail-archives.apache.org/mod_mbox/flink-dev/201910.mbox/%3CCANC1h_vRPWs1PnRPuDe602zhX=3j713fanz0wn2dw9pzf_t...@mail.gmail.com%3E
> >
>
>

[DISCUSS] Stateful Functions - Contribution Details

[Igal Shilman]

Hello everyone!

Following the successful vote to accept Stateful Functions into Flink [1],
I would like to start a discussion regarding the technical aspects of the
contribution.
Once the discussion will finalize I will summarize the results into a FLIP
and bring it up to a vote.

1) External repository name - Following the discussion conclusion of [2] we
need a name for an external repository.

proposal: flink-statefun
rational: discussed in the other thread.

2) Maven modules proposal:
2.1) group id: org.apache.flink
2.2) artifact ids: replace "stateful-functions-*" with "statefun-*".

3) Java package name: org.apache.flink.statefun.*

4) Mailing list - should we reuse the existing mailing list or have a
dedicated mailing list for stateful functions?
options:
a) Completely separate mailing list for statefun developers and users (
dev-state...@flink.apache.org and user-state...@flink.apache.org)
b) Reuse the dev and user mailing lists of Flink
c) Reuse Flink's user mailing list, but create a dedicated mailing list for
development.
d) Have a separate single list for developers and users of statefun (
state...@flink.apache.org)

proposal: (c) separate dev list: "dev-state...@flink.apache.org" and reuse
the Flink user mailing list.
rational: It is very likely that stateful functions users would encounter
the same operational issues as regular Flink users, therefore
it might be beneficial to reuse the Flink user list.

5) separate JIRA project or just component / tag?
proposal: use separate component for statefun.

Thanks,
Igal

[1]  http://mail-archives.apache.org/mod_mbox/flink-dev/201911.mbox/browser
[2]
http://mail-archives.apache.org/mod_mbox/flink-dev/201910.mbox/%3CCANC1h_vRPWs1PnRPuDe602zhX=3j713fanz0wn2dw9pzf_t...@mail.gmail.com%3E

Re: Start contribution

[Rishindra Kumar]

Hi Fabian,

I created pull request with the mentioned change. I also commented it on
the JIRA ticket.
https://github.com/apache/flink/pull/9468


-- 
*Maddila Rishindra Kumar*
*Software Engineer*
*Walmartlabs India*
*Contact No: +919967379528 | Alternate E-mail
ID: rishindra.madd...@walmartlabs.com *

Re: Start contribution

[Rishindra Kumar]

Hi Fabian,

Thank you. Sure, I will add comment in the issue with way of plan to fix
and test the bug.

-- 
*Maddila Rishindra Kumar*
*Software Engineer*
*Walmartlabs India*
*Contact No: +919967379528 | Alternate E-mail
ID: rishindra.madd...@walmartlabs.com *

Re: Start contribution

[Zili Chen]

Hi Rishindra,

It would be helpful to checkout [1] and [2].

For your specific case, it's nice that you speak out your
willing to contribute in dev list. It is hopeful other
Flink developers participant the discussion about the issue
and with consensus one of our committers could assign
the ticket to you so that you can provide your patch.

Best,
tison.

[1] https://flink.apache.org/contributing/how-to-contribute.html
[2] https://flink.apache.org/contributing/contribute-code.html




Rishindra Kumar  于2019年8月12日周一 下午11:07写道：

> Hi All,
>
> I subscribed to developer mailing list recently and want to start
> contributing with the following ticket.
> https://issues.apache.org/jira/browse/FLINK-13689
>
> Could you please let me know the procedure to start the discussion?
>
> --
> *Maddila Rishindra Kumar*
> *Software Engineer*
> *Walmartlabs India*
> *Contact No: +919967379528 | Alternate E-mail
> ID: rishindra.madd...@walmartlabs.com *
>

Start contribution

[Rishindra Kumar]

Hi All,

I subscribed to developer mailing list recently and want to start
contributing with the following ticket.
https://issues.apache.org/jira/browse/FLINK-13689

Could you please let me know the procedure to start the discussion?

-- 
*Maddila Rishindra Kumar*
*Software Engineer*
*Walmartlabs India*
*Contact No: +919967379528 | Alternate E-mail
ID: rishindra.madd...@walmartlabs.com *

[jira] [Created] (FLINK-12651) Add "Style Guide" to Documentation Contribution Guide

[Konstantin Knauf (JIRA)]

Konstantin Knauf created FLINK-12651:


 Summary: Add "Style Guide" to Documentation Contribution Guide
 Key: FLINK-12651
 URL: https://issues.apache.org/jira/browse/FLINK-12651
 Project: Flink
  Issue Type: Sub-task
Reporter: Konstantin Knauf


As part of this FLIP we would like to align on a few standards & guidelines for 
our documentation.

The current guide only focuses on the process and technical aspects:

https://flink.apache.org/contribute-documentation.html
https://flink.apache.org/how-to-contribute.html#contribute-documentation

We would like to expand on this for things like:
* when to use "note" or "attention" tags
* where the table of contents should be placed on a page
* when to split up pages
* how to address the user
* when to add code samples in Java & Scala
* ...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FLINK-12605) Describe new contribution process

[Robert Metzger (JIRA)]

Robert Metzger created FLINK-12605:
--

 Summary: Describe new contribution process
 Key: FLINK-12605
 URL: https://issues.apache.org/jira/browse/FLINK-12605
 Project: Flink
  Issue Type: Task
  Components: Project Website
Reporter: Robert Metzger
Assignee: Robert Metzger


The community has decided to change the contribution process to seek consensus 
in Jira first.

Update the website to reflect this change.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Starting contribution, choosing problem

[Александр]

Hello everyone! I would like to start contributing, but I have some
problems with it. There are small number of tasks with label
"newbie/starter" and so on. The most of tasks are just proposals, not a
task in general sense. Can anyone help with finding some bugs/improvements
with start level in flink? It's so hard to start do something. Thanks in
advance for your help.

Best regards,
Aleksandr Salatich

Re: contribution permission

[Fabian Hueske]

Hi Aleksandr,

Welcome to the Flink community!
I've given you contributor permissions for Jira.

Best, Fabian

Am Mo., 18. Feb. 2019 um 16:18 Uhr schrieb Александр :

> Hi, everyone. Could you give me corresponding rights? Jira name: Salatich
>
> Best regards,
> Aleksandr Salatich
>

contribution permission

[Александр]

Hi, everyone. Could you give me corresponding rights? Jira name: Salatich

Best regards,
Aleksandr Salatich

Re: Request for contribution access

[Robert Metzger]

Hi,

I added you to our JIRA.

On Wed, Feb 13, 2019 at 9:17 AM Xin Ma  wrote:

> Hi Guys,
>
> I want to contribute to Apache Flink.
> Would you please give me the permission as a contributor?
> My JIRA ID is iluvex.
>
>
> Best regards,
>
> Xin
>

Re: Request for contribution access

[Robert Metzger]

Hey,
I added you to our JIRA

On Wed, Feb 13, 2019 at 9:17 AM 区 <670694...@qq.com> wrote:

> Hi Guys,
>
>
> I want to contribute to Apache Flink.
> Would you please give me the permission as a contributor?
> My JIRA Username is ysqwhiletrue. My JIRA full name sishu.yss.

Request for contribution access

[??]

Hi Guys,


I want to contribute to Apache Flink.
Would you please give me the permission as a contributor?
My JIRA Username is ysqwhiletrue. My JIRA full name sishu.yss.

Request for contribution access

[Xin Ma]

Hi Guys,

I want to contribute to Apache Flink.
Would you please give me the permission as a contributor?
My JIRA ID is iluvex.


Best regards,

Xin

[jira] [Created] (FLINK-11581) Add Chinese document contribution guideline

[Jark Wu (JIRA)]

Jark Wu created FLINK-11581:
---

 Summary: Add Chinese document contribution guideline
 Key: FLINK-11581
 URL: https://issues.apache.org/jira/browse/FLINK-11581
 Project: Flink
  Issue Type: Sub-task
  Components: Project Website
Reporter: Jark Wu


Add a guideline to introduce how to contribute Chinese docs. For example, how 
it works, how to add a new Chinese page.

Maybe we can add a section to 
https://flink.apache.org/contribute-documentation.html .



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Please add me for Flink contribution

[Robert Metzger]

Hey,

that's a difficult question, because I don't know anything about your
interests and experience.
Ideally, somebody here on the mailing list is approaching you because they
need a certain feature in Flink, and you are driving the development
together.
Or you are looking through our JIRA to see if you find a ticket that you
like. I would recommend you to ensure that you have somebody from the
community who's planning the fix / improvement in the JIRA with you, so
that you can be sure that the change gets reviewed and merged in the end.

Best,
Robert


On Sat, Feb 2, 2019 at 7:06 PM abhishek sharma 
wrote:

> Hey Robert,
>
> Thanks for granting me JIRA contributor permission.
> I am just getting started and thought to have an access of JIRA board If
> you have anything particular in mind from where I can begin then, please
> let me know.
>
> Thanks, {{Abhishek}}
>
> On Sat, Feb 2, 2019 at 3:30 AM Robert Metzger  wrote:
>
>> Hey Abhishek,
>> I granted you contributor permission in our JIRA!
>>
>> May I ask what you are planning to work on?
>>
>> Best,
>> Robert
>>
>> On Sat, Feb 2, 2019 at 2:56 AM abhishek sharma <
>> abhioncbr.apa...@gmail.com>
>> wrote:
>>
>> > Please provide me the contribution permission.
>> >
>> > email: abhion...@yahoo.com
>> > apache-username: abhioncbr
>> >
>> > Thanks
>> > Abhishek Sharma
>> >
>>
>

Re: Please add me for Flink contribution

[abhishek sharma]

Hey Robert,

Thanks for granting me JIRA contributor permission.
I am just getting started and thought to have an access of JIRA board If
you have anything particular in mind from where I can begin then, please
let me know.

Thanks, {{Abhishek}}

On Sat, Feb 2, 2019 at 3:30 AM Robert Metzger  wrote:

> Hey Abhishek,
> I granted you contributor permission in our JIRA!
>
> May I ask what you are planning to work on?
>
> Best,
> Robert
>
> On Sat, Feb 2, 2019 at 2:56 AM abhishek sharma  >
> wrote:
>
> > Please provide me the contribution permission.
> >
> > email: abhion...@yahoo.com
> > apache-username: abhioncbr
> >
> > Thanks
> > Abhishek Sharma
> >
>

Re: Please add me for Flink contribution

[Robert Metzger]

Hey Abhishek,
I granted you contributor permission in our JIRA!

May I ask what you are planning to work on?

Best,
Robert

On Sat, Feb 2, 2019 at 2:56 AM abhishek sharma 
wrote:

> Please provide me the contribution permission.
>
> email: abhion...@yahoo.com
> apache-username: abhioncbr
>
> Thanks
> Abhishek Sharma
>

Please add me for Flink contribution

[abhishek sharma]

Please provide me the contribution permission.

email: abhion...@yahoo.com
apache-username: abhioncbr

Thanks
Abhishek Sharma

Contribution to FlinkML

[Alejandro Alcalde]

Hello all

I've been some time developing a library for data preprocessing in Flink.

I reach out to you because this library is almost finished and this month I
will be submitting a paper to a journal (pre-print available at arxiv:
https://arxiv.org/abs/1810.06021)

I've checked Flink's roadmap (
https://cwiki.apache.org/confluence/display/FLINK/FlinkML%3A+Vision+and+Roadmap)
and saw you want to implement Dimensionality reduction. My library has six
preprocessing algorithms, three Discretizers and three feature selection
methods. I was wondering if there is any possibility to integrate them into
Flink. Also, I will be willing to make any necessary changes to the
algorithms, if you consider I could implemented in more efficient ways.
This will allow me also to  improve my knowledge and skill with Flink.

The code is at https://github.com/elbaulp/DPASF

Hoping to hear from you soon, best regards.

*-- Alejandro Alcalde - elbauldelprogramador.com
*

Re: Request contribution permission

[Timo Walther]

Hi,

I gave you contributor permissions.

Regards,
Timo

Am 10.08.18 um 13:05 schrieb 邓林:

  Hi Flink community,

I want to contribute code to Flink, can anyone give me
contribution permission? My JIRA account name is  lyndldeng.

Thanks.

Request contribution permission

[邓林]

 Hi Flink community,

I want to contribute code to Flink, can anyone give me
contribution permission? My JIRA account name is  lyndldeng.

Thanks.

[jira] [Created] (FLINK-9447) "sensible" vs. "sensitive" in Code Contribution Process

[Andrew Janke (JIRA)]

Andrew Janke created FLINK-9447:
---

 Summary: "sensible" vs. "sensitive" in Code Contribution Process
 Key: FLINK-9447
 URL: https://issues.apache.org/jira/browse/FLINK-9447
 Project: Flink
  Issue Type: Bug
  Components: Project Website
 Environment: Chrome 66.0 on macOS High Sierra
Reporter: Andrew Janke


In the Contribute Code page (https://flink.apache.org/contribute-code.html), 
under "Before you start coding...", it refers to "sensible" parts of the code 
base that require a design doc:

> If the description of a JIRA issue indicates that its resolution will touch 
> sensible parts of the code base, be sufficiently complex, or add significant 
> amounts of new code, the Flink community might request a design document 
> (most contributions should not require a design document).

Should this be "sensitive" instead?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Apply for contribution permission

[Chesnay Schepler]

I've given you contributor permissions, looking forward to your 
contributions.


On 03.04.2018 03:59, jianhua xiao wrote:

Hi!

I'm very intrested in Flink and has applied Flink in production, I'm
willing to contribute to it, could anybody give me the contribution
permission please, my jira uername is " xiaojianhua ".

Thanks~

Apply for contribution permission

[jianhua xiao]

Hi!

I'm very intrested in Flink and has applied Flink in production, I'm
willing to contribute to it, could anybody give me the contribution
permission please, my jira uername is " xiaojianhua ".

Thanks~

Re: Question: Flink documentation contribution only to flink-docs-release-1.3 (not flink-docs-release-1.4)

[Kewei Shang]

Hi Gordon,

Thank you for your help. That clarifies the steps for me.

Cheers,
Kewei

On Fri, Sep 22, 2017 at 12:22 PM, Tzu-Li (Gordon) Tai <tzuli...@apache.org>
wrote:

> Hi Kewei,
>
> Welcome to the community and contributing!
>
> Normally, for fixes that apply only to specific release branches, you can
> simply open a pull request against that branch, and not against master
> branch.
> For example, to fix something for Flink 1.3.x, open a pull request against
> the `release-1.3` branch.
>
> I agree that we should perhaps update that part of the contribution doc
> guide a bit for these cases.
>
> Cheers,
> Gordon
>
> On 22 September 2017 at 12:16:03 PM, Kewei Shang (keweish...@gmail.com)
> wrote:
>
> Hi,
>
> I'm new to Flink documentation contribution.
>
> I've noticed there is a typo error in the lastest stable version of
> documentation, which makes a File not found error when linking to another
> page:
> https://ci.apache.org/projects/flink/flink-docs-release-1.3/
>
>
> The lastest Flink documentation v1.4-SNAPSHOT (
> https://ci.apache.org/projects/flink/flink-docs-release-1.4/) doesn't have
> this typo error.
> Only the flink-docs-release-1.3 has this typo error.
>
> I've read the Contribute Documentation page here:
> https://flink.apache.org/contribute-documentation.html
>
> But I still have some questions in the steps I should follow before I
> start. Here are the steps and my questions:
> 1. Make sure no corresponding JIRA already existed, then create a JIRA.
> 2. Fork Flink project and clone my fork to my machine.
> 3. Create a branch related to JIRA.
> Question: Based on which branch should I create my branch? The error
> exists only on branch release-1.3, not on branch master.
> 4. Make changes, test, and push changes to my fork.
> 5. Create Pull Request.
> Question: The contribute-documentation guide says "Make sure that the
> base fork is apache/flink master", but since the typo exists only on branch
> release-1.3, not on branch master, should I still choose apache/flink
> master as base fork? If not, which base fork shall I choose?
>
> Thank you.
>
> Kind regards,
> Kewei Shang
>

Re: Question: Flink documentation contribution only to flink-docs-release-1.3 (not flink-docs-release-1.4)

[Tzu-Li (Gordon) Tai]

Hi Kewei,

Welcome to the community and contributing!

Normally, for fixes that apply only to specific release branches, you can 
simply open a pull request against that branch, and not against master branch.
For example, to fix something for Flink 1.3.x, open a pull request against the 
`release-1.3` branch.

I agree that we should perhaps update that part of the contribution doc guide a 
bit for these cases.

Cheers,
Gordon

On 22 September 2017 at 12:16:03 PM, Kewei Shang (keweish...@gmail.com) wrote:

Hi, 

I'm new to Flink documentation contribution. 

I've noticed there is a typo error in the lastest stable version of 
documentation, which makes a File not found error when linking to another 
page: 
https://ci.apache.org/projects/flink/flink-docs-release-1.3/ 


The lastest Flink documentation v1.4-SNAPSHOT ( 
https://ci.apache.org/projects/flink/flink-docs-release-1.4/) doesn't have 
this typo error. 
Only the flink-docs-release-1.3 has this typo error. 

I've read the Contribute Documentation page here: 
https://flink.apache.org/contribute-documentation.html 

But I still have some questions in the steps I should follow before I 
start. Here are the steps and my questions: 
1. Make sure no corresponding JIRA already existed, then create a JIRA. 
2. Fork Flink project and clone my fork to my machine. 
3. Create a branch related to JIRA. 
Question: Based on which branch should I create my branch? The error 
exists only on branch release-1.3, not on branch master. 
4. Make changes, test, and push changes to my fork. 
5. Create Pull Request. 
Question: The contribute-documentation guide says "Make sure that the 
base fork is apache/flink master", but since the typo exists only on branch 
release-1.3, not on branch master, should I still choose apache/flink 
master as base fork? If not, which base fork shall I choose? 

Thank you. 

Kind regards, 
Kewei Shang 

Question: Flink documentation contribution only to flink-docs-release-1.3 (not flink-docs-release-1.4)

[Kewei Shang]

Hi,

I'm new to Flink documentation contribution.

I've noticed there is a typo error in the lastest stable version of
documentation, which makes a File not found error when linking to another
page:
https://ci.apache.org/projects/flink/flink-docs-release-1.3/


The lastest Flink documentation v1.4-SNAPSHOT (
https://ci.apache.org/projects/flink/flink-docs-release-1.4/) doesn't have
this typo error.
Only the flink-docs-release-1.3 has this typo error.

I've read the Contribute Documentation page here:
https://flink.apache.org/contribute-documentation.html

But I still have some questions in the steps I should follow before I
start. Here are the steps and my questions:
1. Make sure no corresponding JIRA already existed, then create a JIRA.
2. Fork Flink project and clone my fork to my machine.
3. Create a branch related to JIRA.
   Question: Based on which branch should I create my branch? The error
exists only on branch release-1.3, not on branch master.
4. Make changes, test, and push changes to my fork.
5. Create Pull Request.
   Question: The contribute-documentation guide says "Make sure that the
base fork is apache/flink master", but since the typo exists only on branch
release-1.3, not on branch master, should I still choose apache/flink
master as base fork? If not, which base fork shall I choose?

Thank you.

Kind regards,
Kewei Shang

Contribution

[Hasan Gürcan]

Hi devs,

i contributed to Stratosphere as I was studying computer science at the FU 
Berlin. Currently i am working as data engineer and i am very interested in 
contributing to your project.
Do someone have an idea for getting started in contributing to Flink like a 
certain jira task?

Best Regards
Hasan Gürcan

Re: Contribution

[Hasan Gürcan]

Hi,

Thanks Gábor i will search for some tasks with this label.
@Till: Thanks too :). Tendencially to backend.

Best Regards
Hasan

> Am 09.09.2016 um 14:17 schrieb Till Rohrmann :
> 
> Welcome back Hasan :-)
> 
> What are you interested in (e.g. libraries, backend, frontend)?
> 
> Cheers,
> Till
> 
> On Fri, Sep 9, 2016 at 2:02 PM, Gábor Gévay  wrote:
> 
>> Hi Hasan,
>> 
>> Welcome!
>> There is the "starter" label on some Jiras, which means that the issue
>> is good for getting started.
>> 
>> Best,
>> Gábor
>> 
>> 
>> 
>> 
>> 2016-09-09 13:46 GMT+02:00 Hasan Gürcan
>> :
>>> Hi devs,
>>> 
>>> i contributed to Stratosphere as I was studying computer science at the
>> FU Berlin. Currently i am working as data engineer and i am very interested
>> in contributing to your project.
>>> Do someone have an idea for getting started in contributing to Flink
>> like a certain jira task?
>>> 
>>> Best Regards
>>> Hasan Gürcan
>> 

Re: Contribution

[Till Rohrmann]

Welcome back Hasan :-)

What are you interested in (e.g. libraries, backend, frontend)?

Cheers,
Till

On Fri, Sep 9, 2016 at 2:02 PM, Gábor Gévay  wrote:

> Hi Hasan,
>
> Welcome!
> There is the "starter" label on some Jiras, which means that the issue
> is good for getting started.
>
> Best,
> Gábor
>
>
>
>
> 2016-09-09 13:46 GMT+02:00 Hasan Gürcan
> :
> > Hi devs,
> >
> > i contributed to Stratosphere as I was studying computer science at the
> FU Berlin. Currently i am working as data engineer and i am very interested
> in contributing to your project.
> > Do someone have an idea for getting started in contributing to Flink
> like a certain jira task?
> >
> > Best Regards
> > Hasan Gürcan
>

Re: Contribution

[Gábor Gévay]

Hi Hasan,

Welcome!
There is the "starter" label on some Jiras, which means that the issue
is good for getting started.

Best,
Gábor




2016-09-09 13:46 GMT+02:00 Hasan Gürcan
:
> Hi devs,
>
> i contributed to Stratosphere as I was studying computer science at the FU 
> Berlin. Currently i am working as data engineer and i am very interested in 
> contributing to your project.
> Do someone have an idea for getting started in contributing to Flink like a 
> certain jira task?
>
> Best Regards
> Hasan Gürcan

Contribution

[Hasan Gürcan]

Hi devs,

i contributed to Stratosphere as I was studying computer science at the FU 
Berlin. Currently i am working as data engineer and i am very interested in 
contributing to your project.
Do someone have an idea for getting started in contributing to Flink like a 
certain jira task?

Best Regards
Hasan Gürcan

[jira] [Created] (FLINK-2841) Broken roadmap link in FlinkML contribution guide

[Chiwan Park (JIRA)]

Chiwan Park created FLINK-2841:
--

 Summary: Broken roadmap link in FlinkML contribution guide
 Key: FLINK-2841
 URL: https://issues.apache.org/jira/browse/FLINK-2841
 Project: Flink
  Issue Type: Bug
  Components: Documentation, Machine Learning Library
Affects Versions: 0.10
Reporter: Chiwan Park


Because the roadmap of FlinkML is moved to wiki, we need to update roadmap link 
in [FlinkML contribution 
guide|https://ci.apache.org/projects/flink/flink-docs-master/libs/ml/contribution_guide.html].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FLINK-2073) Add contribution guide for FlinkML

[Theodore Vasiloudis (JIRA)]

Theodore Vasiloudis created FLINK-2073:
--

 Summary: Add contribution guide for FlinkML
 Key: FLINK-2073
 URL: https://issues.apache.org/jira/browse/FLINK-2073
 Project: Flink
  Issue Type: New Feature
  Components: Documentation, Machine Learning Library
Reporter: Theodore Vasiloudis
 Fix For: 0.9


We need a guide for contributions to FlinkML in order to encourage the 
extension of the library, and provide guidelines for developers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)