That's great! Thanks, Robert On Tue, Dec 3, 2019 at 2:31 PM Robert Metzger <rmetz...@apache.org> 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 <wander4...@gmail.com> wrote: > > > Thanks for your summary Stephan. All entries make sense to me. Let's play > > statefun :-) > > > > Best, > > tison. > > > > > > Stephan Ewen <se...@apache.org> 于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 <i...@ververica.com> > 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 <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!" > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
