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