Hi all, @Gale thanks for sharing that insight.
@Frans we've tried that in the past (see the discussion thread), but it doesn't feel like a workable path going forward. There's no new development happening on the Statefun project, and the current PMC and committers are focussing elsewhere when it comes to the multiple Flink projects that exist. Best regards, Martijn On Wed, Jan 28, 2026 at 1:37 PM <[email protected]> wrote: > Hi, > > I did some work recently on a fork to uplift to Flink 2.2 (migrated from > DataSet to DataStream etc). > > > https://github.com/fransking/flink-statefun/commit/25b2dfcc3feafd701eb2fec32d413fab56e1cfe6 > > I did drop kenesis because I have no way to test it. I'd be happy to > contribute the changes back but I'd need some help from the community > navigating the process. > > Thanks, > > Frans > > -----Original Message----- > From: Galen Warren via dev <[email protected]> > Sent: 28 January 2026 14:14 > To: Flink Dev <[email protected]> > Cc: user <[email protected]>; Galen Warren <[email protected]> > Subject: Re: [DISCUSS] Status of Statefun Project > > I had been using it - and contributed some code - but have given up on it > and moved on to other solutions since it's clearly not being supported. > > On Wed, Jan 28, 2026, 6:30 AM Martijn Visser <[email protected]> > wrote: > > > 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+rev > > iew%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> > > > > >>>> > > >>>>>>>>> > > > > > >>>> > > >>>>>>>>> > > > > > >>>> > > >>>>>>>>> > > > > > >>>> > > >>>>>>>>> > > > > > >>>> > > >>>>>>>>> > > > > > >>>> > > >>>>>>>>> > > > > >>>> > > >>>>>>>> > > > > >>>> > > > > > > >>>> > > > > > >>>> > > > > >>> > > > > > > > >
