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