I agree with Chesnay that we also used Blocker as a kind of reminder for things which should happen but are not super time critical. Other examples are for example the deprecation of APIs or changing of default values. I admit that these examples could also be changed right away and wouldn't benefit from postponing their change to a later date.
If we change how we use fixVersion or introduce a new label, then this could be solved. Cheers, Till On Fri, Mar 26, 2021 at 11:24 AM Chesnay Schepler <ches...@apache.org> wrote: > FLINK-21152 is special because we usually know quite early that it must > be done (e.g., because we bump some dependency in flink-shaded at the > start of the release cycle), but only do it shortly before a release to > avoid wasting time on multiple flink-shaded release cycles for a single > Flink release. > > I don't think there are many instances of such issues. > > On 3/26/2021 11:11 AM, Konstantin Knauf wrote: > > My proposal does not have an answer for this. > > > > Is "Blocker" often used for this, right now? What is special about > > FLINK-21152 compared to other important bug fixes/features for the > > release that makes it a Blocker? > > > > It also ties a bit into the question of what "fixVersion" means. I > > think, right now it means something like "targeted for this release" > > ranging from "basically a must have" and "would be nice if someone > > picks it up". If "fixVersion" would mean "there is a concrete plan to > > have this in the release", it might be less of a problem. > > > > > > > > On Fri, Mar 26, 2021 at 11:03 AM Chesnay Schepler <ches...@apache.org > > <mailto:ches...@apache.org>> wrote: > > > > That's a fair point, but then that raises the question how tasks > > are documented that /must/ be done for a release /at some point/. > > The current approach allows me to easily setup a signal for the > > Release Manager that this ticket must be completed. How would that > > work in your proposal? > > > > On 3/26/2021 9:18 AM, Konstantin Knauf wrote: > >> Hi Chesnay, > >> > >> a blocker is currently defined in the Flink Confluence as a "needs > to be > >> resolved before a release (matched based on fix versions)" whereas > I was > >> thinking of it as a "someone needs to stop their work to fix this" > kind of > >> thing. In the proposal I shared a blocker is therefore defined as > >> "infrastructure > >> failures, bugs that block a release". With this definition > FLINK-21152 > >> would not be blocker, or would it? Cheers, Konstantin > >> > >> On Fri, Mar 26, 2021 at 8:55 AM Chesnay Schepler<ches...@apache.org> > <mailto:ches...@apache.org> wrote: > >> > >>> FLINK-21152 is an example of a blocker issue that can remain stale > for > >>> months. > >>> > >>> On 3/26/2021 8:46 AM, Konstantin Knauf wrote: > >>>> Hi Arvid, > >>>> > >>>> I agree that this should never happen for blockers. My thinking > was that > >>> if > >>>> an unassigned blocker is deprioritized after 1 day it also forces > us to > >>>> find someone to work on the blocker right away, which we should > do anyway > >>>> if it is blocker. > >>>> > >>>> Thanks, > >>>> > >>>> Konstantin > >>>> > >>>> On Fri, Mar 26, 2021 at 8:40 AM Arvid Heise<ar...@apache.org> > <mailto:ar...@apache.org> wrote: > >>>> > >>>>> +1 from my side. > >>>>> > >>>>> I would have probably never deprioritized blockers > automatically. Just > >>>>> because there is no activity doesn't mean that the nature of the > ticket > >>>>> changes (blockers are quite special). However, as blockers are by > >>>>> definition resolved with urgency, I also cannot imagine a > blocker going > >>>>> completely stale, so we probably talk about something that never > >>> happens in > >>>>> reality. For other tickets, it makes sense. > >>>>> > >>>>> On Tue, Mar 23, 2021 at 8:09 AM Konstantin Knauf< > kna...@apache.org> <mailto:kna...@apache.org> > >>>>> wrote: > >>>>> > >>>>>> Hi everyone, > >>>>>> > >>>>>> The discussion has stalled a bit on this thread. I would > proceed to a > >>>>> vote > >>>>>> on the currently documented proposal tomorrow if there are no > further > >>>>>> concerns or opinions. > >>>>>> > >>>>>> Best, > >>>>>> > >>>>>> Konstantin > >>>>>> > >>>>>> On Fri, Mar 12, 2021 at 5:24 PM Konstantin Knauf< > kna...@apache.org> <mailto:kna...@apache.org> > >>>>>> wrote: > >>>>>> > >>>>>>> Hi Leonard, > >>>>>>> > >>>>>>> Thank you for your feedback. > >>>>>>> > >>>>>>> Re Notifications: The bot would write a comment that would > notify > >>>>>>> assignee, reporter and watchers. Probably, we could change the > >>>>>>> notifications not to notify watchers on comments, but this > would also > >>>>>>> affect regular comments. Generally, I'd argue that if you are > an > >>>>>>> assignee/reporter/watcher you want to know when the ticket is > about to > >>>>>>> become stale or deprioritized. > >>>>>>> > >>>>>>> Re Technical Debt: There is no getting around the fact that > there is > >>>>>>> technical debt. There is technical debt in every software > project of > >>>>> the > >>>>>>> size and age of Apache Flink. The idea of the issue type is to > make > >>>>> this > >>>>>>> explicit and to encourage developers to document technical > debt, so > >>>>> that > >>>>>> it > >>>>>>> can be more easily prioritized and eventually be addressed. > For users, > >>>>>> the > >>>>>>> advantage is to tell features and technical debt apart. Users > are > >>>>>> probably > >>>>>>> only interested in features that change the user-facing > behavior of > >>>>>> Apache > >>>>>>> Flink. I'd be curious to hear other opinions on whether > developers > >>>>> would > >>>>>> be > >>>>>>> reluctant to report technical debt publicly. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Konstantin > >>>>>>> > >>>>>>> On Tue, Mar 9, 2021 at 9:20 AM Leonard Xu<xbjt...@gmail.com> > <mailto:xbjt...@gmail.com> wrote: > >>>>>>> > >>>>>>>> Thanks Konstantin for driving this topic. > >>>>>>>> > >>>>>>>> Generally +1 for the proposal, I went through the doc and > have two > >>>>>>>> concerns here. > >>>>>>>> > >>>>>>>> Will the robot send all notifications to > assignee/reporter/watchers ? > >>>>>>>> I’m a little worried about too many push messages. > Eg, I > >>>>> watched > >>>>>>>> some issues that I want to know about, but according to this > rule, I > >>>>>> will > >>>>>>>> also receive lots of pushed messages. > >>>>>>>> Could we add push stratey for > assignee/reporter/watcher > >>> role? > >>>>>>>> For the proposed new issue type Technical Debt, I don't think > >>>>> developers > >>>>>>>> are inclined to choose this kind of issue, and I don't like > the name > >>>>>> very > >>>>>>>> much because it can be seen/reported by users. > >>>>>>>> > >>>>>>>> Best, > >>>>>>>> Leonard > >>>>>>>> > >>>>>>>>> 在 2021年3月8日，10:28，Xintong Song<tonysong...@gmail.com> > <mailto:tonysong...@gmail.com> 写道： > >>>>>>>>> > >>>>>>>>> Thanks for the updates, Konstantin. > >>>>>>>>> > >>>>>>>>> The changes look good to me. > >>>>>>>>> > >>>>>>>>> Minor: > >>>>>>>>> - typo: The last two `auto-deprioritized-blocker` in rule 1 > details > >>>>>>>> should > >>>>>>>>> be `auto-deprioritized-critical/major`. > >>>>>>>>> > >>>>>>>>> Thank you~ > >>>>>>>>> > >>>>>>>>> Xintong Song > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Fri, Mar 5, 2021 at 7:33 PM Konstantin Knauf< > kna...@apache.org> <mailto:kna...@apache.org> > >>>>>>>> wrote: > >>>>>>>>>> Hi everyone, > >>>>>>>>>> > >>>>>>>>>> Thank you for all the comments so far. As proposed, I have > dropped > >>>>>> the > >>>>>>>>>> "Trivial" Priority. > >>>>>>>>>> > >>>>>>>>>> I also added another section "Rules in Detail" to the > document > >>>>> adding > >>>>>>>> some > >>>>>>>>>> concrete numbers & labels that implement the rules. As a > TLDR, here > >>>>>> is > >>>>>>>> an > >>>>>>>>>> example of the flow for a "Blocker", that is created and > assigned > >>>>> to > >>>>>> a > >>>>>>>>>> user, but never receives any updates afterwards. > >>>>>>>>>> > >>>>>>>>>> Day > >>>>>>>>>> > >>>>>>>>>> Status > >>>>>>>>>> > >>>>>>>>>> Priority > >>>>>>>>>> > >>>>>>>>>> Labels > >>>>>>>>>> > >>>>>>>>>> 0 > >>>>>>>>>> > >>>>>>>>>> Open > >>>>>>>>>> > >>>>>>>>>> Blocker > >>>>>>>>>> > >>>>>>>>>> 7 > >>>>>>>>>> > >>>>>>>>>> Open > >>>>>>>>>> > >>>>>>>>>> Blocker > >>>>>>>>>> > >>>>>>>>>> stale-assigned > >>>>>>>>>> > >>>>>>>>>> 14 > >>>>>>>>>> > >>>>>>>>>> Open > >>>>>>>>>> > >>>>>>>>>> Blocker > >>>>>>>>>> > >>>>>>>>>> auto-unassigned > >>>>>>>>>> > >>>>>>>>>> 15 > >>>>>>>>>> > >>>>>>>>>> Open > >>>>>>>>>> > >>>>>>>>>> Blocker > >>>>>>>>>> > >>>>>>>>>> auto-unassigned, stale-blocker > >>>>>>>>>> > >>>>>>>>>> 22 > >>>>>>>>>> > >>>>>>>>>> Open > >>>>>>>>>> > >>>>>>>>>> Critical > >>>>>>>>>> > >>>>>>>>>> auto-unassigned, auto-deprioritized-blocker > >>>>>>>>>> > >>>>>>>>>> 29 > >>>>>>>>>> > >>>>>>>>>> Open > >>>>>>>>>> > >>>>>>>>>> Critical > >>>>>>>>>> > >>>>>>>>>> auto-unassigned, auto-deprioritized-blocker, stale-critical > >>>>>>>>>> > >>>>>>>>>> 36 > >>>>>>>>>> > >>>>>>>>>> Open > >>>>>>>>>> > >>>>>>>>>> Major > >>>>>>>>>> > >>>>>>>>>> auto-unassigned, auto-deprioritized-blocker, > >>>>>>>> auto-deprioritized-critical > >>>>>>>>>> 66 > >>>>>>>>>> > >>>>>>>>>> Open > >>>>>>>>>> > >>>>>>>>>> Major > >>>>>>>>>> > >>>>>>>>>> auto-unassigned, auto-deprioritized-blocker, > >>>>>>>> auto-deprioritized-critical, > >>>>>>>>>> stale-major > >>>>>>>>>> > >>>>>>>>>> 73 > >>>>>>>>>> > >>>>>>>>>> Open > >>>>>>>>>> > >>>>>>>>>> Minor > >>>>>>>>>> > >>>>>>>>>> auto-unassigned, auto-deprioritized-blocker, > >>>>>>>> auto-deprioritized-critical, > >>>>>>>>>> auto-deprioritized-major > >>>>>>>>>> > >>>>>>>>>> 263 > >>>>>>>>>> > >>>>>>>>>> Open > >>>>>>>>>> > >>>>>>>>>> Minor > >>>>>>>>>> > >>>>>>>>>> auto-unassigned, auto-deprioritized-blocker, > >>>>>>>> auto-deprioritized-critical, > >>>>>>>>>> auto-deprioritized-major, stale-minor > >>>>>>>>>> > >>>>>>>>>> 270 > >>>>>>>>>> > >>>>>>>>>> Closed > >>>>>>>>>> > >>>>>>>>>> Minor > >>>>>>>>>> > >>>>>>>>>> auto-unassigned, auto-deprioritized-blocker, > >>>>>>>> auto-deprioritized-critical, > >>>>>>>>>> auto-deprioritized-major, auto-closed > >>>>>>>>>> > >>>>>>>>>> I am looking forward to further comments and would otherwise > >>>>> proceed > >>>>>>>> to a > >>>>>>>>>> vote towards the end of next week. > >>>>>>>>>> > >>>>>>>>>> Cheers, > >>>>>>>>>> > >>>>>>>>>> Konstantin > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Tue, Mar 2, 2021 at 3:45 PM Robert Metzger < > rmetz...@apache.org <mailto:rmetz...@apache.org> > >>>>>>>> wrote: > >>>>>>>>>>> Thanks a lot for the proposal! > >>>>>>>>>>> > >>>>>>>>>>> +1 for doing it! > >>>>>>>>>>> > >>>>>>>>>>> On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman < > >>>>>>>>>>> khachatryan.ro...@gmail.com <mailto: > khachatryan.ro...@gmail.com>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Hi Konstantin, > >>>>>>>>>>>> > >>>>>>>>>>>> I think we should try it out. > >>>>>>>>>>>> Even if tickets don't work well it can be a good step > towards > >>>>>>>> managing > >>>>>>>>>>>> technical debt in some other way, like wiki. > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks! > >>>>>>>>>>>> > >>>>>>>>>>>> Regards, > >>>>>>>>>>>> Roman > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Tue, Mar 2, 2021 at 9:32 AM Dawid Wysakowicz < > >>>>>>>>>> dwysakow...@apache.org <mailto:dwysakow...@apache.org>> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> I'd be fine with dropping the "Trivial" priority in > favour of > >>>>>>>>>> "starter" > >>>>>>>>>>>>> label. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Best, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Dawid > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 01/03/2021 11:53, Konstantin Knauf wrote: > >>>>>>>>>>>>>> Hi Dawid, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks for the feedback. Do you think we should simply > get rid > >>>>> of > >>>>>>>>>> the > >>>>>>>>>>>>>> "Trivial" priority then and use the "starter" label more > >>>>>>>>>>> aggressively? > >>>>>>>>>>>>>> Best, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Konstantin > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz < > >>>>>>>>>>>> dwysakow...@apache.org <mailto:dwysakow...@apache.org> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi Konstantin, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I also like the idea. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Two comments: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> * you describe the "Trivial" priority as one that > needs to be > >>>>>>>>>>>>>>> implemented immediately. First of all it is not used > to often, > >>>>>>>>>> but I > >>>>>>>>>>>>>>> think the way it works now is similar with a "starter" > label. > >>>>>>>>>> Tasks > >>>>>>>>>>>> that > >>>>>>>>>>>>>>> are not bugs, are easy to implement and we think they > are fine > >>>>>> to > >>>>>>>>>> be > >>>>>>>>>>>>>>> taken by newcomers. Therefore they do not fall in my > mind into > >>>>>>>>>>>>>>> "immediately" category. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> * I would still deprioritise test instabilities. I > think there > >>>>>>>>>>>> shouldn't > >>>>>>>>>>>>>>> be a problem with that. We do post links to all > failures > >>>>>> therefore > >>>>>>>>>>> it > >>>>>>>>>>>>>>> will automatically priortise the tasks according to > failure > >>>>>>>>>>>> frequencies. > >>>>>>>>>>>>>>> Best, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Dawid > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 01/03/2021 09:38, Konstantin Knauf wrote: > >>>>>>>>>>>>>>>> Hi Xintong, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> yes, such labels would make a lot of sense. I added a > >>>>> sentence > >>>>>> to > >>>>>>>>>>> the > >>>>>>>>>>>>>>>> document. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Konstantin > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Mon, Mar 1, 2021 at 8:51 AM Xintong Song < > >>>>>>>>>> tonysong...@gmail.com <mailto:tonysong...@gmail.com> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>> Thanks for driving this discussion, Konstantin. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I like the idea of having a bot reminding > >>>>>>>>>>> reporter/assignee/watchers > >>>>>>>>>>>>>>> about > >>>>>>>>>>>>>>>>> inactive tickets and if needed downgrade/close them > >>>>>>>>>> automatically. > >>>>>>>>>>>>>>>>> My two cents: > >>>>>>>>>>>>>>>>> We may have labels like "downgraded-by-bot" / > >>>>> "closed-by-bot", > >>>>>>>>>> so > >>>>>>>>>>>> that > >>>>>>>>>>>>>>> it's > >>>>>>>>>>>>>>>>> easier to filter and review tickets updated by the > bot. > >>>>>>>>>>>>>>>>> We may want to review such tickets (e.g., monthly) > in case a > >>>>>>>>>> valid > >>>>>>>>>>>>>>> ticket > >>>>>>>>>>>>>>>>> failed to draw the attention of relevant committers > and the > >>>>>>>>>>> reporter > >>>>>>>>>>>>>>>>> doesn't know who to ping. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thank you~ > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Xintong Song > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann < > >>>>>>>>>>> trohrm...@apache.org <mailto:trohrm...@apache.org> > >>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Thanks for starting this discussion Konstantin. I > like your > >>>>>>>>>>>> proposal > >>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>> also the idea of automating the tedious parts of it > via a > >>>>>> bot. > >>>>>>>>>>>>>>>>>> Cheers, > >>>>>>>>>>>>>>>>>> Till > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf < > >>>>>>>>>>>> kna...@apache.org <mailto:kna...@apache.org>> > >>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Dear Flink Community, > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> I would like to start a discussion on improving > and to > >>>>> some > >>>>>>>>>>> extent > >>>>>>>>>>>>>>>>> simply > >>>>>>>>>>>>>>>>>>> defining the way we work with Jira. Some aspects > have been > >>>>>>>>>>>>> discussed a > >>>>>>>>>>>>>>>>>>> while back [1], but I would like to go a bit > beyond that > >>>>>> with > >>>>>>>>>>> the > >>>>>>>>>>>>>>>>>> following > >>>>>>>>>>>>>>>>>>> goals in mind: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> - > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> clearer communication and expectation > management with > >>>>> the > >>>>>>>>>>>>> community > >>>>>>>>>>>>>>>>>>> - > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> a user or contributor should be able to > judge the > >>>>>>>>>> urgency > >>>>>>>>>>>> of a > >>>>>>>>>>>>>>>>>> ticket > >>>>>>>>>>>>>>>>>>> by its priority > >>>>>>>>>>>>>>>>>>> - > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> if a ticket is assigned to someone the > expectation > >>>>> that > >>>>>>>>>>>>> someone > >>>>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>> working on it should hold > >>>>>>>>>>>>>>>>>>> - > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> generally reduce noise in Jira > >>>>>>>>>>>>>>>>>>> - > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> reduce overhead of committers to ask about > status > >>>>> updates > >>>>>>>>>> of > >>>>>>>>>>>>>>>>>>> contributions or bug reports > >>>>>>>>>>>>>>>>>>> - > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> “Are you still working on this?” > >>>>>>>>>>>>>>>>>>> - > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> “Are you still interested in this?” > >>>>>>>>>>>>>>>>>>> - > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> “Does this still happen on Flink 1.x?” > >>>>>>>>>>>>>>>>>>> - > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> “Are you still experiencing this issue?” > >>>>>>>>>>>>>>>>>>> - > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> “What is the status of the implementation”? > >>>>>>>>>>>>>>>>>>> - > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> while still encouraging users to add new > tickets and to > >>>>>>>>>> leave > >>>>>>>>>>>>>>>>> feedback > >>>>>>>>>>>>>>>>>>> about existing tickets > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Please see the full proposal here: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>> > https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit# > < > https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit# > > > >>>>>>>>>>>>>>>>>>> . > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> The idea would be to discuss this proposal in this > thread. > >>>>>> If > >>>>>>>>>> we > >>>>>>>>>>>>> come > >>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>>>> conclusion, I'd document the proposal in the wiki > [2] and > >>>>> we > >>>>>>>>>>> would > >>>>>>>>>>>>>>> then > >>>>>>>>>>>>>>>>>>> vote on it (approval by "Lazy Majority"). > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Cheers, > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Konstantin > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> [1] > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>> > https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E > < > https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E > > > >>>>>>>>>>>>>>>>>>> [2] > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>> > https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions > < > https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions > > > >>>>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Konstantin Knauf > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> https://twitter.com/snntrable < > https://twitter.com/snntrable> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> https://github.com/knaufk < > https://github.com/knaufk> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> > >>>>>>>>>> Konstantin Knauf > >>>>>>>>>> > >>>>>>>>>> https://twitter.com/snntrable < > https://twitter.com/snntrable> > >>>>>>>>>> > >>>>>>>>>> https://github.com/knaufk <https://github.com/knaufk> > >>>>>>>>>> > >>>>>>> -- > >>>>>>> > >>>>>>> Konstantin Knauf > >>>>>>> > >>>>>>> https://twitter.com/snntrable <https://twitter.com/snntrable> > >>>>>>> > >>>>>>> https://github.com/knaufk <https://github.com/knaufk> > >>>>>>> > >>>>>> -- > >>>>>> > >>>>>> Konstantin Knauf > >>>>>> > >>>>>> https://twitter.com/snntrable <https://twitter.com/snntrable> > >>>>>> > >>>>>> https://github.com/knaufk <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 > > FlinkConference > > > > Stream Processing | Event Driven | Real Time > > > > -- > > > > Ververica GmbH| Invalidenstrasse 115, 10115 Berlin, Germany > > > > -- > > > > Ververica GmbHRegistered at Amtsgericht Charlottenburg: HRB 158244 > > BManaging Directors: Yip Park Tung Jason, Jinwei (Kevin) Zhang, Karl > > Anton Wehner > > >
