http://deprecated-apache-flink-mailing-list-archive.368.s1.nabble.com/DISCUSS-Feedback-Collection-Jira-Bot-tp50389p51440.html
breaking API changes for Flink 2.0 [1]. The idea behind this ticket is to
changes because we haven't started Flink 2.x yet. Also, it is not clear how
> 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>