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