As mentioned before, the name was mainly chosen to resonate with developers form a different background (applications / services) and we checked it with some users. Unrelated to Flink and Stream Processing, it seemed to describe the target use case pretty well.
What would you use as a name instead? On Tue, Nov 12, 2019 at 10:10 AM Chesnay Schepler <ches...@apache.org> wrote: > I'm concerned both about the abbreviation and full name. > > a) It's not distinguishing enough from existing APIs, specifically the > Streaming API, which already features stateful functions. > b) It doesn't describe use-cases that the existing APIs cannot satisfy. > > On 11/11/2019 15:28, Stephan Ewen wrote: > > Thanks, all for the discussion! > > > > About the name: > > > > - Like Igal mentioned, the name "Stateful Functions" and the > abbreviation > > "statefun" underwent some iterations and testing with a small sample of > > developers from a few companies. > > If anyone has an amazing suggestion for another name, please share. > > Would be great to also test it with a small sample of developers from a > few > > companies, just to make sure we have at least a bit of outside feedback. > > > > - fun vs. fn vs. func: I think these are more or less equivalent, > there > > are examples of each one in some language. Working with the code over the > > 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!" > >>> > >
