[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 (
[hidden email] and [hidden email])
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 (
[hidden email])

proposal: (c) separate dev list: "[hidden email]" 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_Tf4A@...%3E

[Chesnay Schepler-3]

[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 (
> [hidden email] and [hidden email])
> 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 (
> [hidden email])
>
> proposal: (c) separate dev list: "[hidden email]" 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_Tf4A@...%3E
>

[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 <[hidden email]> 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 (
> > [hidden email] and [hidden email])
> > 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 (
> > [hidden email])
> >
> > proposal: (c) separate dev list: "[hidden email]" 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_Tf4A@...%3E
> >
>
>

[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 <[hidden email]> 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 <[hidden email]>
> 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 (
> > > [hidden email] and [hidden email])
> > > 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 (
> > > [hidden email])
> > >
> > > proposal: (c) separate dev list: "[hidden email]" 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_Tf4A@...%3E
> > >
> >
> >
>

--
Xuefu Zhang

"In Honey We Trust!"

[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 <[hidden email]> 于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 <[hidden email]> 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 <[hidden email]>
> > 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 (
> > > > [hidden email] and [hidden email])
> > > > 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 (
> > > > [hidden email])
> > > >
> > > > proposal: (c) separate dev list: "[hidden email]" 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_Tf4A@...%3E
> > > >
> > >
> > >
> >
>
>
> --
> Xuefu Zhang
>
> "In Honey We Trust!"
>

[Stephan Ewen]

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-XXXXX 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 <[hidden email]> 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 "func" is an objective better choice
>
> Best,
> tison.
>
>
> Xuefu Z <[hidden email]> 于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 <[hidden email]> 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 <[hidden email]>
> > > 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 (
> > > > > [hidden email] and [hidden email])
> > > > > 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 (
> > > > > [hidden email])
> > > > >
> > > > > proposal: (c) separate dev list: "[hidden email]"
> 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_Tf4A@...%3E
> > > > >
> > > >
> > > >
> > >
> >
> >
> > --
> > Xuefu Zhang
> >
> > "In Honey We Trust!"
> >
>

[Chesnay Schepler-3]

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-XXXXX 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 <[hidden email]> 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 "func" is an objective better choice
>>
>> Best,
>> tison.
>>
>>
>> Xuefu Z <[hidden email]> 于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 <[hidden email]> 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 <[hidden email]>
>>>> 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 (
>>>>>> [hidden email] and [hidden email])
>>>>>> 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 (
>>>>>> [hidden email])
>>>>>>
>>>>>> proposal: (c) separate dev list: "[hidden email]"
>> 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_Tf4A@...%3E
>>>>>
>>>
>>> --
>>> Xuefu Zhang
>>>
>>> "In Honey We Trust!"
>>>

[Stephan Ewen]

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 <[hidden email]>
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-XXXXX 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 <[hidden email]> 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 "func" is an objective better choice
> >>
> >> Best,
> >> tison.
> >>
> >>
> >> Xuefu Z <[hidden email]> 于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 <[hidden email]>
> 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 <[hidden email]>
> >>>> 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 (
> >>>>>> [hidden email] and [hidden email])
> >>>>>> 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 (
> >>>>>> [hidden email])
> >>>>>>
> >>>>>> proposal: (c) separate dev list: "[hidden email]"
> >> 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_Tf4A@...%3E
> >>>>>
> >>>
> >>> --
> >>> Xuefu Zhang
> >>>
> >>> "In Honey We Trust!"
> >>>
>
>

[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 <[hidden email]> 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 <[hidden email]>
> 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-XXXXX 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 <[hidden email]> 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 "func" is an objective better choice
> > >>
> > >> Best,
> > >> tison.
> > >>
> > >>
> > >> Xuefu Z <[hidden email]> 于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 <[hidden email]>
> > 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 <[hidden email]
> >
> > >>>> 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 (
> > >>>>>> [hidden email] and [hidden email])
> > >>>>>> 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 (
> > >>>>>> [hidden email])
> > >>>>>>
> > >>>>>> proposal: (c) separate dev list: "[hidden email]"
> > >> 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_Tf4A@...%3E
> > >>>>>
> > >>>
> > >>> --
> > >>> Xuefu Zhang
> > >>>
> > >>> "In Honey We Trust!"
> > >>>
> >
> >
>

[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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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-XXXXX 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 <[hidden email]> 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 "func" is an objective better choice
> > > >>
> > > >> Best,
> > > >> tison.
> > > >>
> > > >>
> > > >> Xuefu Z <[hidden email]> 于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 <[hidden email]>
> > > 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 <
> [hidden email]
> > >
> > > >>>> 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 (
> > > >>>>>> [hidden email] and
> [hidden email])
> > > >>>>>> 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 (
> > > >>>>>> [hidden email])
> > > >>>>>>
> > > >>>>>> proposal: (c) separate dev list: "[hidden email]
> "
> > > >> 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_Tf4A@...%3E
> > > >>>>>
> > > >>>
> > > >>> --
> > > >>> Xuefu Zhang
> > > >>>
> > > >>> "In Honey We Trust!"
> > > >>>
> > >
> > >
> >
>

[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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
> > > 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-XXXXX 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 <[hidden email]>
> 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 "func" is an objective better
> choice
> > > > >>
> > > > >> Best,
> > > > >> tison.
> > > > >>
> > > > >>
> > > > >> Xuefu Z <[hidden email]> 于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 <[hidden email]>
> > > > 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 <
> > [hidden email]
> > > >
> > > > >>>> 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 (
> > > > >>>>>> [hidden email] and
> > [hidden email])
> > > > >>>>>> 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 (
> > > > >>>>>> [hidden email])
> > > > >>>>>>
> > > > >>>>>> proposal: (c) separate dev list: "
> [hidden email]
> > "
> > > > >> 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_Tf4A@...%3E
> > > > >>>>>
> > > > >>>
> > > > >>> --
> > > > >>> Xuefu Zhang
> > > > >>>
> > > > >>> "In Honey We Trust!"
> > > > >>>
> > > >
> > > >
> > >
> >
>

[tison]

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

Best,
tison.


Stephan Ewen <[hidden email]> 于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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> 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 <
> [hidden email]>
> > > > 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-XXXXX 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 <[hidden email]>
> > 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 "func" is an objective better
> > choice
> > > > > >>
> > > > > >> Best,
> > > > > >> tison.
> > > > > >>
> > > > > >>
> > > > > >> Xuefu Z <[hidden email]> 于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 <
> [hidden email]>
> > > > > 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 <
> > > [hidden email]
> > > > >
> > > > > >>>> 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 (
> > > > > >>>>>> [hidden email] and
> > > [hidden email])
> > > > > >>>>>> 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 (
> > > > > >>>>>> [hidden email])
> > > > > >>>>>>
> > > > > >>>>>> proposal: (c) separate dev list: "
> > [hidden email]
> > > "
> > > > > >> 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_Tf4A@...%3E
> > > > > >>>>>
> > > > > >>>
> > > > > >>> --
> > > > > >>> Xuefu Zhang
> > > > > >>>
> > > > > >>> "In Honey We Trust!"
> > > > > >>>
> > > > >
> > > > >
> > > >
> > >
> >
>

[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 <[hidden email]> wrote:

> Thanks for your summary Stephan. All entries make sense to me. Let's play
> statefun :-)
>
> Best,
> tison.
>
>
> Stephan Ewen <[hidden email]> 于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 <[hidden email]> 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 <[hidden email]>
> > > 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 <[hidden email]>
> > 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 <
> > [hidden email]>
> > > > > 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-XXXXX 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 <[hidden email]>
> > > 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 "func" is an objective better
> > > choice
> > > > > > >>
> > > > > > >> Best,
> > > > > > >> tison.
> > > > > > >>
> > > > > > >>
> > > > > > >> Xuefu Z <[hidden email]> 于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 <
> > [hidden email]>
> > > > > > 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 <
> > > > [hidden email]
> > > > > >
> > > > > > >>>> 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 (
> > > > > > >>>>>> [hidden email] and
> > > > [hidden email])
> > > > > > >>>>>> 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 (
> > > > > > >>>>>> [hidden email])
> > > > > > >>>>>>
> > > > > > >>>>>> proposal: (c) separate dev list: "
> > > [hidden email]
> > > > "
> > > > > > >> 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_Tf4A@...%3E
> > > > > > >>>>>
> > > > > > >>>
> > > > > > >>> --
> > > > > > >>> Xuefu Zhang
> > > > > > >>>
> > > > > > >>> "In Honey We Trust!"
> > > > > > >>>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Stephan Ewen]

 That's great!
Thanks, Robert

On Tue, Dec 3, 2019 at 2:31 PM Robert Metzger <[hidden email]> 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 <[hidden email]> wrote:
>
> > Thanks for your summary Stephan. All entries make sense to me. Let's play
> > statefun :-)
> >
> > Best,
> > tison.
> >
> >
> > Stephan Ewen <[hidden email]> 于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 <[hidden email]>
> 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 <[hidden email]>
> > > > 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 <[hidden email]>
> > > 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 <
> > > [hidden email]>
> > > > > > 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-XXXXX 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 <[hidden email]>
> > > > 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 "func" is an objective
> better
> > > > choice
> > > > > > > >>
> > > > > > > >> Best,
> > > > > > > >> tison.
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Xuefu Z <[hidden email]> 于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 <
> > > [hidden email]>
> > > > > > > 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 <
> > > > > [hidden email]
> > > > > > >
> > > > > > > >>>> 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 (
> > > > > > > >>>>>> [hidden email] and
> > > > > [hidden email])
> > > > > > > >>>>>> 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 (
> > > > > > > >>>>>> [hidden email])
> > > > > > > >>>>>>
> > > > > > > >>>>>> proposal: (c) separate dev list: "
> > > > [hidden email]
> > > > > "
> > > > > > > >> 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_Tf4A@...%3E
> > > > > > > >>>>>
> > > > > > > >>>
> > > > > > > >>> --
> > > > > > > >>> Xuefu Zhang
> > > > > > > >>>
> > > > > > > >>> "In Honey We Trust!"
> > > > > > > >>>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>