+1 to Stephan's opinion, with just one minor difference. For my experience and a project as big as Flink, picking up an issue created 1-2 years ago seems normal to me. To be more specific, during the blink planner merge, I created lots of clean up & refactor issues, trying to make the code be more clean. I haven't had a chance to resolve all these but I think they are still good improvements. Thus I would propose we don't close any stall issues for at least 2 years.
Best, Kurt On Wed, Jun 30, 2021 at 7:22 AM Stephan Ewen <se...@apache.org> wrote: > Being a bit late to the party, and don't want to ask to change everything, > just maybe some observation. > > My main observation and concern is still that this puts pressure and > confusion on contributors, which are mostly blocked on committers for > reviews, or are taking tickets as multi-week projects. I think it is not a > great experience for contributors, when they are already unsure why their > work isn't getting the attention from committers that they hoped for, to > then see issues unassigned or deprioritized automatically. I think we > really need to weigh this discouragement of contributors against the desire > for a tidy ticket system. > I also think by now this isn't just a matter of phrasing the bot's message > correctly. Auto unassignment and deprioritization sends a subtle message > that jira resolution is a more important goal than paying attention to > contributors (at least I think that is how it will be perceived by many). > > Back to the original motivation, to not have issues lying around forever, > ensuring there is closure eventually. > For that, even much longer intervals would be fine. Like pinging every > three months, closing after three pings - would resolve most tickets in a > year, which is not too bad in the scope of a project like Flink. Many > features/wishes easily move to two releases in the future, which is almost > a year. We would get rid of long dead tickets and interfere little with > current tickets. Contributors can probably understand ticket closing after > a year of inactivity. > > I am curious if a very simple bot that really just looks at stale issues > (no comment/change in three months), pings the > issue/reporter/assignee/watchers and closes it after three pings would do > the job. > We would get out of the un-assigning business (which can send very tricky > signals) and would rely on reporters/assignees/watchers to unassign if they > see that the contributor abandoned the issue. With a cadence of three > months for pinging, this isn't much work for the ones that get pinged. > > Issues where we rely on faster handling are probably the ones where > committers have a stake in getting those into an upcoming release, so these > tend to be watched anyways. > > On Wed, Jun 23, 2021 at 2:39 PM JING ZHANG <beyond1...@gmail.com> wrote: > > > Hi Konstantin, Chesnay, > > > > > I would like it to not unassign people if a PR is open. These are > > > usually blocked by the reviewer, not the assignee, and having the > > > assignees now additionally having to update JIRA periodically is a bit > > > like rubbing salt into the wound. > > > > I agree with Chesnay about not un-assign an issue if a PR is open. > > Besides, Could assignees remove the "stale-assigned" tag by themself? It > > seems assignees have no permission to delete the tag if the issue is not > > created by themselves. > > > > Best regards, > > JING ZHANG > > > > Konstantin Knauf <konstan...@ververica.com> 于2021年6月23日周三 下午4:17写道： > > > > > > I agree there are such tickets, but I don't see how this is > addressing > > my > > > concerns. There are also tickets that just shouldn't be closed as I > > > described above. Why do you think that duplicating tickets and losing > > > discussions/knowledge is a good solution? > > > > > > I don't understand why we are necessarily losing discussion/knowledge. > > The > > > tickets are still there, just in "Closed" state, which are included in > > > default Jira search. We could of course just add a label, but closing > > seems > > > clearer to me given that likely this ticket will not get comitter > > attention > > > in the foreseeable future. > > > > > > > I would like to avoid having to constantly fight against the bot. > It's > > > already responsible for the majority of my daily emails, with quite > > little > > > benefit for me personally. I initially thought that after some period > of > > > time it will settle down, but now I'm afraid it won't happen. > > > > > > Can you elaborate which rules you are running into mostly? I'd rather > > like > > > to understand how we work right now and where this conflicts with the > > Jira > > > bot vs slowly disabling the jira bot via labels. > > > > > > On Wed, Jun 23, 2021 at 10:00 AM Piotr Nowojski <pnowoj...@apache.org> > > > wrote: > > > > > > > Hi Konstantin, > > > > > > > > > In my opinion it is important that we close tickets eventually. > There > > > are > > > > a > > > > > lot of tickets (bugs, improvements, tech debt) that over time > became > > > > > irrelevant, out-of-scope, irreproducible, etc. In my experience, > > these > > > > > tickets are usually not closed by anyone but the bot. > > > > > > > > I agree there are such tickets, but I don't see how this is > addressing > > my > > > > concerns. There are also tickets that just shouldn't be closed as I > > > > described above. Why do you think that duplicating tickets and losing > > > > discussions/knowledge is a good solution? > > > > > > > > I would like to avoid having to constantly fight against the bot. > It's > > > > already responsible for the majority of my daily emails, with quite > > > little > > > > benefit for me personally. I initially thought that after some period > > of > > > > time it will settle down, but now I'm afraid it won't happen. Can we > > add > > > > some label to mark tickets to be ignored by the jira-bot? > > > > > > > > Best, > > > > Piotrek > > > > > > > > śr., 23 cze 2021 o 09:40 Chesnay Schepler <ches...@apache.org> > > > napisał(a): > > > > > > > > > I would like it to not unassign people if a PR is open. These are > > > > > usually blocked by the reviewer, not the assignee, and having the > > > > > assignees now additionally having to update JIRA periodically is a > > bit > > > > > like rubbing salt into the wound. > > > > > > > > > > On 6/23/2021 7:52 AM, Konstantin Knauf wrote: > > > > > > Hi everyone, > > > > > > > > > > > > I was hoping for more feedback from other committers, but seems > > like > > > > this > > > > > > is not happening, so here's my proposal for immediate changes: > > > > > > > > > > > > * Ignore tickets with a fixVersion for all rules but the > > > > stale-unassigned > > > > > > role. > > > > > > > > > > > > * We change the time intervals as follows, accepting reality a > bit > > > more > > > > > ;) > > > > > > > > > > > > * stale-assigned only after 30 days (instead of 14 days) > > > > > > * stale-critical only after 14 days (instead of 7 days) > > > > > > * stale-major only after 60 days (instead of 30 days) > > > > > > > > > > > > Unless there are -1s, I'd implement the changes Monday next week. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Konstantin > > > > > > > > > > > > On Thu, Jun 17, 2021 at 2:17 PM Piotr Nowojski < > > pnowoj...@apache.org > > > > > > > > > wrote: > > > > > > > > > > > >> Hi, > > > > > >> > > > > > >> I also think that the bot is a bit too aggressive/too quick with > > > > > assigning > > > > > >> stale issues/deprioritizing them, but that's not that big of a > > deal > > > > for > > > > > me. > > > > > >> > > > > > >> What bothers me much more is that it's closing minor issues > > > > > automatically. > > > > > >> Depriotising issues makes sense to me. If a wish for improvement > > or > > > a > > > > > bug > > > > > >> report has been opened a long time ago, and they got no > attention > > > over > > > > > the > > > > > >> time, sure depriotize them. But closing them is IMO a bad idea. > > Bug > > > > > might > > > > > >> be minor, but if it's not fixed it's still there - it shouldn't > be > > > > > closed. > > > > > >> Closing with "won't fix" should be done for very good reasons > and > > > very > > > > > >> rarely. Same applies to improvements/wishes. Furthermore, very > > often > > > > > >> descriptions and comments have a lot of value, and if we keep > > > closing > > > > > minor > > > > > >> issues I'm afraid that we end up with: > > > > > >> - more duplication. I doubt anyone will be looking for prior > > > "closed" > > > > > bug > > > > > >> reports/improvement requests. Definitely I'm only looking for > open > > > > > tickets > > > > > >> when looking if a ticket for XYZ already exists or not > > > > > >> - we will be losing knowledge > > > > > >> > > > > > >> Piotrek > > > > > >> > > > > > >> śr., 16 cze 2021 o 15:12 Robert Metzger <rmetz...@apache.org> > > > > > napisał(a): > > > > > >> > > > > > >>> Very sorry for the delayed response. > > > > > >>> > > > > > >>> Regarding tickets with the "test-instability" label (topic 1): > > I'm > > > > > >> usually > > > > > >>> assigning a fixVersion to the next release of the branch where > > the > > > > > >> failure > > > > > >>> occurred, when I'm opening a test failure ticket. Others seem > to > > do > > > > > that > > > > > >>> too. Hence my comment that not checking tickets with a > fixVersion > > > set > > > > > by > > > > > >>> Flink bot is good (because test failures should always stay > > > > "Critical" > > > > > >>> until we've understood what's going on) > > > > > >>> I see that it is a bit contradicting that Critical test > > > instabilities > > > > > >>> receive no attention for 14 days, but that seems to be the norm > > > given > > > > > the > > > > > >>> current number of incoming test instabilities. > > > > > >>> > > > > > >>> On Wed, Jun 16, 2021 at 2:05 PM Till Rohrmann < > > > trohrm...@apache.org> > > > > > >>> wrote: > > > > > >>> > > > > > >>>> Another example for category 4 would be the ticket where we > > > collect > > > > > >>>> breaking API changes for Flink 2.0 [1]. The idea behind this > > > ticket > > > > is > > > > > >> to > > > > > >>>> collect things to consider when developing the next major > > version. > > > > > >>>> Admittedly, we have never seen the benefits of collecting the > > > > breaking > > > > > >>>> changes because we haven't started Flink 2.x yet. Also, it is > > not > > > > > clear > > > > > >>> how > > > > > >>>> relevant these tickets are right now. > > > > > >>>> > > > > > >>>> [1] https://issues.apache.org/jira/browse/FLINK-3957 > > > > > >>>> > > > > > >>>> Cheers, > > > > > >>>> Till > > > > > >>>> > > > > > >>>> On Wed, Jun 16, 2021 at 11:42 AM Konstantin Knauf < > > > > kna...@apache.org> > > > > > >>>> wrote: > > > > > >>>> > > > > > >>>>> Hi everyone, > > > > > >>>>> > > > > > >>>>> thank you for all the feedback so far. I believe we have four > > > > > >> different > > > > > >>>>> topics by now: > > > > > >>>>> > > > > > >>>>> 1 about *test-instability tickets* raised by Robert. Waiting > > for > > > > > >>> feedback > > > > > >>>>> by Robert. > > > > > >>>>> > > > > > >>>>> 2 about *aggressiveness of stale-assigned *rule raised by > Timo. > > > > > >> Waiting > > > > > >>>>> for feedback by Timo and others. > > > > > >>>>> > > > > > >>>>> 3 about *excluding issues with a fixVersion* raised by > > > Konstantin, > > > > > >>> Till. > > > > > >>>>> Waiting for more feedback by the community as it involves > > general > > > > > >>> changes > > > > > >>>>> to how we deal with fixVersion. > > > > > >>>>> > > > > > >>>>> 4 about *excluding issues with a specific-label* raised by > > Arvid. > > > > > >>>>> > > > > > >>>>> I've already written something about 1-3. Regarding 4: > > > > > >>>>> > > > > > >>>>> How do we make sure that these don't become stale? I think, > > there > > > > > >> have > > > > > >>>>> been a few "long-term efforts" in the past that never got the > > > > > >> attention > > > > > >>>>> that we initially wanted. Is this just about the ability to > > > collect > > > > > >>>> tickets > > > > > >>>>> under an umbrella to document a future effort? Maybe for the > > > > example > > > > > >> of > > > > > >>>>> DataStream replacing DataSet how would this look like in > Jira? > > > > > >>>>> > > > > > >>>>> Cheers, > > > > > >>>>> > > > > > >>>>> Konstantin > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> On Tue, Jun 8, 2021 at 11:31 AM Till Rohrmann < > > > > trohrm...@apache.org> > > > > > >>>>> wrote: > > > > > >>>>> > > > > > >>>>>> I like this idea. It would then be the responsibility of the > > > > > >> component > > > > > >>>>>> maintainers to manage the lifecycle explicitly. > > > > > >>>>>> > > > > > >>>>>> Cheers, > > > > > >>>>>> Till > > > > > >>>>>> > > > > > >>>>>> On Mon, Jun 7, 2021 at 1:48 PM Arvid Heise < > ar...@apache.org> > > > > > >> wrote: > > > > > >>>>>>> One more idea for the bot. Could we have a label to exclude > > > > > >> certain > > > > > >>>>>> tickets > > > > > >>>>>>> from the life-cycle? > > > > > >>>>>>> > > > > > >>>>>>> I'm thinking about long-term tickets such as improving > > > DataStream > > > > > >> to > > > > > >>>>>>> eventually replace DataSet. We would collect ideas over the > > > next > > > > > >>>> couple > > > > > >>>>>> of > > > > > >>>>>>> weeks without any visible progress on the implementation. > > > > > >>>>>>> > > > > > >>>>>>> On Fri, May 21, 2021 at 2:06 PM Konstantin Knauf < > > > > > >> kna...@apache.org > > > > > >>>>>>> wrote: > > > > > >>>>>>> > > > > > >>>>>>>> Hi Timo, > > > > > >>>>>>>> > > > > > >>>>>>>> Thanks for joining the discussion. All rules except the > > > > > >> unassigned > > > > > >>>>>> rule > > > > > >>>>>>> do > > > > > >>>>>>>> not apply to Sub-Tasks actually (like deprioritization, > > > > > >> closing). > > > > > >>>>>>>> Additionally, activity on a Sub-Taks counts as activity > for > > > the > > > > > >>>>>> parent. > > > > > >>>>>>> So, > > > > > >>>>>>>> the parent ticket would not be touched by the bot as long > as > > > > > >> there > > > > > >>>> is > > > > > >>>>>> a > > > > > >>>>>>>> single Sub-Task that has a discussion or an update. If you > > > > > >>>> experience > > > > > >>>>>>>> something different, this is a bug. > > > > > >>>>>>>> > > > > > >>>>>>>> Is there a reason why it is important to assign all > > Sub-Tasks > > > to > > > > > >>> the > > > > > >>>>>> same > > > > > >>>>>>>> person immediately? I am not sure if this kind "reserving > > > > > >> tickets" > > > > > >>>> is > > > > > >>>>>> a > > > > > >>>>>>>> good idea in general to be honest. > > > > > >>>>>>>> > > > > > >>>>>>>> Cheers, > > > > > >>>>>>>> > > > > > >>>>>>>> Konstantin > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> On Fri, May 21, 2021 at 12:00 PM Timo Walther < > > > > > >> twal...@apache.org > > > > > >>>>>>> wrote: > > > > > >>>>>>>>> Hi Konstantin, > > > > > >>>>>>>>> > > > > > >>>>>>>>> thanks for starting this discussion. I was also about to > > > > > >> provide > > > > > >>>>>> some > > > > > >>>>>>>>> feedback because I have the feeling that the bot is too > > > > > >>> aggressive > > > > > >>>>>> at > > > > > >>>>>>>>> the moment. > > > > > >>>>>>>>> > > > > > >>>>>>>>> Even a 14 days interval is a short period of time for > > bigger > > > > > >>>> efforts > > > > > >>>>>>>>> that might include several subtasks. Currently, if we > split > > > an > > > > > >>>> issue > > > > > >>>>>>>>> into subtasks usually most subtasks are assigned to the > > same > > > > > >>>> person. > > > > > >>>>>>> But > > > > > >>>>>>>>> the bot requires us to update all subtasks again after 7 > > > days. > > > > > >>>>>> Could we > > > > > >>>>>>>>> disable the bot for subtasks or extend the period to 30 > > days? > > > > > >>>>>>>>> > > > > > >>>>>>>>> The core problem in the past was that we had issues > laying > > > > > >>> around > > > > > >>>>>>>>> untouched for years. Luckily, this is solved with the bot > > > now. > > > > > >>> But > > > > > >>>>>>> going > > > > > >>>>>>>>> from years to 7 days spams the mail box quite a bit. > > > > > >>>>>>>>> > > > > > >>>>>>>>> Regards, > > > > > >>>>>>>>> Timo > > > > > >>>>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>>>> On 21.05.21 09:22, Konstantin Knauf wrote: > > > > > >>>>>>>>>> Hi Robert, > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> Could you elaborate on your comment on test > instabilities? > > > > > >>> Would > > > > > >>>>>> test > > > > > >>>>>>>>>> instabilities always get a fixVersion then? > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> Background: Test instabilities are supposed to be > > Critical. > > > > > >>>>>> Critical > > > > > >>>>>>>>>> tickets are deprioritized if they are unassigned and > have > > > > > >> not > > > > > >>>>>>> received > > > > > >>>>>>>> an > > > > > >>>>>>>>>> update for 14 days. > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> Cheers, > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> Konstantin > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> On Thu, May 20, 2021 at 9:34 AM Robert Metzger < > > > > > >>>>>> rmetz...@apache.org> > > > > > >>>>>>>>> wrote: > > > > > >>>>>>>>>>> +1 > > > > > >>>>>>>>>>> This would also cover test instabilities, which I > > > > > >> personally > > > > > >>>>>> believe > > > > > >>>>>>>>> should > > > > > >>>>>>>>>>> not be auto-deprioritized until they've been analyzed. > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> On Wed, May 19, 2021 at 1:46 PM Till Rohrmann < > > > > > >>>>>> trohrm...@apache.org > > > > > >>>>>>>>>>> wrote: > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>>> I like this idea. +1 for your proposal Konstantin. > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> Cheers, > > > > > >>>>>>>>>>>> Till > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> On Wed, May 19, 2021 at 1:30 PM Konstantin Knauf < > > > > > >>>>>>>>>>> konstan...@ververica.com > > > > > >>>>>>>>>>>> wrote: > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>>> Hi everyone, > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> Till and I recently discussed whether we should > disable > > > > > >> the > > > > > >>>>>>>>>>>>> "stale-blocker", "stale-critical", "stale-major" and > > > > > >>>>>> "stale-minor" > > > > > >>>>>>>>>>> rules > > > > > >>>>>>>>>>>>> for tickets that have a fixVersion set. This would > > allow > > > > > >>>>>> people to > > > > > >>>>>>>>> plan > > > > > >>>>>>>>>>>> the > > > > > >>>>>>>>>>>>> upcoming release without tickets being deprioritized > by > > > > > >> the > > > > > >>>> bot > > > > > >>>>>>>> during > > > > > >>>>>>>>>>>> the > > > > > >>>>>>>>>>>>> release cycle. > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> From my point of view, this is a good idea as long > as > > > we > > > > > >>> can > > > > > >>>>>>> agree > > > > > >>>>>>>> to > > > > > >>>>>>>>>>> use > > > > > >>>>>>>>>>>>> the "fixVersion" a bit more conservatively. What do I > > > > > >> mean > > > > > >>> by > > > > > >>>>>>> that? > > > > > >>>>>>>> If > > > > > >>>>>>>>>>>> you > > > > > >>>>>>>>>>>>> would categorize tickets planned for an upcoming > > release > > > > > >>>> into: > > > > > >>>>>>>>>>>>> * Must Have > > > > > >>>>>>>>>>>>> * Should Have > > > > > >>>>>>>>>>>>> * Nice-To-Have > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> only "Must Have" and "Should Have" tickets should > get a > > > > > >>>>>>> fixVersion. > > > > > >>>>>>>>>>> From > > > > > >>>>>>>>>>>> my > > > > > >>>>>>>>>>>>> observation, we currently often set the fixVersion if > > we > > > > > >>> just > > > > > >>>>>>>> wished a > > > > > >>>>>>>>>>>>> feature was included in an upcoming release. > > Similarly, I > > > > > >>>> often > > > > > >>>>>>> see > > > > > >>>>>>>>>>> bulk > > > > > >>>>>>>>>>>>> changes of fixVersion that "roll over" many tickets > to > > > > > >> the > > > > > >>>> next > > > > > >>>>>>>>> release > > > > > >>>>>>>>>>>> if > > > > > >>>>>>>>>>>>> they have not made into the previous release although > > > > > >> there > > > > > >>>> is > > > > > >>>>>> no > > > > > >>>>>>>>>>>> concrete > > > > > >>>>>>>>>>>>> plan to fix them or they have even become obsolete by > > > > > >> then. > > > > > >>>>>>>> Excluding > > > > > >>>>>>>>>>>> those > > > > > >>>>>>>>>>>>> from the bot would be counterproductive. > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> What do you think? > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> Cheers, > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> Konstantin > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> On Fri, Apr 23, 2021 at 2:25 PM Konstantin Knauf < > > > > > >>>>>>> kna...@apache.org > > > > > >>>>>>>>>>>>> wrote: > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>> Hi everyone, > > > > > >>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>> After some offline conversations, I think, it makes > > > > > >> sense > > > > > >>> to > > > > > >>>>>>>> already > > > > > >>>>>>>>>>>> open > > > > > >>>>>>>>>>>>>> this thread now in order to collect feedback and > > > > > >>> suggestions > > > > > >>>>>>> around > > > > > >>>>>>>>>>> the > > > > > >>>>>>>>>>>>>> Jira Bot. > > > > > >>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>> The following two changes I will do right away: > > > > > >>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>> * increase "stale-assigned.stale-days" to 14 days > > > > > >> (Marta, > > > > > >>>>>>> Stephan, > > > > > >>>>>>>>>>> Nico > > > > > >>>>>>>>>>>>>> have provided feedback that this is too aggressive). > > > > > >>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>> * exclude Sub-Tasks from all rules except the > > > > > >>>> "stale-assigned" > > > > > >>>>>>> rule > > > > > >>>>>>>>>>> (I > > > > > >>>>>>>>>>>>>> think, this was just an oversight in the original > > > > > >>>> discussion.) > > > > > >>>>>>>>>>>>>> Keep it coming. > > > > > >>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>> Cheers, > > > > > >>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>> Konstantin > > > > > >>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>> -- > > > > > >>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>> Konstantin Knauf > > > > > >>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>> https://twitter.com/snntrable > > > > > >>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>> https://github.com/knaufk > > > > > >>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> -- > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> Konstantin Knauf | Head of Product > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> +49 160 91394525 > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> Follow us @VervericaData Ververica < > > > > > >>>> https://www.ververica.com/ > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> -- > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> Join Flink Forward <https://flink-forward.org/> - > The > > > > > >>> Apache > > > > > >>>>>>> Flink > > > > > >>>>>>>>>>>>> Conference > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> Stream Processing | Event Driven | Real Time > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> -- > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, > > > > > >>> Germany > > > > > >>>>>>>>>>>>> -- > > > > > >>>>>>>>>>>>> Ververica GmbH > > > > > >>>>>>>>>>>>> Registered at Amtsgericht Charlottenburg: HRB 158244 > B > > > > > >>>>>>>>>>>>> Managing Directors: Yip Park Tung Jason, Jinwei > (Kevin) > > > > > >>>> Zhang, > > > > > >>>>>>> Karl > > > > > >>>>>>>>>>> Anton > > > > > >>>>>>>>>>>>> Wehner > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>>> -- > > > > > >>>>>>>> > > > > > >>>>>>>> Konstantin Knauf > > > > > >>>>>>>> > > > > > >>>>>>>> https://twitter.com/snntrable > > > > > >>>>>>>> > > > > > >>>>>>>> https://github.com/knaufk > > > > > >>>>>>>> > > > > > >>>>> > > > > > >>>>> -- > > > > > >>>>> > > > > > >>>>> Konstantin Knauf > > > > > >>>>> > > > > > >>>>> https://twitter.com/snntrable > > > > > >>>>> > > > > > >>>>> https://github.com/knaufk > > > > > >>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Konstantin Knauf | Head of Product > > > > > > +49 160 91394525 > > > > > > > > > Follow us @VervericaData Ververica <https://www.ververica.com/> > > > > > > > > > -- > > > > > > Join Flink Forward <https://flink-forward.org/> - The Apache Flink > > > Conference > > > > > > Stream Processing | Event Driven | Real Time > > > > > > -- > > > > > > Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, Germany > > > > > > -- > > > Ververica GmbH > > > Registered at Amtsgericht Charlottenburg: HRB 158244 B > > > Managing Directors: Yip Park Tung Jason, Jinwei (Kevin) Zhang, Karl > Anton > > > Wehner > > > > > >
