Hi everyone, I'm bringing back this very old thread. It's been a while since we last discussed this, so I wanted to follow up on where things stand with Stateful Functions.
Since the 3.3.0 release in September 2023, there has been: - Zero commits to the repository - No new releases (now 4+ Flink versions behind: 1.16 vs 1.20/2.2) - 22 open PRs unreviewed - No sustained contributor activity I don't think that the current Flink committers and PMC members have the bandwidth or expertise in StateFun's codebase to maintain it. StateFun was always a specialized subproject maintained by a small group of dedicated contributors who have since moved on to other projects. Given this situation, I'd like to get the community's input: 1. Is anyone still actively using StateFun in production? 2. Should we consider sunsetting the project rather than leaving it in limbo? Thanks, Martijn Op wo 23 aug 2023 om 08:48 schreef Filip Karnicki <[email protected]>: > > Hi Gordon > > Any chance we could get this reviewed and released to the central repo? > We're currently forced to use a Flink version that has a nasty bug causing > an operational nightmare > > Many thanks > Fil > > On Sat, 19 Aug 2023 at 01:38, Galen Warren via user <[email protected]> > wrote: > > > Gotcha, makes sense as to the original division. > > > > >> Can this be solved by simply passing in the path to the artifacts > > > > This definitely works if we're going to be copying the artifacts on the > > host side -- into the build context -- and then from the context into the > > image. It only gets tricky to have a potentially varying path to the > > artifacts if we're trying to *directly *include the artifacts in the > > Docker context -- then we have a situation where the Docker context must > > contain both the artifacts and playground files, with (potentially) > > different root locations. > > > > Maybe the simplest thing to do here is just to leave the playground as-is > > and then copy the artifacts into the Docker context manually, prior to > > building the playground images. I'm fine with that. It will mean that each > > Statefun release will require two PRs and two sets of build/publish steps > > instead of one, but if everyone else is fine with that I am, too. Unless > > anyone objects, I'll go ahead and queue up a PR for the playground that > > makes these changes. > > > > Also, I should mention -- in case it's not clear -- that I have already > > built and run the playground examples with the code from the PR and > > everything worked. So that PR is ready to move forward with review, etc., > > at this point. > > > > Thanks. > > > > > > > > > > > > > > > > On Fri, Aug 18, 2023 at 4:16 PM Tzu-Li (Gordon) Tai <[email protected]> > > wrote: > > > >> Hi Galen, > >> > >> The original intent of having a separate repo for the playground repo, > >> was that StateFun users can just go to that and start running simple > >> examples without any other distractions from the core code. I personally > >> don't have a strong preference here and can understand how it would make > >> the workflow more streamlined, but just FYI on the reasoning why are > >> separate in the first place. > >> > >> re: paths for locating StateFun artifacts. > >> Can this be solved by simply passing in the path to the artifacts? As > >> well as the image tag for the locally build base StateFun image. They could > >> probably be environment variables. > >> > >> Cheers, > >> Gordon > >> > >> On Fri, Aug 18, 2023 at 12:13 PM Galen Warren via user < > >> [email protected]> wrote: > >> > >>> Yes, exactly! And in addition to the base Statefun jars and the jar for > >>> the Java SDK, it does an equivalent copy/register operation for each of > >>> the > >>> other SDK libraries (Go, Python, Javascript) so that those libraries are > >>> also available when building the playground examples. > >>> > >>> One more question: In order to copy the various build artifacts into the > >>> Docker containers, those artifacts need to be part of the Docker context. > >>> With the playground being a separate project, that's slightly tricky to > >>> do, > >>> as there is no guarantee (other than convention) about the relative paths > >>> of *flink-statefun* and* flink-statefun-playground *in someone's local > >>> filesystem. The way I've set this up locally is to copy the playground > >>> into > >>> the* flink-statefun* project -- i.e. to *flink-statefun*/playground -- > >>> such that I can set the Docker context to the root folder of > >>> *flink-statefun* and then have access to any local code and/or build > >>> artifacts. > >>> > >>> I'm wondering if there might be any appetite for making that move > >>> permanent, i.e. moving the playground to *flink-statefun*/playground > >>> and deprecating the standalone playground project. In addition to making > >>> the problem of building with unreleased artifacts a bit simpler to solve, > >>> it would also simplify the process of releasing a new Statefun version, > >>> since the entire process could be handled with a single PR and associated > >>> build/deploy tasks. In other words, a single PR could both update and > >>> deploy the Statefun package and the playground code and images. > >>> > >>> As it stands, at least two PRs would be required for each Statefun > >>> version update -- one for *flink-statefun* and one for > >>> *flink-statefun-playground*. > >>> > >>> Anyway, just an idea. Maybe there's an important reason for these > >>> projects to remain separate. If we do want to keep the playground project > >>> where it is, I could solve the copying problem by requiring the two > >>> projects to be siblings in the file system and by pre-copying the local > >>> build artifacts into a location accessible by the existing Docker > >>> contexts. > >>> This would still leave us with the need to have two PRs and releases > >>> instead of one, though. > >>> > >>> Thanks for your help! > >>> > >>> > >>> On Fri, Aug 18, 2023 at 2:45 PM Tzu-Li (Gordon) Tai <[email protected]> > >>> wrote: > >>> > >>>> Hi Galen, > >>>> > >>>> > locally built code is copied into the build containers > >>>> so that it can be accessed during the build. > >>>> > >>>> That's exactly what we had been doing for release testing, yes. Sorry I > >>>> missed that detail in my previous response. > >>>> > >>>> And yes, that sounds like a reasonable approach. If I understand you > >>>> correctly, the workflow would become this: > >>>> > >>>> 1. Build the StateFun repo locally to install the snapshot artifact > >>>> jars + have a local base StateFun image. > >>>> 2. Run the playground in "local" mode, so that it uses the local base > >>>> StateFun image + builds the playground code using copied artifact > >>>> jars > >>>> (instead of pulling from Maven). > >>>> > >>>> That looks good to me! > >>>> > >>>> Thanks, > >>>> Gordon > >>>> > >>>> On Fri, Aug 18, 2023 at 11:33 AM Galen Warren > >>>> <[email protected]> wrote: > >>>> > >>>> > Thanks. > >>>> > > >>>> > If you were to build a local image, as you suggest, how do you access > >>>> that > >>>> > image when building the playground images? All the compilation of > >>>> > playground code happens inside containers, so local images on the host > >>>> > aren't available in those containers. Unless I'm missing something? > >>>> > > >>>> > I've slightly reworked things such that the playground images can be > >>>> run in > >>>> > one of two modes -- the default mode, which works like before, and a > >>>> > "local" mode where locally built code is copied into the build > >>>> containers > >>>> > so that it can be accessed during the build. It works fine, you just > >>>> have > >>>> > to define a couple of environment variables when running > >>>> docker-compose to > >>>> > specify default vs. local mode and what versions of Flink and Statefun > >>>> > should be referenced, and then you can build a run the local examples > >>>> > without any additional steps. Does that sound like a reasonable > >>>> approach? > >>>> > > >>>> > > >>>> > On Fri, Aug 18, 2023 at 2:17 PM Tzu-Li (Gordon) Tai < > >>>> [email protected]> > >>>> > wrote: > >>>> > > >>>> > > Hi Galen, > >>>> > > > >>>> > > > Gordon, is there a trick to running the sample code in > >>>> > > flink-statefun-playground against yet-unreleased code that I'm > >>>> missing? > >>>> > > > >>>> > > You'd have to locally build an image from the release branch, with a > >>>> > > temporary image version tag. Then, in the flink-statefun-playground, > >>>> > change > >>>> > > the image versions in the docker-compose files to use that locally > >>>> built > >>>> > > image. IIRC, that's what we have been doing in the past. > >>>> Admittedly, it's > >>>> > > pretty manual - I don't think the CI manages this workflow. > >>>> > > > >>>> > > Thanks, > >>>> > > Gordon > >>>> > > > >>>> > > On Mon, Aug 14, 2023 at 10:42 AM Galen Warren < > >>>> [email protected]> > >>>> > > wrote: > >>>> > > > >>>> > > > I created a pull request for this: [FLINK-31619] Upgrade Stateful > >>>> > > > Functions to Flink 1.16.1 by galenwarren · Pull Request #331 · > >>>> > > > apache/flink-statefun (github.com) > >>>> > > > <https://github.com/apache/flink-statefun/pull/331>. > >>>> > > > > >>>> > > > JIRA is here: [FLINK-31619] Upgrade Stateful Functions to Flink > >>>> 1.16.1 > >>>> > - > >>>> > > > ASF JIRA (apache.org) > >>>> > > > <https://issues.apache.org/jira/browse/FLINK-31619?filter=-1>. > >>>> > > > > >>>> > > > Statefun references 1.16.2, despite the title -- that version has > >>>> come > >>>> > > out > >>>> > > > since the issue was created. > >>>> > > > > >>>> > > > I figured out how to run all the playground tests locally, but it > >>>> took > >>>> > a > >>>> > > > bit of reworking of the playground setup with respect to Docker; > >>>> > > > specifically, the Docker contexts used to build the example > >>>> functions > >>>> > > > needed to be broadened (i.e. moved up the tree) so that, if > >>>> needed, > >>>> > local > >>>> > > > artifacts/code can be accessed from within the containers at build > >>>> > time. > >>>> > > > Then I made the Docker compose.yml configurable through > >>>> environment > >>>> > > > variables to allow for them to run in either the original manner > >>>> -- > >>>> > i.e. > >>>> > > > pulling artifacts from public repos -- or in a "local" mode, where > >>>> > > > artifacts are pulled from local builds. > >>>> > > > > >>>> > > > This process is a cleaner if the playground is a subfolder of the > >>>> > > > flink-statefun project rather than be its own repository > >>>> > > > (flink-statefun-playground), because then all the relative paths > >>>> > between > >>>> > > > the playground files and the build artifacts are fixed. So, I'd > >>>> like to > >>>> > > > propose to move the playground files, modified as described > >>>> above, to > >>>> > > > flink-statefun/playground and retire flink-statefun-playground. I > >>>> can > >>>> > > > submit separate PR s those changes if everyone is on board. > >>>> > > > > >>>> > > > Also, should I plan to do the same upgrade to handle Flink > >>>> 1.17.x? It > >>>> > > > should be easy to do, especially while the 1.16.x upgrade is > >>>> fresh on > >>>> > my > >>>> > > > mind. > >>>> > > > > >>>> > > > Thanks. > >>>> > > > > >>>> > > > > >>>> > > > On Fri, Aug 11, 2023 at 6:40 PM Galen Warren < > >>>> [email protected]> > >>>> > > > wrote: > >>>> > > > > >>>> > > >> I'm done with the code to make Statefun compatible with Flink > >>>> 1.16, > >>>> > and > >>>> > > >> all the tests (including e2e succeed). The required changes were > >>>> > pretty > >>>> > > >> minimal. > >>>> > > >> > >>>> > > >> I'm running into a bit of a chicken/egg problem executing the > >>>> tests in > >>>> > > >> flink-statefun-playground > >>>> > > >> <https://github.com/apache/flink-statefun-playground>, though. > >>>> That > >>>> > > >> project seems to assume that all the various Statefun artifacts > >>>> are > >>>> > > built > >>>> > > >> and deployed to the various public repositories already. I've > >>>> looked > >>>> > > into > >>>> > > >> trying to redirect references to local artifacts; however, > >>>> that's also > >>>> > > >> tricky since all the building occurs in Docker containers. > >>>> > > >> > >>>> > > >> Gordon, is there a trick to running the sample code in > >>>> > > >> flink-statefun-playground against yet-unreleased code that I'm > >>>> > missing? > >>>> > > >> > >>>> > > >> Thanks. > >>>> > > >> > >>>> > > >> On Sat, Jun 24, 2023 at 12:40 PM Galen Warren < > >>>> > [email protected]> > >>>> > > >> wrote: > >>>> > > >> > >>>> > > >>> Great -- thanks! > >>>> > > >>> > >>>> > > >>> I'm going to be out of town for about a week but I'll take a > >>>> look at > >>>> > > >>> this when I'm back. > >>>> > > >>> > >>>> > > >>> On Tue, Jun 20, 2023 at 8:46 AM Martijn Visser < > >>>> [email protected] > >>>> > > > >>>> > > >>> wrote: > >>>> > > >>> > >>>> > > >>>> Hi Galen, > >>>> > > >>>> > >>>> > > >>>> Yes, I'll be more than happy to help with Statefun releases. > >>>> > > >>>> > >>>> > > >>>> Best regards, > >>>> > > >>>> > >>>> > > >>>> Martijn > >>>> > > >>>> > >>>> > > >>>> On Tue, Jun 20, 2023 at 2:21 PM Galen Warren < > >>>> > [email protected] > >>>> > > > > >>>> > > >>>> wrote: > >>>> > > >>>> > >>>> > > >>>>> Thanks. > >>>> > > >>>>> > >>>> > > >>>>> Martijn, to answer your question, I'd need to do a small > >>>> amount of > >>>> > > >>>>> work to get a PR ready, but not much. Happy to do it if we're > >>>> > > deciding to > >>>> > > >>>>> restart Statefun releases -- are we? > >>>> > > >>>>> > >>>> > > >>>>> -- Galen > >>>> > > >>>>> > >>>> > > >>>>> On Sat, Jun 17, 2023 at 9:47 AM Tzu-Li (Gordon) Tai < > >>>> > > >>>>> [email protected]> wrote: > >>>> > > >>>>> > >>>> > > >>>>>> > Perhaps he could weigh in on whether the combination of > >>>> > automated > >>>> > > >>>>>> tests plus those smoke tests should be sufficient for > >>>> testing with > >>>> > > new > >>>> > > >>>>>> Flink versions > >>>> > > >>>>>> > >>>> > > >>>>>> What we usually did at the bare minimum for new StateFun > >>>> releases > >>>> > > was > >>>> > > >>>>>> the following: > >>>> > > >>>>>> > >>>> > > >>>>>> 1. Build tests (including the smoke tests in the e2e > >>>> module, > >>>> > > >>>>>> which covers important tests like exactly-once > >>>> verification) > >>>> > > >>>>>> 2. Updating the flink-statefun-playground repo and > >>>> manually > >>>> > > >>>>>> running all language examples there. > >>>> > > >>>>>> > >>>> > > >>>>>> If upgrading Flink versions was the only change in the > >>>> release, > >>>> > I'd > >>>> > > >>>>>> probably say that this is sufficient. > >>>> > > >>>>>> > >>>> > > >>>>>> Best, > >>>> > > >>>>>> Gordon > >>>> > > >>>>>> > >>>> > > >>>>>> On Thu, Jun 15, 2023 at 5:25 AM Martijn Visser < > >>>> > > >>>>>> [email protected]> wrote: > >>>> > > >>>>>> > >>>> > > >>>>>>> Let me know if you have a PR for a Flink update :) > >>>> > > >>>>>>> > >>>> > > >>>>>>> On Thu, Jun 8, 2023 at 5:52 PM Galen Warren via user < > >>>> > > >>>>>>> [email protected]> wrote: > >>>> > > >>>>>>> > >>>> > > >>>>>>>> Thanks Martijn. > >>>> > > >>>>>>>> > >>>> > > >>>>>>>> Personally, I'm already using a local fork of Statefun > >>>> that is > >>>> > > >>>>>>>> compatible with Flink 1.16.x, so I wouldn't have any need > >>>> for a > >>>> > > released > >>>> > > >>>>>>>> version compatible with 1.15.x. I'd be happy to do the PRs > >>>> to > >>>> > > modify > >>>> > > >>>>>>>> Statefun to work with new versions of Flink as they come > >>>> along. > >>>> > > >>>>>>>> > >>>> > > >>>>>>>> As for testing, Statefun does have unit tests and Gordon > >>>> also > >>>> > sent > >>>> > > >>>>>>>> me instructions a while back for how to do some additional > >>>> smoke > >>>> > > tests > >>>> > > >>>>>>>> which are pretty straightforward. Perhaps he could weigh > >>>> in on > >>>> > > whether the > >>>> > > >>>>>>>> combination of automated tests plus those smoke tests > >>>> should be > >>>> > > sufficient > >>>> > > >>>>>>>> for testing with new Flink versions (I believe the answer > >>>> is > >>>> > yes). > >>>> > > >>>>>>>> > >>>> > > >>>>>>>> -- Galen > >>>> > > >>>>>>>> > >>>> > > >>>>>>>> > >>>> > > >>>>>>>> > >>>> > > >>>>>>>> On Thu, Jun 8, 2023 at 8:01 AM Martijn Visser < > >>>> > > >>>>>>>> [email protected]> wrote: > >>>> > > >>>>>>>> > >>>> > > >>>>>>>>> Hi all, > >>>> > > >>>>>>>>> > >>>> > > >>>>>>>>> Apologies for the late reply. > >>>> > > >>>>>>>>> > >>>> > > >>>>>>>>> I'm willing to help out with merging requests in Statefun > >>>> to > >>>> > keep > >>>> > > >>>>>>>>> them > >>>> > > >>>>>>>>> compatible with new Flink releases and create new > >>>> releases. I > >>>> > do > >>>> > > >>>>>>>>> think that > >>>> > > >>>>>>>>> validation of the functionality of these releases depends > >>>> a lot > >>>> > > on > >>>> > > >>>>>>>>> those > >>>> > > >>>>>>>>> who do these compatibility updates, with PMC members > >>>> helping > >>>> > out > >>>> > > >>>>>>>>> with the > >>>> > > >>>>>>>>> formal process. > >>>> > > >>>>>>>>> > >>>> > > >>>>>>>>> > Why can't the Apache Software Foundation allow community > >>>> > > members > >>>> > > >>>>>>>>> to bring > >>>> > > >>>>>>>>> it up to date? > >>>> > > >>>>>>>>> > >>>> > > >>>>>>>>> There's nothing preventing anyone from reviewing any of > >>>> the > >>>> > > >>>>>>>>> current PRs or > >>>> > > >>>>>>>>> opening new ones. However, none of them are approved [1], > >>>> so > >>>> > > >>>>>>>>> there's also > >>>> > > >>>>>>>>> nothing to merge. > >>>> > > >>>>>>>>> > >>>> > > >>>>>>>>> > I believe that there are people and companies on this > >>>> mailing > >>>> > > >>>>>>>>> list > >>>> > > >>>>>>>>> interested in supporting Apache Flink Stateful Functions. > >>>> > > >>>>>>>>> > >>>> > > >>>>>>>>> If so, then now is the time to show. > >>>> > > >>>>>>>>> > >>>> > > >>>>>>>>> Would there be a preference to create a release with > >>>> Galen's > >>>> > > merged > >>>> > > >>>>>>>>> compatibility update to Flink 1.15.2, or do we want to > >>>> skip > >>>> > that > >>>> > > >>>>>>>>> and go > >>>> > > >>>>>>>>> straight to a newer version? > >>>> > > >>>>>>>>> > >>>> > > >>>>>>>>> Best regards, > >>>> > > >>>>>>>>> > >>>> > > >>>>>>>>> Martijn > >>>> > > >>>>>>>>> > >>>> > > >>>>>>>>> [1] > >>>> > > >>>>>>>>> > >>>> > > >>>>>>>>> > >>>> > > > >>>> > > >>>> https://github.com/apache/flink-statefun/pulls?q=is%3Apr+is%3Aopen+review%3Aapproved > >>>> > > >>>>>>>>> > >>>> > > >>>>>>>>> On Tue, Jun 6, 2023 at 3:55 PM Marco Villalobos < > >>>> > > >>>>>>>>> [email protected]> > >>>> > > >>>>>>>>> wrote: > >>>> > > >>>>>>>>> > >>>> > > >>>>>>>>> > Why can't the Apache Software Foundation allow community > >>>> > > members > >>>> > > >>>>>>>>> to bring > >>>> > > >>>>>>>>> > it up to date? > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > What's the process for that? > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > I believe that there are people and companies on this > >>>> mailing > >>>> > > >>>>>>>>> list > >>>> > > >>>>>>>>> > interested in supporting Apache Flink Stateful > >>>> Functions. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > You already had two people on this thread express > >>>> interest. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > At the very least, we could keep the library versions > >>>> up to > >>>> > > date. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > There are only a small list of new features that might > >>>> be > >>>> > > >>>>>>>>> worthwhile: > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > 1. event time processing > >>>> > > >>>>>>>>> > 2. state rest api > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > On Jun 6, 2023, at 3:06 AM, Chesnay Schepler < > >>>> > > [email protected]> > >>>> > > >>>>>>>>> wrote: > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > If you were to fork it *and want to redistribute it* > >>>> then the > >>>> > > >>>>>>>>> short > >>>> > > >>>>>>>>> > version is that > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > 1. you have to adhere to the Apache licensing > >>>> requirements > >>>> > > >>>>>>>>> > 2. you have to make it clear that your fork does not > >>>> > belong > >>>> > > >>>>>>>>> to the > >>>> > > >>>>>>>>> > Apache Flink project. (Trademarks and all that) > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > Neither should be significant hurdles (there should > >>>> also be > >>>> > > >>>>>>>>> plenty of > >>>> > > >>>>>>>>> > online resources regarding 1), and if you do this then > >>>> you > >>>> > can > >>>> > > >>>>>>>>> freely share > >>>> > > >>>>>>>>> > your fork with others. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > I've also pinged Martijn to take a look at this thread. > >>>> > > >>>>>>>>> > To my knowledge the project hasn't decided anything yet. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > On 27/05/2023 04:05, Galen Warren wrote: > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > Ok, I get it. No interest. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > If this project is being abandoned, I guess I'll work > >>>> with my > >>>> > > >>>>>>>>> own fork. Is > >>>> > > >>>>>>>>> > there anything I should consider here? Can I share it > >>>> with > >>>> > > other > >>>> > > >>>>>>>>> people who > >>>> > > >>>>>>>>> > use this project? > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > On Tue, May 16, 2023 at 10:50 AM Galen Warren < > >>>> > > >>>>>>>>> [email protected]> <[email protected]> > >>>> > > >>>>>>>>> > wrote: > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > Hi Martijn, since you opened this discussion thread, I'm > >>>> > > curious > >>>> > > >>>>>>>>> what your > >>>> > > >>>>>>>>> > thoughts are in light of the responses? Thanks. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > On Wed, Apr 19, 2023 at 1:21 PM Galen Warren < > >>>> > > >>>>>>>>> [email protected]> <[email protected]> > >>>> > > >>>>>>>>> > wrote: > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > I use Apache Flink for stream processing, and StateFun > >>>> as a > >>>> > > >>>>>>>>> hand-off > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > point for the rest of the application. > >>>> > > >>>>>>>>> > It serves well as a bridge between a Flink Streaming > >>>> job and > >>>> > > >>>>>>>>> > micro-services. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > This is essentially how I use it as well, and I would > >>>> also be > >>>> > > >>>>>>>>> sad to see > >>>> > > >>>>>>>>> > it sunsetted. It works well; I don't know that there is > >>>> a lot > >>>> > > of > >>>> > > >>>>>>>>> new > >>>> > > >>>>>>>>> > development required, but if there are no new Statefun > >>>> > > releases, > >>>> > > >>>>>>>>> then > >>>> > > >>>>>>>>> > Statefun can only be used with older Flink versions. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > On Tue, Apr 18, 2023 at 10:04 PM Marco Villalobos < > >>>> > > >>>>>>>>> [email protected]> wrote: > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > I am currently using Stateful Functions in my > >>>> application. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > I use Apache Flink for stream processing, and StateFun > >>>> as a > >>>> > > >>>>>>>>> hand-off > >>>> > > >>>>>>>>> > point for the rest of the application. > >>>> > > >>>>>>>>> > It serves well as a bridge between a Flink Streaming > >>>> job and > >>>> > > >>>>>>>>> > micro-services. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > I would be disappointed if StateFun was sunsetted. Its > >>>> a > >>>> > good > >>>> > > >>>>>>>>> idea. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > If there is anything I can do to help, as a contributor > >>>> > > perhaps, > >>>> > > >>>>>>>>> please > >>>> > > >>>>>>>>> > let me know. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > On Apr 3, 2023, at 2:02 AM, Martijn Visser < > >>>> > > >>>>>>>>> [email protected]> <[email protected]> > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > wrote: > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > Hi everyone, > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > I want to open a discussion on the status of the > >>>> Statefun > >>>> > > >>>>>>>>> Project [1] > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > in Apache Flink. As you might have noticed, there > >>>> hasn't been > >>>> > > >>>>>>>>> much > >>>> > > >>>>>>>>> > development over the past months in the Statefun > >>>> repository > >>>> > > [2]. > >>>> > > >>>>>>>>> There is > >>>> > > >>>>>>>>> > currently a lack of active contributors and committers > >>>> who > >>>> > are > >>>> > > >>>>>>>>> able to help > >>>> > > >>>>>>>>> > with the maintenance of the project. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > In order to improve the situation, we need to solve the > >>>> lack > >>>> > of > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > committers and the lack of contributors. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > On the lack of committers: > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > 1. Ideally, there are some of the current Flink > >>>> committers > >>>> > who > >>>> > > >>>>>>>>> have > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > the bandwidth and can help with reviewing PRs and > >>>> merging > >>>> > them. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > 2. If that's not an option, it could be a consideration > >>>> that > >>>> > > >>>>>>>>> current > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > committers only approve and review PRs, that are > >>>> approved by > >>>> > > >>>>>>>>> those who are > >>>> > > >>>>>>>>> > willing to contribute to Statefun and if the CI passes > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > On the lack of contributors: > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > 3. Next to having this discussion on the Dev and User > >>>> mailing > >>>> > > >>>>>>>>> list, we > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > can also create a blog with a call for new contributors > >>>> on > >>>> > the > >>>> > > >>>>>>>>> Flink > >>>> > > >>>>>>>>> > project website, send out some tweets on the Flink / > >>>> Statefun > >>>> > > >>>>>>>>> twitter > >>>> > > >>>>>>>>> > accounts, post messages on Slack etc. In that message, > >>>> we > >>>> > would > >>>> > > >>>>>>>>> inform how > >>>> > > >>>>>>>>> > those that are interested in contributing can start and > >>>> where > >>>> > > >>>>>>>>> they could > >>>> > > >>>>>>>>> > reach out for more information. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > There's also option 4. where a group of interested > >>>> people > >>>> > would > >>>> > > >>>>>>>>> split > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > Statefun from the Flink project and make it a separate > >>>> top > >>>> > > level > >>>> > > >>>>>>>>> project > >>>> > > >>>>>>>>> > under the Apache Flink umbrella (similar as recently has > >>>> > > >>>>>>>>> happened with > >>>> > > >>>>>>>>> > Flink Table Store, which has become Apache Paimon). > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > If we see no improvements in the coming period, we > >>>> should > >>>> > > >>>>>>>>> consider > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > sunsetting Statefun and communicate that clearly to the > >>>> > users. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > I'm looking forward to your thoughts. > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > Best regards, > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > Martijn > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > [1] > >>>> > > >>>>>>>>> > >>>> https://nightlies.apache.org/flink/flink-statefun-docs-master/ > >>>> > < > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > > >>>> > https://nightlies.apache.org/flink/flink-statefun-docs-master/ > >>>> > > > > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > [2] https://github.com/apache/flink-statefun < > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > https://github.com/apache/flink-statefun> > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>>> > >>>> > > >>>>>>>> > >>>> > > > >>>> > > >>>> > >>>
