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 <rmetz...@apache.org> 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 <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!" > > > >>> > > > > > > > > >
