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
