http://deprecated-apache-flink-mailing-list-archive.368.s1.nabble.com/DISCUSS-Feedback-Collection-Jira-Bot-tp50389p51446.html
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
> 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 <
[hidden email]>
> 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 <
[hidden email]>
> > 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 <
[hidden email]> 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 <
[hidden email]>
> >> > 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 <
[hidden email]>
> >> > 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 <
> >>
[hidden email]>
> >> > > > 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 <
> >>
[hidden email]
> >> > >
> >> > > > >> wrote:
> >> > > > >>
> >> > > > >>> I like this idea. +1 for your proposal Konstantin.
> >> > > > >>>
> >> > > > >>> Cheers,
> >> > > > >>> Till
> >> > > > >>>
> >> > > > >>> On Wed, May 19, 2021 at 1:30 PM Konstantin Knauf <
> >> > > > >>
[hidden email]
> >> > > > >>>>
> >> > > > >>> 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 <
> >> >
[hidden email]
> >> > > >
> >> > > > >>>> 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> >
>