[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


Reply via email to