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!"
> > > > >>>
> > > >
> > > >
> > >
> >
>
