I forgot to include the link to this discussion thread for those that don't have the history, that can be found at https://lists.apache.org/thread/7cr2bgt91ppk6pz8o0nfbd10gs63nz6t
On Wed, Jan 28, 2026 at 12:28 PM Martijn Visser <[email protected]> wrote: > 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> > > >>>> > > >>>>>>>>> > > > >>>> > > >>>>>>>>> > > > >>>> > > >>>>>>>>> > > > >>>> > > >>>>>>>>> > > > >>>> > > >>>>>>>>> > > > >>>> > > >>>>>>>>> > > >>>> > > >>>>>>>> > > >>>> > > > > >>>> > > > >>>> > > >>> >
