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
https://twitter.com/snntrable
https://github.com/knaufk
