[DISCUSS] Semantics of our JIRA fields

[Zhu Zhu]

This is very helpful!
+1

Thanks,
Zhu Zhu

Yang Wang <[hidden email]> 于2020年5月25日周一 下午4:04写道：

> +1 from this useful proposal.
>
> This makes me clearer about "Resolve" and "Close" since I used to be
> confused by this two button.
>
> Best,
> Yang
>
> Jingsong Li <[hidden email]> 于2020年5月25日周一 下午3:10写道：
>
> > +1 for the proposal.
> > It makes me clearer.
> >
> > Best,
> > Jingsong Lee
> >
> > On Mon, May 25, 2020 at 2:51 PM Zhijiang <[hidden email]
> > .invalid>
> > wrote:
> >
> > > Thanks for launching this discussion and giving so detailed infos,
> > > Robert!  +1 on my side for the proposal.
> > >
> > > For "Affects Version", I previously thought it was only for the already
> > > released versions, so it can give a reminder that the fix should also
> > pick
> > > into the related released branches for future minor versions.
> > > I saw that Jark had somehow similar concerns for this field in below
> > > replies.  Either way makes sense for me as long as we give a determined
> > > rule in Wiki.
> > >
> > > Re Flavio' s comments, I agree that the Jira reporter can leave most of
> > > the fields empty if not confirmed of them, then the respective
> component
> > > maintainer or committer can update them accordingly later.
> > > But the state of Jira should not be marked as "resolved" when the PR is
> > > detected, that is not fitting into the resolved semantic I guess. If
> > > possible, the Jira can be updated as "in progress" automatically if
> > > the respective PR is ready, then it will save some time to stat
> progress
> > > of related issues during release process.
> > >
> > > Best,
> > > Zhijiang
> > > ------------------------------------------------------------------
> > > From:Congxian Qiu <[hidden email]>
> > > Send Time:2020年5月25日(星期一) 13:57
> > > To:[hidden email] <[hidden email]>
> > > Subject:Re: [DISCUSS] Semantics of our JIRA fields
> > >
> > > Hi
> > >
> > > Currently, when I'm going to create an issue for Project-website. I'm
> not
> > > very sure what the "Affect Version/s" should be set. The problem is
> that
> > > the current Dockfile[1] in flink-web is broken because of the EOL of
> > Ubuntu
> > > 18.10[2], the project-web does not affect any release of Flink, it does
> > > affect the process to build website, so what's the version should I set
> > to?
> > >
> > > [1]
> > >
> > >
> >
> https://github.com/apache/flink-web/blob/bc66f0f0f463ab62a22e81df7d7efd301b76a6b4/docker/Dockerfile#L17
> > > [2] https://wiki.ubuntu.com/Releases
> > >
> > > Best,
> > > Congxian
> > >
> > >
> > > Flavio Pompermaier <[hidden email]> 于2020年5月24日周日 下午1:23写道：
> > >
> > > > In my experience it's quite complicated for a normal reporter to be
> > able
> > > to
> > > > fill all the fields correctly (especially for new users).
> > > > Usually you just wanto to report a problem, remember to add a new
> > feature
> > > > or improve code/documentation but you can't really give a priority,
> > > assign
> > > > the correct label or decide which releases will benefit of the
> fix/new
> > > > feature. This is something that only core developers could decide
> > (IMHO).
> > > >
> > > > My experiece says that it's better if normal users could just open
> > > tickets
> > > > with some default (or mark ticket as new) and leave them in such a
> > state
> > > > until an experienced user, one that can assign tickets, have the time
> > to
> > > > read it and immediately reject the ticket or accept it and properly
> > > assign
> > > > priorities, fix version, etc.
> > > >
> > > > With respect to resolve/close I think that a good practice could be
> to
> > > mark
> > > > automatically a ticket as resolved once that a PR is detected for
> that
> > > > ticket, while marking it as closed should be done by the commiter who
> > > merge
> > > > the PR.
> > > >
> > > > Probably this process would slightly increase the work of a committer
> > but
> > > > this would make things a lot cleaner and will bring the benefit of
> > > having a
> > > > reliable and semantically sound JIRA state.
> > > >
> > > > Cheers,
> > > > Flavio
> > > >
> > > > Il Dom 24 Mag 2020, 05:05 Israel Ekpo <[hidden email]> ha
> > scritto:
> > > >
> > > > > +1 for the proposal
> > > > >
> > > > > This will bring some consistency to the process
> > > > >
> > > > > Regarding Closed vs Resolved, should we go back and switch all the
> > > > Resolved
> > > > > issues to Closed so that is is not confusing to new people to the
> > > project
> > > > > in the future that may not have seen this discussion?
> > > > >
> > > > > I would recommend changing it to Closed just to be consistent since
> > > that
> > > > is
> > > > > the majority and the new process will be using Closed going forward
> > > > >
> > > > > Those are my thoughts for now
> > > > >
> > > > > On Sat, May 23, 2020 at 7:48 AM Congxian Qiu <
> [hidden email]
> > >
> > > > > wrote:
> > > > >
> > > > > > +1 for the proposal. It's good to have a unified description and
> > > write
> > > > it
> > > > > > down in the wiki, so that every contributor has the same
> > > understanding
> > > > of
> > > > > > all the fields.
> > > > > >
> > > > > > Best,
> > > > > > Congxian
> > > > > >
> > > > > >
> > > > > > Till Rohrmann <[hidden email]> 于2020年5月23日周六 上午12:04写道：
> > > > > >
> > > > > > > Thanks for drafting this proposal Robert. +1 for the proposal.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Till
> > > > > > >
> > > > > > > On Fri, May 22, 2020 at 5:39 PM Leonard Xu <[hidden email]>
> > > > wrote:
> > > > > > >
> > > > > > > > Thanks bringing up this topic @Robert,  +1 to the proposal.
> > > > > > > >
> > > > > > > > It clarifies the JIRA fields well and should be a rule to
> > follow.
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > Leonard Xu
> > > > > > > > > 在 2020年5月22日，20:24，Aljoscha Krettek <[hidden email]>
> > 写道：
> > > > > > > > >
> > > > > > > > > +1 That's also how I think of the semantics of the fields.
> > > > > > > > >
> > > > > > > > > Aljoscha
> > > > > > > > >
> > > > > > > > > On 22.05.20 08:07, Robert Metzger wrote:
> > > > > > > > >> Hi all,
> > > > > > > > >> I have the feeling that the semantics of some of our JIRA
> > > fields
> > > > > > > (mostly
> > > > > > > > >> "affects versions", "fix versions" and resolve / close)
> are
> > > not
> > > > > > > defined
> > > > > > > > in
> > > > > > > > >> the same way by all the core Flink contributors, which
> leads
> > > to
> > > > > > cases
> > > > > > > > where
> > > > > > > > >> I spend quite some time on filling the fields correctly
> (at
> > > > least
> > > > > > > what I
> > > > > > > > >> consider correctly), and then others changing them again
> to
> > > > match
> > > > > > > their
> > > > > > > > >> semantics.
> > > > > > > > >> In an effort to increase our efficiency, and since I'm
> > > creating
> > > > a
> > > > > > lot
> > > > > > > of
> > > > > > > > >> (test instability-related) tickets these days, I would
> like
> > to
> > > > > > discuss
> > > > > > > > the
> > > > > > > > >> semantics, come to a conclusion and document this in our
> > Wiki.
> > > > > > > > >> *Proposal:*
> > > > > > > > >> *Priority:*
> > > > > > > > >> "Blocker": needs to be resolved before a release (matched
> > > based
> > > > on
> > > > > > fix
> > > > > > > > >> versions)
> > > > > > > > >> "Critical": strongly considered before a release
> > > > > > > > >> other priorities have no practical meaning in Flink.
> > > > > > > > >> *Component/s:*
> > > > > > > > >> Primary component relevant for this feature / fix.
> > > > > > > > >> For test-related issues, add the component the test
> belongs
> > to
> > > > > (for
> > > > > > > > example
> > > > > > > > >> "Connectors / Kafka" for Kafka test failures) + "Test".
> > > > > > > > >> The same applies for documentation tickets. For example,
> if
> > > > > there's
> > > > > > > > >> something wrong with the DataStream API, add it to the
> "API
> > /
> > > > > > > > DataStream"
> > > > > > > > >> and "Documentation" components.
> > > > > > > > >> *Affects Version/s:*Only for Bug / Task-type tickets: We
> > list
> > > > all
> > > > > > > > currently
> > > > > > > > >> supported and unreleased Flink versions known to be
> affected
> > > by
> > > > > > this.
> > > > > > > > >> Example: If I see a test failure that happens on "master"
> > and
> > > > > > > > >> "release-1.11", I set "affects version" to "1.12.0" and
> > > > "1.11.0".
> > > > > > > > >> *Fix Version/s:*
> > > > > > > > >> For closed/resolved tickets, this field lists the released
> > > Flink
> > > > > > > > versions
> > > > > > > > >> that contain a fix or feature for the first time.
> > > > > > > > >> For open tickets, it indicates that a fix / feature should
> > be
> > > > > > > contained
> > > > > > > > in
> > > > > > > > >> the listed versions. Only blocker issues can block a
> > release,
> > > > all
> > > > > > > other
> > > > > > > > >> tickets which have "fix version/s" set at the time of a
> > > release
> > > > > and
> > > > > > > are
> > > > > > > > >> unresolved will be moved to the next version.
> > > > > > > > >> *Assignee:*
> > > > > > > > >> Person currently working on the ticket. Assigned after
> > > > conclusion
> > > > > on
> > > > > > > > >> approach by a committer.
> > > > > > > > >> Often, fixes are obvious and committers self-assign w/o
> > > > > discussion.
> > > > > > > > >> *Resolve / Close:*
> > > > > > > > >> You can either Resolve or Close a ticket once it is done
> > > (fixed,
> > > > > > > > rejected,
> > > > > > > > >> invalid, ...).
> > > > > > > > >> As a rule, we Close tickets instead of Resolving them when
> > > they
> > > > > are
> > > > > > > > done.
> > > > > > > > >> Background: There are semantic differences for Resolve and
> > > Close
> > > > > > > > >> (implementor vs reporter considers it done), but I don't
> see
> > > how
> > > > > > they
> > > > > > > > >> practically apply to the Flink project. Looking at the
> > > numbers,
> > > > > > Flink
> > > > > > > > has
> > > > > > > > >> 11066 closed tickets, and 3372 resolved tickets (that's
> why
> > I
> > > > > > propose
> > > > > > > to
> > > > > > > > >> close instead of resolve)
> > > > > > > > >> *Labels:*
> > > > > > > > >> "test-stability" for all test instabilities
> > > > > > > > >> "starter" for tickets suitable for new contributors
> > > > > > > > >> *Release Note:*
> > > > > > > > >> Small notes that will be included into the release notes
> > > > published
> > > > > > > with
> > > > > > > > the
> > > > > > > > >> release.
> > > > > > > > >> *All other fields are not used not used on a regular
> basis.*
> > > > > > > > >> Please +1 my proposal if you want it to be published in
> our
> > > Wiki
> > > > > > like
> > > > > > > > that
> > > > > > > > >> or let me know if I got something wrong here.
> > > > > > > > >> Best,
> > > > > > > > >> Robert
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
> > --
> > Best, Jingsong Lee
> >
>

[Congxian Qiu]

@[hidden email] <[hidden email]>  Thanks for the confirmation

Best,
Congxian


Zhu Zhu <[hidden email]> 于2020年5月25日周一 下午4:13写道：

> This is very helpful!
> +1
>
> Thanks,
> Zhu Zhu
>
> Yang Wang <[hidden email]> 于2020年5月25日周一 下午4:04写道：
>
> > +1 from this useful proposal.
> >
> > This makes me clearer about "Resolve" and "Close" since I used to be
> > confused by this two button.
> >
> > Best,
> > Yang
> >
> > Jingsong Li <[hidden email]> 于2020年5月25日周一 下午3:10写道：
> >
> > > +1 for the proposal.
> > > It makes me clearer.
> > >
> > > Best,
> > > Jingsong Lee
> > >
> > > On Mon, May 25, 2020 at 2:51 PM Zhijiang <[hidden email]
> > > .invalid>
> > > wrote:
> > >
> > > > Thanks for launching this discussion and giving so detailed infos,
> > > > Robert!  +1 on my side for the proposal.
> > > >
> > > > For "Affects Version", I previously thought it was only for the
> already
> > > > released versions, so it can give a reminder that the fix should also
> > > pick
> > > > into the related released branches for future minor versions.
> > > > I saw that Jark had somehow similar concerns for this field in below
> > > > replies.  Either way makes sense for me as long as we give a
> determined
> > > > rule in Wiki.
> > > >
> > > > Re Flavio' s comments, I agree that the Jira reporter can leave most
> of
> > > > the fields empty if not confirmed of them, then the respective
> > component
> > > > maintainer or committer can update them accordingly later.
> > > > But the state of Jira should not be marked as "resolved" when the PR
> is
> > > > detected, that is not fitting into the resolved semantic I guess. If
> > > > possible, the Jira can be updated as "in progress" automatically if
> > > > the respective PR is ready, then it will save some time to stat
> > progress
> > > > of related issues during release process.
> > > >
> > > > Best,
> > > > Zhijiang
> > > > ------------------------------------------------------------------
> > > > From:Congxian Qiu <[hidden email]>
> > > > Send Time:2020年5月25日(星期一) 13:57
> > > > To:[hidden email] <[hidden email]>
> > > > Subject:Re: [DISCUSS] Semantics of our JIRA fields
> > > >
> > > > Hi
> > > >
> > > > Currently, when I'm going to create an issue for Project-website. I'm
> > not
> > > > very sure what the "Affect Version/s" should be set. The problem is
> > that
> > > > the current Dockfile[1] in flink-web is broken because of the EOL of
> > > Ubuntu
> > > > 18.10[2], the project-web does not affect any release of Flink, it
> does
> > > > affect the process to build website, so what's the version should I
> set
> > > to?
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://github.com/apache/flink-web/blob/bc66f0f0f463ab62a22e81df7d7efd301b76a6b4/docker/Dockerfile#L17
> > > > [2] https://wiki.ubuntu.com/Releases
> > > >
> > > > Best,
> > > > Congxian
> > > >
> > > >
> > > > Flavio Pompermaier <[hidden email]> 于2020年5月24日周日 下午1:23写道：
> > > >
> > > > > In my experience it's quite complicated for a normal reporter to be
> > > able
> > > > to
> > > > > fill all the fields correctly (especially for new users).
> > > > > Usually you just wanto to report a problem, remember to add a new
> > > feature
> > > > > or improve code/documentation but you can't really give a priority,
> > > > assign
> > > > > the correct label or decide which releases will benefit of the
> > fix/new
> > > > > feature. This is something that only core developers could decide
> > > (IMHO).
> > > > >
> > > > > My experiece says that it's better if normal users could just open
> > > > tickets
> > > > > with some default (or mark ticket as new) and leave them in such a
> > > state
> > > > > until an experienced user, one that can assign tickets, have the
> time
> > > to
> > > > > read it and immediately reject the ticket or accept it and properly
> > > > assign
> > > > > priorities, fix version, etc.
> > > > >
> > > > > With respect to resolve/close I think that a good practice could be
> > to
> > > > mark
> > > > > automatically a ticket as resolved once that a PR is detected for
> > that
> > > > > ticket, while marking it as closed should be done by the commiter
> who
> > > > merge
> > > > > the PR.
> > > > >
> > > > > Probably this process would slightly increase the work of a
> committer
> > > but
> > > > > this would make things a lot cleaner and will bring the benefit of
> > > > having a
> > > > > reliable and semantically sound JIRA state.
> > > > >
> > > > > Cheers,
> > > > > Flavio
> > > > >
> > > > > Il Dom 24 Mag 2020, 05:05 Israel Ekpo <[hidden email]> ha
> > > scritto:
> > > > >
> > > > > > +1 for the proposal
> > > > > >
> > > > > > This will bring some consistency to the process
> > > > > >
> > > > > > Regarding Closed vs Resolved, should we go back and switch all
> the
> > > > > Resolved
> > > > > > issues to Closed so that is is not confusing to new people to the
> > > > project
> > > > > > in the future that may not have seen this discussion?
> > > > > >
> > > > > > I would recommend changing it to Closed just to be consistent
> since
> > > > that
> > > > > is
> > > > > > the majority and the new process will be using Closed going
> forward
> > > > > >
> > > > > > Those are my thoughts for now
> > > > > >
> > > > > > On Sat, May 23, 2020 at 7:48 AM Congxian Qiu <
> > [hidden email]
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > +1 for the proposal. It's good to have a unified description
> and
> > > > write
> > > > > it
> > > > > > > down in the wiki, so that every contributor has the same
> > > > understanding
> > > > > of
> > > > > > > all the fields.
> > > > > > >
> > > > > > > Best,
> > > > > > > Congxian
> > > > > > >
> > > > > > >
> > > > > > > Till Rohrmann <[hidden email]> 于2020年5月23日周六 上午12:04写道：
> > > > > > >
> > > > > > > > Thanks for drafting this proposal Robert. +1 for the
> proposal.
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > > Till
> > > > > > > >
> > > > > > > > On Fri, May 22, 2020 at 5:39 PM Leonard Xu <
> [hidden email]>
> > > > > wrote:
> > > > > > > >
> > > > > > > > > Thanks bringing up this topic @Robert,  +1 to the proposal.
> > > > > > > > >
> > > > > > > > > It clarifies the JIRA fields well and should be a rule to
> > > follow.
> > > > > > > > >
> > > > > > > > > Best,
> > > > > > > > > Leonard Xu
> > > > > > > > > > 在 2020年5月22日，20:24，Aljoscha Krettek <[hidden email]
> >
> > > 写道：
> > > > > > > > > >
> > > > > > > > > > +1 That's also how I think of the semantics of the
> fields.
> > > > > > > > > >
> > > > > > > > > > Aljoscha
> > > > > > > > > >
> > > > > > > > > > On 22.05.20 08:07, Robert Metzger wrote:
> > > > > > > > > >> Hi all,
> > > > > > > > > >> I have the feeling that the semantics of some of our
> JIRA
> > > > fields
> > > > > > > > (mostly
> > > > > > > > > >> "affects versions", "fix versions" and resolve / close)
> > are
> > > > not
> > > > > > > > defined
> > > > > > > > > in
> > > > > > > > > >> the same way by all the core Flink contributors, which
> > leads
> > > > to
> > > > > > > cases
> > > > > > > > > where
> > > > > > > > > >> I spend quite some time on filling the fields correctly
> > (at
> > > > > least
> > > > > > > > what I
> > > > > > > > > >> consider correctly), and then others changing them again
> > to
> > > > > match
> > > > > > > > their
> > > > > > > > > >> semantics.
> > > > > > > > > >> In an effort to increase our efficiency, and since I'm
> > > > creating
> > > > > a
> > > > > > > lot
> > > > > > > > of
> > > > > > > > > >> (test instability-related) tickets these days, I would
> > like
> > > to
> > > > > > > discuss
> > > > > > > > > the
> > > > > > > > > >> semantics, come to a conclusion and document this in our
> > > Wiki.
> > > > > > > > > >> *Proposal:*
> > > > > > > > > >> *Priority:*
> > > > > > > > > >> "Blocker": needs to be resolved before a release
> (matched
> > > > based
> > > > > on
> > > > > > > fix
> > > > > > > > > >> versions)
> > > > > > > > > >> "Critical": strongly considered before a release
> > > > > > > > > >> other priorities have no practical meaning in Flink.
> > > > > > > > > >> *Component/s:*
> > > > > > > > > >> Primary component relevant for this feature / fix.
> > > > > > > > > >> For test-related issues, add the component the test
> > belongs
> > > to
> > > > > > (for
> > > > > > > > > example
> > > > > > > > > >> "Connectors / Kafka" for Kafka test failures) + "Test".
> > > > > > > > > >> The same applies for documentation tickets. For example,
> > if
> > > > > > there's
> > > > > > > > > >> something wrong with the DataStream API, add it to the
> > "API
> > > /
> > > > > > > > > DataStream"
> > > > > > > > > >> and "Documentation" components.
> > > > > > > > > >> *Affects Version/s:*Only for Bug / Task-type tickets: We
> > > list
> > > > > all
> > > > > > > > > currently
> > > > > > > > > >> supported and unreleased Flink versions known to be
> > affected
> > > > by
> > > > > > > this.
> > > > > > > > > >> Example: If I see a test failure that happens on
> "master"
> > > and
> > > > > > > > > >> "release-1.11", I set "affects version" to "1.12.0" and
> > > > > "1.11.0".
> > > > > > > > > >> *Fix Version/s:*
> > > > > > > > > >> For closed/resolved tickets, this field lists the
> released
> > > > Flink
> > > > > > > > > versions
> > > > > > > > > >> that contain a fix or feature for the first time.
> > > > > > > > > >> For open tickets, it indicates that a fix / feature
> should
> > > be
> > > > > > > > contained
> > > > > > > > > in
> > > > > > > > > >> the listed versions. Only blocker issues can block a
> > > release,
> > > > > all
> > > > > > > > other
> > > > > > > > > >> tickets which have "fix version/s" set at the time of a
> > > > release
> > > > > > and
> > > > > > > > are
> > > > > > > > > >> unresolved will be moved to the next version.
> > > > > > > > > >> *Assignee:*
> > > > > > > > > >> Person currently working on the ticket. Assigned after
> > > > > conclusion
> > > > > > on
> > > > > > > > > >> approach by a committer.
> > > > > > > > > >> Often, fixes are obvious and committers self-assign w/o
> > > > > > discussion.
> > > > > > > > > >> *Resolve / Close:*
> > > > > > > > > >> You can either Resolve or Close a ticket once it is done
> > > > (fixed,
> > > > > > > > > rejected,
> > > > > > > > > >> invalid, ...).
> > > > > > > > > >> As a rule, we Close tickets instead of Resolving them
> when
> > > > they
> > > > > > are
> > > > > > > > > done.
> > > > > > > > > >> Background: There are semantic differences for Resolve
> and
> > > > Close
> > > > > > > > > >> (implementor vs reporter considers it done), but I don't
> > see
> > > > how
> > > > > > > they
> > > > > > > > > >> practically apply to the Flink project. Looking at the
> > > > numbers,
> > > > > > > Flink
> > > > > > > > > has
> > > > > > > > > >> 11066 closed tickets, and 3372 resolved tickets (that's
> > why
> > > I
> > > > > > > propose
> > > > > > > > to
> > > > > > > > > >> close instead of resolve)
> > > > > > > > > >> *Labels:*
> > > > > > > > > >> "test-stability" for all test instabilities
> > > > > > > > > >> "starter" for tickets suitable for new contributors
> > > > > > > > > >> *Release Note:*
> > > > > > > > > >> Small notes that will be included into the release notes
> > > > > published
> > > > > > > > with
> > > > > > > > > the
> > > > > > > > > >> release.
> > > > > > > > > >> *All other fields are not used not used on a regular
> > basis.*
> > > > > > > > > >> Please +1 my proposal if you want it to be published in
> > our
> > > > Wiki
> > > > > > > like
> > > > > > > > > that
> > > > > > > > > >> or let me know if I got something wrong here.
> > > > > > > > > >> Best,
> > > > > > > > > >> Robert
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > > --
> > > Best, Jingsong Lee
> > >
> >
>

[Robert Metzger]

Hi all,
thanks a lot for the feedback. The majority of responses are very positive
to my proposal.

I have put my proposal into our wiki:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=154995514

Regarding the comments so far:
@Jark: I clarified this in the wiki.

@Israel: I have not considered build changing all 3000 resolved tickets to
closed yet, but after consideration I don't think it is necessary. If
others in the community would like to change them, please speak up in this
thread :)

@Flavio: I agree that we can not ask new or infrequent users to fully
adhere to these definitions. I added a note in the Wiki.
Using the resolved state for indicating "PR available" is problematic
because there are plenty of cases where PRs are stale (and this ticket
would then appear as a "resolved"). The Apache tools are adding a link to
the PR, and some contributors are setting the ticket to "In Progress". I
don't see a problem that we need to solve here.

@Yun: Thank you for your comment. I added an example clarifying how I would
handle such a case. It is slightly different from your proposal: You
suggested using x.y.0 versions, I used "the next supported, unreleased
version", because that's how we've done it so far (and I don't want to
change things, I just want to document how the majority of the core
contributors are using JIRA).

Here are all the changes (in green, blue are just formatting changes) I
made compared to my initial proposal:
https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=154995514&selectedPageVersions=4&selectedPageVersions=1



On Mon, May 25, 2020 at 2:28 PM Congxian Qiu <[hidden email]> wrote:

> @[hidden email] <[hidden email]>  Thanks for the confirmation
>
> Best,
> Congxian
>
>
> Zhu Zhu <[hidden email]> 于2020年5月25日周一 下午4:13写道：
>
> > This is very helpful!
> > +1
> >
> > Thanks,
> > Zhu Zhu
> >
> > Yang Wang <[hidden email]> 于2020年5月25日周一 下午4:04写道：
> >
> > > +1 from this useful proposal.
> > >
> > > This makes me clearer about "Resolve" and "Close" since I used to be
> > > confused by this two button.
> > >
> > > Best,
> > > Yang
> > >
> > > Jingsong Li <[hidden email]> 于2020年5月25日周一 下午3:10写道：
> > >
> > > > +1 for the proposal.
> > > > It makes me clearer.
> > > >
> > > > Best,
> > > > Jingsong Lee
> > > >
> > > > On Mon, May 25, 2020 at 2:51 PM Zhijiang <[hidden email]
> > > > .invalid>
> > > > wrote:
> > > >
> > > > > Thanks for launching this discussion and giving so detailed infos,
> > > > > Robert!  +1 on my side for the proposal.
> > > > >
> > > > > For "Affects Version", I previously thought it was only for the
> > already
> > > > > released versions, so it can give a reminder that the fix should
> also
> > > > pick
> > > > > into the related released branches for future minor versions.
> > > > > I saw that Jark had somehow similar concerns for this field in
> below
> > > > > replies.  Either way makes sense for me as long as we give a
> > determined
> > > > > rule in Wiki.
> > > > >
> > > > > Re Flavio' s comments, I agree that the Jira reporter can leave
> most
> > of
> > > > > the fields empty if not confirmed of them, then the respective
> > > component
> > > > > maintainer or committer can update them accordingly later.
> > > > > But the state of Jira should not be marked as "resolved" when the
> PR
> > is
> > > > > detected, that is not fitting into the resolved semantic I guess.
> If
> > > > > possible, the Jira can be updated as "in progress" automatically if
> > > > > the respective PR is ready, then it will save some time to stat
> > > progress
> > > > > of related issues during release process.
> > > > >
> > > > > Best,
> > > > > Zhijiang
> > > > > ------------------------------------------------------------------
> > > > > From:Congxian Qiu <[hidden email]>
> > > > > Send Time:2020年5月25日(星期一) 13:57
> > > > > To:[hidden email] <[hidden email]>
> > > > > Subject:Re: [DISCUSS] Semantics of our JIRA fields
> > > > >
> > > > > Hi
> > > > >
> > > > > Currently, when I'm going to create an issue for Project-website.
> I'm
> > > not
> > > > > very sure what the "Affect Version/s" should be set. The problem is
> > > that
> > > > > the current Dockfile[1] in flink-web is broken because of the EOL
> of
> > > > Ubuntu
> > > > > 18.10[2], the project-web does not affect any release of Flink, it
> > does
> > > > > affect the process to build website, so what's the version should I
> > set
> > > > to?
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/flink-web/blob/bc66f0f0f463ab62a22e81df7d7efd301b76a6b4/docker/Dockerfile#L17
> > > > > [2] https://wiki.ubuntu.com/Releases
> > > > >
> > > > > Best,
> > > > > Congxian
> > > > >
> > > > >
> > > > > Flavio Pompermaier <[hidden email]> 于2020年5月24日周日 下午1:23写道：
> > > > >
> > > > > > In my experience it's quite complicated for a normal reporter to
> be
> > > > able
> > > > > to
> > > > > > fill all the fields correctly (especially for new users).
> > > > > > Usually you just wanto to report a problem, remember to add a new
> > > > feature
> > > > > > or improve code/documentation but you can't really give a
> priority,
> > > > > assign
> > > > > > the correct label or decide which releases will benefit of the
> > > fix/new
> > > > > > feature. This is something that only core developers could decide
> > > > (IMHO).
> > > > > >
> > > > > > My experiece says that it's better if normal users could just
> open
> > > > > tickets
> > > > > > with some default (or mark ticket as new) and leave them in such
> a
> > > > state
> > > > > > until an experienced user, one that can assign tickets, have the
> > time
> > > > to
> > > > > > read it and immediately reject the ticket or accept it and
> properly
> > > > > assign
> > > > > > priorities, fix version, etc.
> > > > > >
> > > > > > With respect to resolve/close I think that a good practice could
> be
> > > to
> > > > > mark
> > > > > > automatically a ticket as resolved once that a PR is detected for
> > > that
> > > > > > ticket, while marking it as closed should be done by the commiter
> > who
> > > > > merge
> > > > > > the PR.
> > > > > >
> > > > > > Probably this process would slightly increase the work of a
> > committer
> > > > but
> > > > > > this would make things a lot cleaner and will bring the benefit
> of
> > > > > having a
> > > > > > reliable and semantically sound JIRA state.
> > > > > >
> > > > > > Cheers,
> > > > > > Flavio
> > > > > >
> > > > > > Il Dom 24 Mag 2020, 05:05 Israel Ekpo <[hidden email]> ha
> > > > scritto:
> > > > > >
> > > > > > > +1 for the proposal
> > > > > > >
> > > > > > > This will bring some consistency to the process
> > > > > > >
> > > > > > > Regarding Closed vs Resolved, should we go back and switch all
> > the
> > > > > > Resolved
> > > > > > > issues to Closed so that is is not confusing to new people to
> the
> > > > > project
> > > > > > > in the future that may not have seen this discussion?
> > > > > > >
> > > > > > > I would recommend changing it to Closed just to be consistent
> > since
> > > > > that
> > > > > > is
> > > > > > > the majority and the new process will be using Closed going
> > forward
> > > > > > >
> > > > > > > Those are my thoughts for now
> > > > > > >
> > > > > > > On Sat, May 23, 2020 at 7:48 AM Congxian Qiu <
> > > [hidden email]
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > +1 for the proposal. It's good to have a unified description
> > and
> > > > > write
> > > > > > it
> > > > > > > > down in the wiki, so that every contributor has the same
> > > > > understanding
> > > > > > of
> > > > > > > > all the fields.
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > Congxian
> > > > > > > >
> > > > > > > >
> > > > > > > > Till Rohrmann <[hidden email]> 于2020年5月23日周六
> 上午12:04写道：
> > > > > > > >
> > > > > > > > > Thanks for drafting this proposal Robert. +1 for the
> > proposal.
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > > Till
> > > > > > > > >
> > > > > > > > > On Fri, May 22, 2020 at 5:39 PM Leonard Xu <
> > [hidden email]>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Thanks bringing up this topic @Robert,  +1 to the
> proposal.
> > > > > > > > > >
> > > > > > > > > > It clarifies the JIRA fields well and should be a rule to
> > > > follow.
> > > > > > > > > >
> > > > > > > > > > Best,
> > > > > > > > > > Leonard Xu
> > > > > > > > > > > 在 2020年5月22日，20:24，Aljoscha Krettek <
> [hidden email]
> > >
> > > > 写道：
> > > > > > > > > > >
> > > > > > > > > > > +1 That's also how I think of the semantics of the
> > fields.
> > > > > > > > > > >
> > > > > > > > > > > Aljoscha
> > > > > > > > > > >
> > > > > > > > > > > On 22.05.20 08:07, Robert Metzger wrote:
> > > > > > > > > > >> Hi all,
> > > > > > > > > > >> I have the feeling that the semantics of some of our
> > JIRA
> > > > > fields
> > > > > > > > > (mostly
> > > > > > > > > > >> "affects versions", "fix versions" and resolve /
> close)
> > > are
> > > > > not
> > > > > > > > > defined
> > > > > > > > > > in
> > > > > > > > > > >> the same way by all the core Flink contributors, which
> > > leads
> > > > > to
> > > > > > > > cases
> > > > > > > > > > where
> > > > > > > > > > >> I spend quite some time on filling the fields
> correctly
> > > (at
> > > > > > least
> > > > > > > > > what I
> > > > > > > > > > >> consider correctly), and then others changing them
> again
> > > to
> > > > > > match
> > > > > > > > > their
> > > > > > > > > > >> semantics.
> > > > > > > > > > >> In an effort to increase our efficiency, and since I'm
> > > > > creating
> > > > > > a
> > > > > > > > lot
> > > > > > > > > of
> > > > > > > > > > >> (test instability-related) tickets these days, I would
> > > like
> > > > to
> > > > > > > > discuss
> > > > > > > > > > the
> > > > > > > > > > >> semantics, come to a conclusion and document this in
> our
> > > > Wiki.
> > > > > > > > > > >> *Proposal:*
> > > > > > > > > > >> *Priority:*
> > > > > > > > > > >> "Blocker": needs to be resolved before a release
> > (matched
> > > > > based
> > > > > > on
> > > > > > > > fix
> > > > > > > > > > >> versions)
> > > > > > > > > > >> "Critical": strongly considered before a release
> > > > > > > > > > >> other priorities have no practical meaning in Flink.
> > > > > > > > > > >> *Component/s:*
> > > > > > > > > > >> Primary component relevant for this feature / fix.
> > > > > > > > > > >> For test-related issues, add the component the test
> > > belongs
> > > > to
> > > > > > > (for
> > > > > > > > > > example
> > > > > > > > > > >> "Connectors / Kafka" for Kafka test failures) +
> "Test".
> > > > > > > > > > >> The same applies for documentation tickets. For
> example,
> > > if
> > > > > > > there's
> > > > > > > > > > >> something wrong with the DataStream API, add it to the
> > > "API
> > > > /
> > > > > > > > > > DataStream"
> > > > > > > > > > >> and "Documentation" components.
> > > > > > > > > > >> *Affects Version/s:*Only for Bug / Task-type tickets:
> We
> > > > list
> > > > > > all
> > > > > > > > > > currently
> > > > > > > > > > >> supported and unreleased Flink versions known to be
> > > affected
> > > > > by
> > > > > > > > this.
> > > > > > > > > > >> Example: If I see a test failure that happens on
> > "master"
> > > > and
> > > > > > > > > > >> "release-1.11", I set "affects version" to "1.12.0"
> and
> > > > > > "1.11.0".
> > > > > > > > > > >> *Fix Version/s:*
> > > > > > > > > > >> For closed/resolved tickets, this field lists the
> > released
> > > > > Flink
> > > > > > > > > > versions
> > > > > > > > > > >> that contain a fix or feature for the first time.
> > > > > > > > > > >> For open tickets, it indicates that a fix / feature
> > should
> > > > be
> > > > > > > > > contained
> > > > > > > > > > in
> > > > > > > > > > >> the listed versions. Only blocker issues can block a
> > > > release,
> > > > > > all
> > > > > > > > > other
> > > > > > > > > > >> tickets which have "fix version/s" set at the time of
> a
> > > > > release
> > > > > > > and
> > > > > > > > > are
> > > > > > > > > > >> unresolved will be moved to the next version.
> > > > > > > > > > >> *Assignee:*
> > > > > > > > > > >> Person currently working on the ticket. Assigned after
> > > > > > conclusion
> > > > > > > on
> > > > > > > > > > >> approach by a committer.
> > > > > > > > > > >> Often, fixes are obvious and committers self-assign
> w/o
> > > > > > > discussion.
> > > > > > > > > > >> *Resolve / Close:*
> > > > > > > > > > >> You can either Resolve or Close a ticket once it is
> done
> > > > > (fixed,
> > > > > > > > > > rejected,
> > > > > > > > > > >> invalid, ...).
> > > > > > > > > > >> As a rule, we Close tickets instead of Resolving them
> > when
> > > > > they
> > > > > > > are
> > > > > > > > > > done.
> > > > > > > > > > >> Background: There are semantic differences for Resolve
> > and
> > > > > Close
> > > > > > > > > > >> (implementor vs reporter considers it done), but I
> don't
> > > see
> > > > > how
> > > > > > > > they
> > > > > > > > > > >> practically apply to the Flink project. Looking at the
> > > > > numbers,
> > > > > > > > Flink
> > > > > > > > > > has
> > > > > > > > > > >> 11066 closed tickets, and 3372 resolved tickets
> (that's
> > > why
> > > > I
> > > > > > > > propose
> > > > > > > > > to
> > > > > > > > > > >> close instead of resolve)
> > > > > > > > > > >> *Labels:*
> > > > > > > > > > >> "test-stability" for all test instabilities
> > > > > > > > > > >> "starter" for tickets suitable for new contributors
> > > > > > > > > > >> *Release Note:*
> > > > > > > > > > >> Small notes that will be included into the release
> notes
> > > > > > published
> > > > > > > > > with
> > > > > > > > > > the
> > > > > > > > > > >> release.
> > > > > > > > > > >> *All other fields are not used not used on a regular
> > > basis.*
> > > > > > > > > > >> Please +1 my proposal if you want it to be published
> in
> > > our
> > > > > Wiki
> > > > > > > > like
> > > > > > > > > > that
> > > > > > > > > > >> or let me know if I got something wrong here.
> > > > > > > > > > >> Best,
> > > > > > > > > > >> Robert
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Best, Jingsong Lee
> > > >
> > >
> >
>

[Piotr Nowojski-3]

Hi,

Sorry for a bit late response. I have two concerns:

1. Priority

I would propose to stretch priorities that we are using to differentiate between things that must be fixed for given release:

BLOCKER - drop anything you are doing, this issue must be fixed right now
CRITICAL - release can not happen without fixing it, but can be fixed a bit later (for example without context switching and dropping whatever I’m doing right now)
MAJOR - default, nice to have
Anything below - meh

We were already using this semantic for tracking test instabilities during the 1.11 release cycle. Good examples:

BLOCKER - master branch not compiling, very frequent test failures (for example almost every build affected), …
CRITICAL - performance regression/bug that we introduced in some feature, but which is not affecting other developers as much
MAJOR - freshly discovered test instability with unknown impact/frequency (could be happening once a year),

2. Affects version

If bug is only on the master branch, does it affect an unreleased version?

So far I was assuming that it doesn’t - unreleased bugs would have empty “affects version” field. My reasoning was that this field should be used for Flink users, to check which RELEASED Flink versions are affected by some bug, that user is searching for. Otherwise it might be a bit confusing if there are lots of bugs with both affects version and fix version set to the same value.

Piotrek

> On 25 May 2020, at 16:40, Robert Metzger <[hidden email]> wrote:
>
> Hi all,
> thanks a lot for the feedback. The majority of responses are very positive
> to my proposal.
>
> I have put my proposal into our wiki:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=154995514
>
> Regarding the comments so far:
> @Jark: I clarified this in the wiki.
>
> @Israel: I have not considered build changing all 3000 resolved tickets to
> closed yet, but after consideration I don't think it is necessary. If
> others in the community would like to change them, please speak up in this
> thread :)
>
> @Flavio: I agree that we can not ask new or infrequent users to fully
> adhere to these definitions. I added a note in the Wiki.
> Using the resolved state for indicating "PR available" is problematic
> because there are plenty of cases where PRs are stale (and this ticket
> would then appear as a "resolved"). The Apache tools are adding a link to
> the PR, and some contributors are setting the ticket to "In Progress". I
> don't see a problem that we need to solve here.
>
> @Yun: Thank you for your comment. I added an example clarifying how I would
> handle such a case. It is slightly different from your proposal: You
> suggested using x.y.0 versions, I used "the next supported, unreleased
> version", because that's how we've done it so far (and I don't want to
> change things, I just want to document how the majority of the core
> contributors are using JIRA).
>
> Here are all the changes (in green, blue are just formatting changes) I
> made compared to my initial proposal:
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=154995514&selectedPageVersions=4&selectedPageVersions=1
>
>
>
> On Mon, May 25, 2020 at 2:28 PM Congxian Qiu <[hidden email]> wrote:
>
>> @[hidden email] <[hidden email]>  Thanks for the confirmation
>>
>> Best,
>> Congxian
>>
>>
>> Zhu Zhu <[hidden email]> 于2020年5月25日周一 下午4:13写道：
>>
>>> This is very helpful!
>>> +1
>>>
>>> Thanks,
>>> Zhu Zhu
>>>
>>> Yang Wang <[hidden email]> 于2020年5月25日周一 下午4:04写道：
>>>
>>>> +1 from this useful proposal.
>>>>
>>>> This makes me clearer about "Resolve" and "Close" since I used to be
>>>> confused by this two button.
>>>>
>>>> Best,
>>>> Yang
>>>>
>>>> Jingsong Li <[hidden email]> 于2020年5月25日周一 下午3:10写道：
>>>>
>>>>> +1 for the proposal.
>>>>> It makes me clearer.
>>>>>
>>>>> Best,
>>>>> Jingsong Lee
>>>>>
>>>>> On Mon, May 25, 2020 at 2:51 PM Zhijiang <[hidden email]
>>>>> .invalid>
>>>>> wrote:
>>>>>
>>>>>> Thanks for launching this discussion and giving so detailed infos,
>>>>>> Robert!  +1 on my side for the proposal.
>>>>>>
>>>>>> For "Affects Version", I previously thought it was only for the
>>> already
>>>>>> released versions, so it can give a reminder that the fix should
>> also
>>>>> pick
>>>>>> into the related released branches for future minor versions.
>>>>>> I saw that Jark had somehow similar concerns for this field in
>> below
>>>>>> replies.  Either way makes sense for me as long as we give a
>>> determined
>>>>>> rule in Wiki.
>>>>>>
>>>>>> Re Flavio' s comments, I agree that the Jira reporter can leave
>> most
>>> of
>>>>>> the fields empty if not confirmed of them, then the respective
>>>> component
>>>>>> maintainer or committer can update them accordingly later.
>>>>>> But the state of Jira should not be marked as "resolved" when the
>> PR
>>> is
>>>>>> detected, that is not fitting into the resolved semantic I guess.
>> If
>>>>>> possible, the Jira can be updated as "in progress" automatically if
>>>>>> the respective PR is ready, then it will save some time to stat
>>>> progress
>>>>>> of related issues during release process.
>>>>>>
>>>>>> Best,
>>>>>> Zhijiang
>>>>>> ------------------------------------------------------------------
>>>>>> From:Congxian Qiu <[hidden email]>
>>>>>> Send Time:2020年5月25日(星期一) 13:57
>>>>>> To:[hidden email] <[hidden email]>
>>>>>> Subject:Re: [DISCUSS] Semantics of our JIRA fields
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> Currently, when I'm going to create an issue for Project-website.
>> I'm
>>>> not
>>>>>> very sure what the "Affect Version/s" should be set. The problem is
>>>> that
>>>>>> the current Dockfile[1] in flink-web is broken because of the EOL
>> of
>>>>> Ubuntu
>>>>>> 18.10[2], the project-web does not affect any release of Flink, it
>>> does
>>>>>> affect the process to build website, so what's the version should I
>>> set
>>>>> to?
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> https://github.com/apache/flink-web/blob/bc66f0f0f463ab62a22e81df7d7efd301b76a6b4/docker/Dockerfile#L17
>>>>>> [2] https://wiki.ubuntu.com/Releases
>>>>>>
>>>>>> Best,
>>>>>> Congxian
>>>>>>
>>>>>>
>>>>>> Flavio Pompermaier <[hidden email]> 于2020年5月24日周日 下午1:23写道：
>>>>>>
>>>>>>> In my experience it's quite complicated for a normal reporter to
>> be
>>>>> able
>>>>>> to
>>>>>>> fill all the fields correctly (especially for new users).
>>>>>>> Usually you just wanto to report a problem, remember to add a new
>>>>> feature
>>>>>>> or improve code/documentation but you can't really give a
>> priority,
>>>>>> assign
>>>>>>> the correct label or decide which releases will benefit of the
>>>> fix/new
>>>>>>> feature. This is something that only core developers could decide
>>>>> (IMHO).
>>>>>>>
>>>>>>> My experiece says that it's better if normal users could just
>> open
>>>>>> tickets
>>>>>>> with some default (or mark ticket as new) and leave them in such
>> a
>>>>> state
>>>>>>> until an experienced user, one that can assign tickets, have the
>>> time
>>>>> to
>>>>>>> read it and immediately reject the ticket or accept it and
>> properly
>>>>>> assign
>>>>>>> priorities, fix version, etc.
>>>>>>>
>>>>>>> With respect to resolve/close I think that a good practice could
>> be
>>>> to
>>>>>> mark
>>>>>>> automatically a ticket as resolved once that a PR is detected for
>>>> that
>>>>>>> ticket, while marking it as closed should be done by the commiter
>>> who
>>>>>> merge
>>>>>>> the PR.
>>>>>>>
>>>>>>> Probably this process would slightly increase the work of a
>>> committer
>>>>> but
>>>>>>> this would make things a lot cleaner and will bring the benefit
>> of
>>>>>> having a
>>>>>>> reliable and semantically sound JIRA state.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Flavio
>>>>>>>
>>>>>>> Il Dom 24 Mag 2020, 05:05 Israel Ekpo <[hidden email]> ha
>>>>> scritto:
>>>>>>>
>>>>>>>> +1 for the proposal
>>>>>>>>
>>>>>>>> This will bring some consistency to the process
>>>>>>>>
>>>>>>>> Regarding Closed vs Resolved, should we go back and switch all
>>> the
>>>>>>> Resolved
>>>>>>>> issues to Closed so that is is not confusing to new people to
>> the
>>>>>> project
>>>>>>>> in the future that may not have seen this discussion?
>>>>>>>>
>>>>>>>> I would recommend changing it to Closed just to be consistent
>>> since
>>>>>> that
>>>>>>> is
>>>>>>>> the majority and the new process will be using Closed going
>>> forward
>>>>>>>>
>>>>>>>> Those are my thoughts for now
>>>>>>>>
>>>>>>>> On Sat, May 23, 2020 at 7:48 AM Congxian Qiu <
>>>> [hidden email]
>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> +1 for the proposal. It's good to have a unified description
>>> and
>>>>>> write
>>>>>>> it
>>>>>>>>> down in the wiki, so that every contributor has the same
>>>>>> understanding
>>>>>>> of
>>>>>>>>> all the fields.
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Congxian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Till Rohrmann <[hidden email]> 于2020年5月23日周六
>> 上午12:04写道：
>>>>>>>>>
>>>>>>>>>> Thanks for drafting this proposal Robert. +1 for the
>>> proposal.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Till
>>>>>>>>>>
>>>>>>>>>> On Fri, May 22, 2020 at 5:39 PM Leonard Xu <
>>> [hidden email]>
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Thanks bringing up this topic @Robert,  +1 to the
>> proposal.
>>>>>>>>>>>
>>>>>>>>>>> It clarifies the JIRA fields well and should be a rule to
>>>>> follow.
>>>>>>>>>>>
>>>>>>>>>>> Best,
>>>>>>>>>>> Leonard Xu
>>>>>>>>>>>> 在 2020年5月22日，20:24，Aljoscha Krettek <
>> [hidden email]
>>>>
>>>>> 写道：
>>>>>>>>>>>>
>>>>>>>>>>>> +1 That's also how I think of the semantics of the
>>> fields.
>>>>>>>>>>>>
>>>>>>>>>>>> Aljoscha
>>>>>>>>>>>>
>>>>>>>>>>>> On 22.05.20 08:07, Robert Metzger wrote:
>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>> I have the feeling that the semantics of some of our
>>> JIRA
>>>>>> fields
>>>>>>>>>> (mostly
>>>>>>>>>>>>> "affects versions", "fix versions" and resolve /
>> close)
>>>> are
>>>>>> not
>>>>>>>>>> defined
>>>>>>>>>>> in
>>>>>>>>>>>>> the same way by all the core Flink contributors, which
>>>> leads
>>>>>> to
>>>>>>>>> cases
>>>>>>>>>>> where
>>>>>>>>>>>>> I spend quite some time on filling the fields
>> correctly
>>>> (at
>>>>>>> least
>>>>>>>>>> what I
>>>>>>>>>>>>> consider correctly), and then others changing them
>> again
>>>> to
>>>>>>> match
>>>>>>>>>> their
>>>>>>>>>>>>> semantics.
>>>>>>>>>>>>> In an effort to increase our efficiency, and since I'm
>>>>>> creating
>>>>>>> a
>>>>>>>>> lot
>>>>>>>>>> of
>>>>>>>>>>>>> (test instability-related) tickets these days, I would
>>>> like
>>>>> to
>>>>>>>>> discuss
>>>>>>>>>>> the
>>>>>>>>>>>>> semantics, come to a conclusion and document this in
>> our
>>>>> Wiki.
>>>>>>>>>>>>> *Proposal:*
>>>>>>>>>>>>> *Priority:*
>>>>>>>>>>>>> "Blocker": needs to be resolved before a release
>>> (matched
>>>>>> based
>>>>>>> on
>>>>>>>>> fix
>>>>>>>>>>>>> versions)
>>>>>>>>>>>>> "Critical": strongly considered before a release
>>>>>>>>>>>>> other priorities have no practical meaning in Flink.
>>>>>>>>>>>>> *Component/s:*
>>>>>>>>>>>>> Primary component relevant for this feature / fix.
>>>>>>>>>>>>> For test-related issues, add the component the test
>>>> belongs
>>>>> to
>>>>>>>> (for
>>>>>>>>>>> example
>>>>>>>>>>>>> "Connectors / Kafka" for Kafka test failures) +
>> "Test".
>>>>>>>>>>>>> The same applies for documentation tickets. For
>> example,
>>>> if
>>>>>>>> there's
>>>>>>>>>>>>> something wrong with the DataStream API, add it to the
>>>> "API
>>>>> /
>>>>>>>>>>> DataStream"
>>>>>>>>>>>>> and "Documentation" components.
>>>>>>>>>>>>> *Affects Version/s:*Only for Bug / Task-type tickets:
>> We
>>>>> list
>>>>>>> all
>>>>>>>>>>> currently
>>>>>>>>>>>>> supported and unreleased Flink versions known to be
>>>> affected
>>>>>> by
>>>>>>>>> this.
>>>>>>>>>>>>> Example: If I see a test failure that happens on
>>> "master"
>>>>> and
>>>>>>>>>>>>> "release-1.11", I set "affects version" to "1.12.0"
>> and
>>>>>>> "1.11.0".
>>>>>>>>>>>>> *Fix Version/s:*
>>>>>>>>>>>>> For closed/resolved tickets, this field lists the
>>> released
>>>>>> Flink
>>>>>>>>>>> versions
>>>>>>>>>>>>> that contain a fix or feature for the first time.
>>>>>>>>>>>>> For open tickets, it indicates that a fix / feature
>>> should
>>>>> be
>>>>>>>>>> contained
>>>>>>>>>>> in
>>>>>>>>>>>>> the listed versions. Only blocker issues can block a
>>>>> release,
>>>>>>> all
>>>>>>>>>> other
>>>>>>>>>>>>> tickets which have "fix version/s" set at the time of
>> a
>>>>>> release
>>>>>>>> and
>>>>>>>>>> are
>>>>>>>>>>>>> unresolved will be moved to the next version.
>>>>>>>>>>>>> *Assignee:*
>>>>>>>>>>>>> Person currently working on the ticket. Assigned after
>>>>>>> conclusion
>>>>>>>> on
>>>>>>>>>>>>> approach by a committer.
>>>>>>>>>>>>> Often, fixes are obvious and committers self-assign
>> w/o
>>>>>>>> discussion.
>>>>>>>>>>>>> *Resolve / Close:*
>>>>>>>>>>>>> You can either Resolve or Close a ticket once it is
>> done
>>>>>> (fixed,
>>>>>>>>>>> rejected,
>>>>>>>>>>>>> invalid, ...).
>>>>>>>>>>>>> As a rule, we Close tickets instead of Resolving them
>>> when
>>>>>> they
>>>>>>>> are
>>>>>>>>>>> done.
>>>>>>>>>>>>> Background: There are semantic differences for Resolve
>>> and
>>>>>> Close
>>>>>>>>>>>>> (implementor vs reporter considers it done), but I
>> don't
>>>> see
>>>>>> how
>>>>>>>>> they
>>>>>>>>>>>>> practically apply to the Flink project. Looking at the
>>>>>> numbers,
>>>>>>>>> Flink
>>>>>>>>>>> has
>>>>>>>>>>>>> 11066 closed tickets, and 3372 resolved tickets
>> (that's
>>>> why
>>>>> I
>>>>>>>>> propose
>>>>>>>>>> to
>>>>>>>>>>>>> close instead of resolve)
>>>>>>>>>>>>> *Labels:*
>>>>>>>>>>>>> "test-stability" for all test instabilities
>>>>>>>>>>>>> "starter" for tickets suitable for new contributors
>>>>>>>>>>>>> *Release Note:*
>>>>>>>>>>>>> Small notes that will be included into the release
>> notes
>>>>>>> published
>>>>>>>>>> with
>>>>>>>>>>> the
>>>>>>>>>>>>> release.
>>>>>>>>>>>>> *All other fields are not used not used on a regular
>>>> basis.*
>>>>>>>>>>>>> Please +1 my proposal if you want it to be published
>> in
>>>> our
>>>>>> Wiki
>>>>>>>>> like
>>>>>>>>>>> that
>>>>>>>>>>>>> or let me know if I got something wrong here.
>>>>>>>>>>>>> Best,
>>>>>>>>>>>>> Robert
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Best, Jingsong Lee
>>>>>
>>>>
>>>
>>

[Robert Metzger]

Hi,

1. I'm okay with updating the definition of the priorities for the reason
you've mentioned.

2. "Affects version"

The reason why like to mark affects version on unreleased versions is to
clearly indicate which branch is affected by a bug. Given the current Flink
release status, if there's a bug only in "release-1.11", but not in
"master", there is no way of figuring that out, if we only allow released
versions for "affects version" (In my proposal, you would set "affects
version" to '1.11.0', '1.12.0' to indicate that).

What we could do is introduce "1.12-SNAPSHOT" as version to mark issues on
unreleased versions. (But then people might accidentally set the "fix
version" to a "-SNAPSHOT" version.)

I'm still in favor of my proposal. I have never heard a report from a
confused user about our Jira fields (I guess they usually check bugs for
released versions only)


On Tue, May 26, 2020 at 12:39 PM Piotr Nowojski <[hidden email]> wrote:

> Hi,
>
> Sorry for a bit late response. I have two concerns:
>
> 1. Priority
>
> I would propose to stretch priorities that we are using to differentiate
> between things that must be fixed for given release:
>
> BLOCKER - drop anything you are doing, this issue must be fixed right now
> CRITICAL - release can not happen without fixing it, but can be fixed a
> bit later (for example without context switching and dropping whatever I’m
> doing right now)
> MAJOR - default, nice to have
> Anything below - meh
>
> We were already using this semantic for tracking test instabilities during
> the 1.11 release cycle. Good examples:
>
> BLOCKER - master branch not compiling, very frequent test failures (for
> example almost every build affected), …
> CRITICAL - performance regression/bug that we introduced in some feature,
> but which is not affecting other developers as much
> MAJOR - freshly discovered test instability with unknown impact/frequency
> (could be happening once a year),
>
> 2. Affects version
>
> If bug is only on the master branch, does it affect an unreleased version?
>
> So far I was assuming that it doesn’t - unreleased bugs would have empty
> “affects version” field. My reasoning was that this field should be used
> for Flink users, to check which RELEASED Flink versions are affected by
> some bug, that user is searching for. Otherwise it might be a bit confusing
> if there are lots of bugs with both affects version and fix version set to
> the same value.
>
> Piotrek
>
> > On 25 May 2020, at 16:40, Robert Metzger <[hidden email]> wrote:
> >
> > Hi all,
> > thanks a lot for the feedback. The majority of responses are very
> positive
> > to my proposal.
> >
> > I have put my proposal into our wiki:
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=154995514
> >
> > Regarding the comments so far:
> > @Jark: I clarified this in the wiki.
> >
> > @Israel: I have not considered build changing all 3000 resolved tickets
> to
> > closed yet, but after consideration I don't think it is necessary. If
> > others in the community would like to change them, please speak up in
> this
> > thread :)
> >
> > @Flavio: I agree that we can not ask new or infrequent users to fully
> > adhere to these definitions. I added a note in the Wiki.
> > Using the resolved state for indicating "PR available" is problematic
> > because there are plenty of cases where PRs are stale (and this ticket
> > would then appear as a "resolved"). The Apache tools are adding a link to
> > the PR, and some contributors are setting the ticket to "In Progress". I
> > don't see a problem that we need to solve here.
> >
> > @Yun: Thank you for your comment. I added an example clarifying how I
> would
> > handle such a case. It is slightly different from your proposal: You
> > suggested using x.y.0 versions, I used "the next supported, unreleased
> > version", because that's how we've done it so far (and I don't want to
> > change things, I just want to document how the majority of the core
> > contributors are using JIRA).
> >
> > Here are all the changes (in green, blue are just formatting changes) I
> > made compared to my initial proposal:
> >
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=154995514&selectedPageVersions=4&selectedPageVersions=1
> >
> >
> >
> > On Mon, May 25, 2020 at 2:28 PM Congxian Qiu <[hidden email]>
> wrote:
> >
> >> @[hidden email] <[hidden email]>  Thanks for the confirmation
> >>
> >> Best,
> >> Congxian
> >>
> >>
> >> Zhu Zhu <[hidden email]> 于2020年5月25日周一 下午4:13写道：
> >>
> >>> This is very helpful!
> >>> +1
> >>>
> >>> Thanks,
> >>> Zhu Zhu
> >>>
> >>> Yang Wang <[hidden email]> 于2020年5月25日周一 下午4:04写道：
> >>>
> >>>> +1 from this useful proposal.
> >>>>
> >>>> This makes me clearer about "Resolve" and "Close" since I used to be
> >>>> confused by this two button.
> >>>>
> >>>> Best,
> >>>> Yang
> >>>>
> >>>> Jingsong Li <[hidden email]> 于2020年5月25日周一 下午3:10写道：
> >>>>
> >>>>> +1 for the proposal.
> >>>>> It makes me clearer.
> >>>>>
> >>>>> Best,
> >>>>> Jingsong Lee
> >>>>>
> >>>>> On Mon, May 25, 2020 at 2:51 PM Zhijiang <[hidden email]
> >>>>> .invalid>
> >>>>> wrote:
> >>>>>
> >>>>>> Thanks for launching this discussion and giving so detailed infos,
> >>>>>> Robert!  +1 on my side for the proposal.
> >>>>>>
> >>>>>> For "Affects Version", I previously thought it was only for the
> >>> already
> >>>>>> released versions, so it can give a reminder that the fix should
> >> also
> >>>>> pick
> >>>>>> into the related released branches for future minor versions.
> >>>>>> I saw that Jark had somehow similar concerns for this field in
> >> below
> >>>>>> replies.  Either way makes sense for me as long as we give a
> >>> determined
> >>>>>> rule in Wiki.
> >>>>>>
> >>>>>> Re Flavio' s comments, I agree that the Jira reporter can leave
> >> most
> >>> of
> >>>>>> the fields empty if not confirmed of them, then the respective
> >>>> component
> >>>>>> maintainer or committer can update them accordingly later.
> >>>>>> But the state of Jira should not be marked as "resolved" when the
> >> PR
> >>> is
> >>>>>> detected, that is not fitting into the resolved semantic I guess.
> >> If
> >>>>>> possible, the Jira can be updated as "in progress" automatically if
> >>>>>> the respective PR is ready, then it will save some time to stat
> >>>> progress
> >>>>>> of related issues during release process.
> >>>>>>
> >>>>>> Best,
> >>>>>> Zhijiang
> >>>>>> ------------------------------------------------------------------
> >>>>>> From:Congxian Qiu <[hidden email]>
> >>>>>> Send Time:2020年5月25日(星期一) 13:57
> >>>>>> To:[hidden email] <[hidden email]>
> >>>>>> Subject:Re: [DISCUSS] Semantics of our JIRA fields
> >>>>>>
> >>>>>> Hi
> >>>>>>
> >>>>>> Currently, when I'm going to create an issue for Project-website.
> >> I'm
> >>>> not
> >>>>>> very sure what the "Affect Version/s" should be set. The problem is
> >>>> that
> >>>>>> the current Dockfile[1] in flink-web is broken because of the EOL
> >> of
> >>>>> Ubuntu
> >>>>>> 18.10[2], the project-web does not affect any release of Flink, it
> >>> does
> >>>>>> affect the process to build website, so what's the version should I
> >>> set
> >>>>> to?
> >>>>>>
> >>>>>> [1]
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://github.com/apache/flink-web/blob/bc66f0f0f463ab62a22e81df7d7efd301b76a6b4/docker/Dockerfile#L17
> >>>>>> [2] https://wiki.ubuntu.com/Releases
> >>>>>>
> >>>>>> Best,
> >>>>>> Congxian
> >>>>>>
> >>>>>>
> >>>>>> Flavio Pompermaier <[hidden email]> 于2020年5月24日周日 下午1:23写道：
> >>>>>>
> >>>>>>> In my experience it's quite complicated for a normal reporter to
> >> be
> >>>>> able
> >>>>>> to
> >>>>>>> fill all the fields correctly (especially for new users).
> >>>>>>> Usually you just wanto to report a problem, remember to add a new
> >>>>> feature
> >>>>>>> or improve code/documentation but you can't really give a
> >> priority,
> >>>>>> assign
> >>>>>>> the correct label or decide which releases will benefit of the
> >>>> fix/new
> >>>>>>> feature. This is something that only core developers could decide
> >>>>> (IMHO).
> >>>>>>>
> >>>>>>> My experiece says that it's better if normal users could just
> >> open
> >>>>>> tickets
> >>>>>>> with some default (or mark ticket as new) and leave them in such
> >> a
> >>>>> state
> >>>>>>> until an experienced user, one that can assign tickets, have the
> >>> time
> >>>>> to
> >>>>>>> read it and immediately reject the ticket or accept it and
> >> properly
> >>>>>> assign
> >>>>>>> priorities, fix version, etc.
> >>>>>>>
> >>>>>>> With respect to resolve/close I think that a good practice could
> >> be
> >>>> to
> >>>>>> mark
> >>>>>>> automatically a ticket as resolved once that a PR is detected for
> >>>> that
> >>>>>>> ticket, while marking it as closed should be done by the commiter
> >>> who
> >>>>>> merge
> >>>>>>> the PR.
> >>>>>>>
> >>>>>>> Probably this process would slightly increase the work of a
> >>> committer
> >>>>> but
> >>>>>>> this would make things a lot cleaner and will bring the benefit
> >> of
> >>>>>> having a
> >>>>>>> reliable and semantically sound JIRA state.
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Flavio
> >>>>>>>
> >>>>>>> Il Dom 24 Mag 2020, 05:05 Israel Ekpo <[hidden email]> ha
> >>>>> scritto:
> >>>>>>>
> >>>>>>>> +1 for the proposal
> >>>>>>>>
> >>>>>>>> This will bring some consistency to the process
> >>>>>>>>
> >>>>>>>> Regarding Closed vs Resolved, should we go back and switch all
> >>> the
> >>>>>>> Resolved
> >>>>>>>> issues to Closed so that is is not confusing to new people to
> >> the
> >>>>>> project
> >>>>>>>> in the future that may not have seen this discussion?
> >>>>>>>>
> >>>>>>>> I would recommend changing it to Closed just to be consistent
> >>> since
> >>>>>> that
> >>>>>>> is
> >>>>>>>> the majority and the new process will be using Closed going
> >>> forward
> >>>>>>>>
> >>>>>>>> Those are my thoughts for now
> >>>>>>>>
> >>>>>>>> On Sat, May 23, 2020 at 7:48 AM Congxian Qiu <
> >>>> [hidden email]
> >>>>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> +1 for the proposal. It's good to have a unified description
> >>> and
> >>>>>> write
> >>>>>>> it
> >>>>>>>>> down in the wiki, so that every contributor has the same
> >>>>>> understanding
> >>>>>>> of
> >>>>>>>>> all the fields.
> >>>>>>>>>
> >>>>>>>>> Best,
> >>>>>>>>> Congxian
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Till Rohrmann <[hidden email]> 于2020年5月23日周六
> >> 上午12:04写道：
> >>>>>>>>>
> >>>>>>>>>> Thanks for drafting this proposal Robert. +1 for the
> >>> proposal.
> >>>>>>>>>>
> >>>>>>>>>> Cheers,
> >>>>>>>>>> Till
> >>>>>>>>>>
> >>>>>>>>>> On Fri, May 22, 2020 at 5:39 PM Leonard Xu <
> >>> [hidden email]>
> >>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Thanks bringing up this topic @Robert,  +1 to the
> >> proposal.
> >>>>>>>>>>>
> >>>>>>>>>>> It clarifies the JIRA fields well and should be a rule to
> >>>>> follow.
> >>>>>>>>>>>
> >>>>>>>>>>> Best,
> >>>>>>>>>>> Leonard Xu
> >>>>>>>>>>>> 在 2020年5月22日，20:24，Aljoscha Krettek <
> >> [hidden email]
> >>>>
> >>>>> 写道：
> >>>>>>>>>>>>
> >>>>>>>>>>>> +1 That's also how I think of the semantics of the
> >>> fields.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Aljoscha
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 22.05.20 08:07, Robert Metzger wrote:
> >>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>> I have the feeling that the semantics of some of our
> >>> JIRA
> >>>>>> fields
> >>>>>>>>>> (mostly
> >>>>>>>>>>>>> "affects versions", "fix versions" and resolve /
> >> close)
> >>>> are
> >>>>>> not
> >>>>>>>>>> defined
> >>>>>>>>>>> in
> >>>>>>>>>>>>> the same way by all the core Flink contributors, which
> >>>> leads
> >>>>>> to
> >>>>>>>>> cases
> >>>>>>>>>>> where
> >>>>>>>>>>>>> I spend quite some time on filling the fields
> >> correctly
> >>>> (at
> >>>>>>> least
> >>>>>>>>>> what I
> >>>>>>>>>>>>> consider correctly), and then others changing them
> >> again
> >>>> to
> >>>>>>> match
> >>>>>>>>>> their
> >>>>>>>>>>>>> semantics.
> >>>>>>>>>>>>> In an effort to increase our efficiency, and since I'm
> >>>>>> creating
> >>>>>>> a
> >>>>>>>>> lot
> >>>>>>>>>> of
> >>>>>>>>>>>>> (test instability-related) tickets these days, I would
> >>>> like
> >>>>> to
> >>>>>>>>> discuss
> >>>>>>>>>>> the
> >>>>>>>>>>>>> semantics, come to a conclusion and document this in
> >> our
> >>>>> Wiki.
> >>>>>>>>>>>>> *Proposal:*
> >>>>>>>>>>>>> *Priority:*
> >>>>>>>>>>>>> "Blocker": needs to be resolved before a release
> >>> (matched
> >>>>>> based
> >>>>>>> on
> >>>>>>>>> fix
> >>>>>>>>>>>>> versions)
> >>>>>>>>>>>>> "Critical": strongly considered before a release
> >>>>>>>>>>>>> other priorities have no practical meaning in Flink.
> >>>>>>>>>>>>> *Component/s:*
> >>>>>>>>>>>>> Primary component relevant for this feature / fix.
> >>>>>>>>>>>>> For test-related issues, add the component the test
> >>>> belongs
> >>>>> to
> >>>>>>>> (for
> >>>>>>>>>>> example
> >>>>>>>>>>>>> "Connectors / Kafka" for Kafka test failures) +
> >> "Test".
> >>>>>>>>>>>>> The same applies for documentation tickets. For
> >> example,
> >>>> if
> >>>>>>>> there's
> >>>>>>>>>>>>> something wrong with the DataStream API, add it to the
> >>>> "API
> >>>>> /
> >>>>>>>>>>> DataStream"
> >>>>>>>>>>>>> and "Documentation" components.
> >>>>>>>>>>>>> *Affects Version/s:*Only for Bug / Task-type tickets:
> >> We
> >>>>> list
> >>>>>>> all
> >>>>>>>>>>> currently
> >>>>>>>>>>>>> supported and unreleased Flink versions known to be
> >>>> affected
> >>>>>> by
> >>>>>>>>> this.
> >>>>>>>>>>>>> Example: If I see a test failure that happens on
> >>> "master"
> >>>>> and
> >>>>>>>>>>>>> "release-1.11", I set "affects version" to "1.12.0"
> >> and
> >>>>>>> "1.11.0".
> >>>>>>>>>>>>> *Fix Version/s:*
> >>>>>>>>>>>>> For closed/resolved tickets, this field lists the
> >>> released
> >>>>>> Flink
> >>>>>>>>>>> versions
> >>>>>>>>>>>>> that contain a fix or feature for the first time.
> >>>>>>>>>>>>> For open tickets, it indicates that a fix / feature
> >>> should
> >>>>> be
> >>>>>>>>>> contained
> >>>>>>>>>>> in
> >>>>>>>>>>>>> the listed versions. Only blocker issues can block a
> >>>>> release,
> >>>>>>> all
> >>>>>>>>>> other
> >>>>>>>>>>>>> tickets which have "fix version/s" set at the time of
> >> a
> >>>>>> release
> >>>>>>>> and
> >>>>>>>>>> are
> >>>>>>>>>>>>> unresolved will be moved to the next version.
> >>>>>>>>>>>>> *Assignee:*
> >>>>>>>>>>>>> Person currently working on the ticket. Assigned after
> >>>>>>> conclusion
> >>>>>>>> on
> >>>>>>>>>>>>> approach by a committer.
> >>>>>>>>>>>>> Often, fixes are obvious and committers self-assign
> >> w/o
> >>>>>>>> discussion.
> >>>>>>>>>>>>> *Resolve / Close:*
> >>>>>>>>>>>>> You can either Resolve or Close a ticket once it is
> >> done
> >>>>>> (fixed,
> >>>>>>>>>>> rejected,
> >>>>>>>>>>>>> invalid, ...).
> >>>>>>>>>>>>> As a rule, we Close tickets instead of Resolving them
> >>> when
> >>>>>> they
> >>>>>>>> are
> >>>>>>>>>>> done.
> >>>>>>>>>>>>> Background: There are semantic differences for Resolve
> >>> and
> >>>>>> Close
> >>>>>>>>>>>>> (implementor vs reporter considers it done), but I
> >> don't
> >>>> see
> >>>>>> how
> >>>>>>>>> they
> >>>>>>>>>>>>> practically apply to the Flink project. Looking at the
> >>>>>> numbers,
> >>>>>>>>> Flink
> >>>>>>>>>>> has
> >>>>>>>>>>>>> 11066 closed tickets, and 3372 resolved tickets
> >> (that's
> >>>> why
> >>>>> I
> >>>>>>>>> propose
> >>>>>>>>>> to
> >>>>>>>>>>>>> close instead of resolve)
> >>>>>>>>>>>>> *Labels:*
> >>>>>>>>>>>>> "test-stability" for all test instabilities
> >>>>>>>>>>>>> "starter" for tickets suitable for new contributors
> >>>>>>>>>>>>> *Release Note:*
> >>>>>>>>>>>>> Small notes that will be included into the release
> >> notes
> >>>>>>> published
> >>>>>>>>>> with
> >>>>>>>>>>> the
> >>>>>>>>>>>>> release.
> >>>>>>>>>>>>> *All other fields are not used not used on a regular
> >>>> basis.*
> >>>>>>>>>>>>> Please +1 my proposal if you want it to be published
> >> in
> >>>> our
> >>>>>> Wiki
> >>>>>>>>> like
> >>>>>>>>>>> that
> >>>>>>>>>>>>> or let me know if I got something wrong here.
> >>>>>>>>>>>>> Best,
> >>>>>>>>>>>>> Robert
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Best, Jingsong Lee
> >>>>>
> >>>>
> >>>
> >>
>
>

[Till Rohrmann]

If we change the meaning of the priority levels, then I would suggest to
have a dedicated discussion for it. This would also be more visible than
compared to being hidden in some lengthy discussion thread. I think the
proposed definitions of priority levels differ slightly from how the
community worked in the past.

Cheers,
Till

On Tue, May 26, 2020 at 4:30 PM Robert Metzger <[hidden email]> wrote:

> Hi,
>
> 1. I'm okay with updating the definition of the priorities for the reason
> you've mentioned.
>
> 2. "Affects version"
>
> The reason why like to mark affects version on unreleased versions is to
> clearly indicate which branch is affected by a bug. Given the current Flink
> release status, if there's a bug only in "release-1.11", but not in
> "master", there is no way of figuring that out, if we only allow released
> versions for "affects version" (In my proposal, you would set "affects
> version" to '1.11.0', '1.12.0' to indicate that).
>
> What we could do is introduce "1.12-SNAPSHOT" as version to mark issues on
> unreleased versions. (But then people might accidentally set the "fix
> version" to a "-SNAPSHOT" version.)
>
> I'm still in favor of my proposal. I have never heard a report from a
> confused user about our Jira fields (I guess they usually check bugs for
> released versions only)
>
>
> On Tue, May 26, 2020 at 12:39 PM Piotr Nowojski <[hidden email]>
> wrote:
>
> > Hi,
> >
> > Sorry for a bit late response. I have two concerns:
> >
> > 1. Priority
> >
> > I would propose to stretch priorities that we are using to differentiate
> > between things that must be fixed for given release:
> >
> > BLOCKER - drop anything you are doing, this issue must be fixed right now
> > CRITICAL - release can not happen without fixing it, but can be fixed a
> > bit later (for example without context switching and dropping whatever
> I’m
> > doing right now)
> > MAJOR - default, nice to have
> > Anything below - meh
> >
> > We were already using this semantic for tracking test instabilities
> during
> > the 1.11 release cycle. Good examples:
> >
> > BLOCKER - master branch not compiling, very frequent test failures (for
> > example almost every build affected), …
> > CRITICAL - performance regression/bug that we introduced in some feature,
> > but which is not affecting other developers as much
> > MAJOR - freshly discovered test instability with unknown impact/frequency
> > (could be happening once a year),
> >
> > 2. Affects version
> >
> > If bug is only on the master branch, does it affect an unreleased
> version?
> >
> > So far I was assuming that it doesn’t - unreleased bugs would have empty
> > “affects version” field. My reasoning was that this field should be used
> > for Flink users, to check which RELEASED Flink versions are affected by
> > some bug, that user is searching for. Otherwise it might be a bit
> confusing
> > if there are lots of bugs with both affects version and fix version set
> to
> > the same value.
> >
> > Piotrek
> >
> > > On 25 May 2020, at 16:40, Robert Metzger <[hidden email]> wrote:
> > >
> > > Hi all,
> > > thanks a lot for the feedback. The majority of responses are very
> > positive
> > > to my proposal.
> > >
> > > I have put my proposal into our wiki:
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=154995514
> > >
> > > Regarding the comments so far:
> > > @Jark: I clarified this in the wiki.
> > >
> > > @Israel: I have not considered build changing all 3000 resolved tickets
> > to
> > > closed yet, but after consideration I don't think it is necessary. If
> > > others in the community would like to change them, please speak up in
> > this
> > > thread :)
> > >
> > > @Flavio: I agree that we can not ask new or infrequent users to fully
> > > adhere to these definitions. I added a note in the Wiki.
> > > Using the resolved state for indicating "PR available" is problematic
> > > because there are plenty of cases where PRs are stale (and this ticket
> > > would then appear as a "resolved"). The Apache tools are adding a link
> to
> > > the PR, and some contributors are setting the ticket to "In Progress".
> I
> > > don't see a problem that we need to solve here.
> > >
> > > @Yun: Thank you for your comment. I added an example clarifying how I
> > would
> > > handle such a case. It is slightly different from your proposal: You
> > > suggested using x.y.0 versions, I used "the next supported, unreleased
> > > version", because that's how we've done it so far (and I don't want to
> > > change things, I just want to document how the majority of the core
> > > contributors are using JIRA).
> > >
> > > Here are all the changes (in green, blue are just formatting changes) I
> > > made compared to my initial proposal:
> > >
> >
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=154995514&selectedPageVersions=4&selectedPageVersions=1
> > >
> > >
> > >
> > > On Mon, May 25, 2020 at 2:28 PM Congxian Qiu <[hidden email]>
> > wrote:
> > >
> > >> @[hidden email] <[hidden email]>  Thanks for the confirmation
> > >>
> > >> Best,
> > >> Congxian
> > >>
> > >>
> > >> Zhu Zhu <[hidden email]> 于2020年5月25日周一 下午4:13写道：
> > >>
> > >>> This is very helpful!
> > >>> +1
> > >>>
> > >>> Thanks,
> > >>> Zhu Zhu
> > >>>
> > >>> Yang Wang <[hidden email]> 于2020年5月25日周一 下午4:04写道：
> > >>>
> > >>>> +1 from this useful proposal.
> > >>>>
> > >>>> This makes me clearer about "Resolve" and "Close" since I used to be
> > >>>> confused by this two button.
> > >>>>
> > >>>> Best,
> > >>>> Yang
> > >>>>
> > >>>> Jingsong Li <[hidden email]> 于2020年5月25日周一 下午3:10写道：
> > >>>>
> > >>>>> +1 for the proposal.
> > >>>>> It makes me clearer.
> > >>>>>
> > >>>>> Best,
> > >>>>> Jingsong Lee
> > >>>>>
> > >>>>> On Mon, May 25, 2020 at 2:51 PM Zhijiang <
> [hidden email]
> > >>>>> .invalid>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> Thanks for launching this discussion and giving so detailed infos,
> > >>>>>> Robert!  +1 on my side for the proposal.
> > >>>>>>
> > >>>>>> For "Affects Version", I previously thought it was only for the
> > >>> already
> > >>>>>> released versions, so it can give a reminder that the fix should
> > >> also
> > >>>>> pick
> > >>>>>> into the related released branches for future minor versions.
> > >>>>>> I saw that Jark had somehow similar concerns for this field in
> > >> below
> > >>>>>> replies.  Either way makes sense for me as long as we give a
> > >>> determined
> > >>>>>> rule in Wiki.
> > >>>>>>
> > >>>>>> Re Flavio' s comments, I agree that the Jira reporter can leave
> > >> most
> > >>> of
> > >>>>>> the fields empty if not confirmed of them, then the respective
> > >>>> component
> > >>>>>> maintainer or committer can update them accordingly later.
> > >>>>>> But the state of Jira should not be marked as "resolved" when the
> > >> PR
> > >>> is
> > >>>>>> detected, that is not fitting into the resolved semantic I guess.
> > >> If
> > >>>>>> possible, the Jira can be updated as "in progress" automatically
> if
> > >>>>>> the respective PR is ready, then it will save some time to stat
> > >>>> progress
> > >>>>>> of related issues during release process.
> > >>>>>>
> > >>>>>> Best,
> > >>>>>> Zhijiang
> > >>>>>> ------------------------------------------------------------------
> > >>>>>> From:Congxian Qiu <[hidden email]>
> > >>>>>> Send Time:2020年5月25日(星期一) 13:57
> > >>>>>> To:[hidden email] <[hidden email]>
> > >>>>>> Subject:Re: [DISCUSS] Semantics of our JIRA fields
> > >>>>>>
> > >>>>>> Hi
> > >>>>>>
> > >>>>>> Currently, when I'm going to create an issue for Project-website.
> > >> I'm
> > >>>> not
> > >>>>>> very sure what the "Affect Version/s" should be set. The problem
> is
> > >>>> that
> > >>>>>> the current Dockfile[1] in flink-web is broken because of the EOL
> > >> of
> > >>>>> Ubuntu
> > >>>>>> 18.10[2], the project-web does not affect any release of Flink, it
> > >>> does
> > >>>>>> affect the process to build website, so what's the version should
> I
> > >>> set
> > >>>>> to?
> > >>>>>>
> > >>>>>> [1]
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> https://github.com/apache/flink-web/blob/bc66f0f0f463ab62a22e81df7d7efd301b76a6b4/docker/Dockerfile#L17
> > >>>>>> [2] https://wiki.ubuntu.com/Releases
> > >>>>>>
> > >>>>>> Best,
> > >>>>>> Congxian
> > >>>>>>
> > >>>>>>
> > >>>>>> Flavio Pompermaier <[hidden email]> 于2020年5月24日周日 下午1:23写道：
> > >>>>>>
> > >>>>>>> In my experience it's quite complicated for a normal reporter to
> > >> be
> > >>>>> able
> > >>>>>> to
> > >>>>>>> fill all the fields correctly (especially for new users).
> > >>>>>>> Usually you just wanto to report a problem, remember to add a new
> > >>>>> feature
> > >>>>>>> or improve code/documentation but you can't really give a
> > >> priority,
> > >>>>>> assign
> > >>>>>>> the correct label or decide which releases will benefit of the
> > >>>> fix/new
> > >>>>>>> feature. This is something that only core developers could decide
> > >>>>> (IMHO).
> > >>>>>>>
> > >>>>>>> My experiece says that it's better if normal users could just
> > >> open
> > >>>>>> tickets
> > >>>>>>> with some default (or mark ticket as new) and leave them in such
> > >> a
> > >>>>> state
> > >>>>>>> until an experienced user, one that can assign tickets, have the
> > >>> time
> > >>>>> to
> > >>>>>>> read it and immediately reject the ticket or accept it and
> > >> properly
> > >>>>>> assign
> > >>>>>>> priorities, fix version, etc.
> > >>>>>>>
> > >>>>>>> With respect to resolve/close I think that a good practice could
> > >> be
> > >>>> to
> > >>>>>> mark
> > >>>>>>> automatically a ticket as resolved once that a PR is detected for
> > >>>> that
> > >>>>>>> ticket, while marking it as closed should be done by the commiter
> > >>> who
> > >>>>>> merge
> > >>>>>>> the PR.
> > >>>>>>>
> > >>>>>>> Probably this process would slightly increase the work of a
> > >>> committer
> > >>>>> but
> > >>>>>>> this would make things a lot cleaner and will bring the benefit
> > >> of
> > >>>>>> having a
> > >>>>>>> reliable and semantically sound JIRA state.
> > >>>>>>>
> > >>>>>>> Cheers,
> > >>>>>>> Flavio
> > >>>>>>>
> > >>>>>>> Il Dom 24 Mag 2020, 05:05 Israel Ekpo <[hidden email]> ha
> > >>>>> scritto:
> > >>>>>>>
> > >>>>>>>> +1 for the proposal
> > >>>>>>>>
> > >>>>>>>> This will bring some consistency to the process
> > >>>>>>>>
> > >>>>>>>> Regarding Closed vs Resolved, should we go back and switch all
> > >>> the
> > >>>>>>> Resolved
> > >>>>>>>> issues to Closed so that is is not confusing to new people to
> > >> the
> > >>>>>> project
> > >>>>>>>> in the future that may not have seen this discussion?
> > >>>>>>>>
> > >>>>>>>> I would recommend changing it to Closed just to be consistent
> > >>> since
> > >>>>>> that
> > >>>>>>> is
> > >>>>>>>> the majority and the new process will be using Closed going
> > >>> forward
> > >>>>>>>>
> > >>>>>>>> Those are my thoughts for now
> > >>>>>>>>
> > >>>>>>>> On Sat, May 23, 2020 at 7:48 AM Congxian Qiu <
> > >>>> [hidden email]
> > >>>>>>
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> +1 for the proposal. It's good to have a unified description
> > >>> and
> > >>>>>> write
> > >>>>>>> it
> > >>>>>>>>> down in the wiki, so that every contributor has the same
> > >>>>>> understanding
> > >>>>>>> of
> > >>>>>>>>> all the fields.
> > >>>>>>>>>
> > >>>>>>>>> Best,
> > >>>>>>>>> Congxian
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> Till Rohrmann <[hidden email]> 于2020年5月23日周六
> > >> 上午12:04写道：
> > >>>>>>>>>
> > >>>>>>>>>> Thanks for drafting this proposal Robert. +1 for the
> > >>> proposal.
> > >>>>>>>>>>
> > >>>>>>>>>> Cheers,
> > >>>>>>>>>> Till
> > >>>>>>>>>>
> > >>>>>>>>>> On Fri, May 22, 2020 at 5:39 PM Leonard Xu <
> > >>> [hidden email]>
> > >>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> Thanks bringing up this topic @Robert,  +1 to the
> > >> proposal.
> > >>>>>>>>>>>
> > >>>>>>>>>>> It clarifies the JIRA fields well and should be a rule to
> > >>>>> follow.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Best,
> > >>>>>>>>>>> Leonard Xu
> > >>>>>>>>>>>> 在 2020年5月22日，20:24，Aljoscha Krettek <
> > >> [hidden email]
> > >>>>
> > >>>>> 写道：
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> +1 That's also how I think of the semantics of the
> > >>> fields.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Aljoscha
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On 22.05.20 08:07, Robert Metzger wrote:
> > >>>>>>>>>>>>> Hi all,
> > >>>>>>>>>>>>> I have the feeling that the semantics of some of our
> > >>> JIRA
> > >>>>>> fields
> > >>>>>>>>>> (mostly
> > >>>>>>>>>>>>> "affects versions", "fix versions" and resolve /
> > >> close)
> > >>>> are
> > >>>>>> not
> > >>>>>>>>>> defined
> > >>>>>>>>>>> in
> > >>>>>>>>>>>>> the same way by all the core Flink contributors, which
> > >>>> leads
> > >>>>>> to
> > >>>>>>>>> cases
> > >>>>>>>>>>> where
> > >>>>>>>>>>>>> I spend quite some time on filling the fields
> > >> correctly
> > >>>> (at
> > >>>>>>> least
> > >>>>>>>>>> what I
> > >>>>>>>>>>>>> consider correctly), and then others changing them
> > >> again
> > >>>> to
> > >>>>>>> match
> > >>>>>>>>>> their
> > >>>>>>>>>>>>> semantics.
> > >>>>>>>>>>>>> In an effort to increase our efficiency, and since I'm
> > >>>>>> creating
> > >>>>>>> a
> > >>>>>>>>> lot
> > >>>>>>>>>> of
> > >>>>>>>>>>>>> (test instability-related) tickets these days, I would
> > >>>> like
> > >>>>> to
> > >>>>>>>>> discuss
> > >>>>>>>>>>> the
> > >>>>>>>>>>>>> semantics, come to a conclusion and document this in
> > >> our
> > >>>>> Wiki.
> > >>>>>>>>>>>>> *Proposal:*
> > >>>>>>>>>>>>> *Priority:*
> > >>>>>>>>>>>>> "Blocker": needs to be resolved before a release
> > >>> (matched
> > >>>>>> based
> > >>>>>>> on
> > >>>>>>>>> fix
> > >>>>>>>>>>>>> versions)
> > >>>>>>>>>>>>> "Critical": strongly considered before a release
> > >>>>>>>>>>>>> other priorities have no practical meaning in Flink.
> > >>>>>>>>>>>>> *Component/s:*
> > >>>>>>>>>>>>> Primary component relevant for this feature / fix.
> > >>>>>>>>>>>>> For test-related issues, add the component the test
> > >>>> belongs
> > >>>>> to
> > >>>>>>>> (for
> > >>>>>>>>>>> example
> > >>>>>>>>>>>>> "Connectors / Kafka" for Kafka test failures) +
> > >> "Test".
> > >>>>>>>>>>>>> The same applies for documentation tickets. For
> > >> example,
> > >>>> if
> > >>>>>>>> there's
> > >>>>>>>>>>>>> something wrong with the DataStream API, add it to the
> > >>>> "API
> > >>>>> /
> > >>>>>>>>>>> DataStream"
> > >>>>>>>>>>>>> and "Documentation" components.
> > >>>>>>>>>>>>> *Affects Version/s:*Only for Bug / Task-type tickets:
> > >> We
> > >>>>> list
> > >>>>>>> all
> > >>>>>>>>>>> currently
> > >>>>>>>>>>>>> supported and unreleased Flink versions known to be
> > >>>> affected
> > >>>>>> by
> > >>>>>>>>> this.
> > >>>>>>>>>>>>> Example: If I see a test failure that happens on
> > >>> "master"
> > >>>>> and
> > >>>>>>>>>>>>> "release-1.11", I set "affects version" to "1.12.0"
> > >> and
> > >>>>>>> "1.11.0".
> > >>>>>>>>>>>>> *Fix Version/s:*
> > >>>>>>>>>>>>> For closed/resolved tickets, this field lists the
> > >>> released
> > >>>>>> Flink
> > >>>>>>>>>>> versions
> > >>>>>>>>>>>>> that contain a fix or feature for the first time.
> > >>>>>>>>>>>>> For open tickets, it indicates that a fix / feature
> > >>> should
> > >>>>> be
> > >>>>>>>>>> contained
> > >>>>>>>>>>> in
> > >>>>>>>>>>>>> the listed versions. Only blocker issues can block a
> > >>>>> release,
> > >>>>>>> all
> > >>>>>>>>>> other
> > >>>>>>>>>>>>> tickets which have "fix version/s" set at the time of
> > >> a
> > >>>>>> release
> > >>>>>>>> and
> > >>>>>>>>>> are
> > >>>>>>>>>>>>> unresolved will be moved to the next version.
> > >>>>>>>>>>>>> *Assignee:*
> > >>>>>>>>>>>>> Person currently working on the ticket. Assigned after
> > >>>>>>> conclusion
> > >>>>>>>> on
> > >>>>>>>>>>>>> approach by a committer.
> > >>>>>>>>>>>>> Often, fixes are obvious and committers self-assign
> > >> w/o
> > >>>>>>>> discussion.
> > >>>>>>>>>>>>> *Resolve / Close:*
> > >>>>>>>>>>>>> You can either Resolve or Close a ticket once it is
> > >> done
> > >>>>>> (fixed,
> > >>>>>>>>>>> rejected,
> > >>>>>>>>>>>>> invalid, ...).
> > >>>>>>>>>>>>> As a rule, we Close tickets instead of Resolving them
> > >>> when
> > >>>>>> they
> > >>>>>>>> are
> > >>>>>>>>>>> done.
> > >>>>>>>>>>>>> Background: There are semantic differences for Resolve
> > >>> and
> > >>>>>> Close
> > >>>>>>>>>>>>> (implementor vs reporter considers it done), but I
> > >> don't
> > >>>> see
> > >>>>>> how
> > >>>>>>>>> they
> > >>>>>>>>>>>>> practically apply to the Flink project. Looking at the
> > >>>>>> numbers,
> > >>>>>>>>> Flink
> > >>>>>>>>>>> has
> > >>>>>>>>>>>>> 11066 closed tickets, and 3372 resolved tickets
> > >> (that's
> > >>>> why
> > >>>>> I
> > >>>>>>>>> propose
> > >>>>>>>>>> to
> > >>>>>>>>>>>>> close instead of resolve)
> > >>>>>>>>>>>>> *Labels:*
> > >>>>>>>>>>>>> "test-stability" for all test instabilities
> > >>>>>>>>>>>>> "starter" for tickets suitable for new contributors
> > >>>>>>>>>>>>> *Release Note:*
> > >>>>>>>>>>>>> Small notes that will be included into the release
> > >> notes
> > >>>>>>> published
> > >>>>>>>>>> with
> > >>>>>>>>>>> the
> > >>>>>>>>>>>>> release.
> > >>>>>>>>>>>>> *All other fields are not used not used on a regular
> > >>>> basis.*
> > >>>>>>>>>>>>> Please +1 my proposal if you want it to be published
> > >> in
> > >>>> our
> > >>>>>> Wiki
> > >>>>>>>>> like
> > >>>>>>>>>>> that
> > >>>>>>>>>>>>> or let me know if I got something wrong here.
> > >>>>>>>>>>>>> Best,
> > >>>>>>>>>>>>> Robert
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Best, Jingsong Lee
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>

[Robert Metzger]

I agree with you Till -- changing the definition of the priorities should
be a separate discussion.

Piotrek, do you agree with my "affects version" explanation? I would like
to bring this discussion to a conclusion.



On Tue, May 26, 2020 at 4:51 PM Till Rohrmann <[hidden email]> wrote:

> If we change the meaning of the priority levels, then I would suggest to
> have a dedicated discussion for it. This would also be more visible than
> compared to being hidden in some lengthy discussion thread. I think the
> proposed definitions of priority levels differ slightly from how the
> community worked in the past.
>
> Cheers,
> Till
>
> On Tue, May 26, 2020 at 4:30 PM Robert Metzger <[hidden email]>
> wrote:
>
> > Hi,
> >
> > 1. I'm okay with updating the definition of the priorities for the reason
> > you've mentioned.
> >
> > 2. "Affects version"
> >
> > The reason why like to mark affects version on unreleased versions is to
> > clearly indicate which branch is affected by a bug. Given the current
> Flink
> > release status, if there's a bug only in "release-1.11", but not in
> > "master", there is no way of figuring that out, if we only allow released
> > versions for "affects version" (In my proposal, you would set "affects
> > version" to '1.11.0', '1.12.0' to indicate that).
> >
> > What we could do is introduce "1.12-SNAPSHOT" as version to mark issues
> on
> > unreleased versions. (But then people might accidentally set the "fix
> > version" to a "-SNAPSHOT" version.)
> >
> > I'm still in favor of my proposal. I have never heard a report from a
> > confused user about our Jira fields (I guess they usually check bugs for
> > released versions only)
> >
> >
> > On Tue, May 26, 2020 at 12:39 PM Piotr Nowojski <[hidden email]>
> > wrote:
> >
> > > Hi,
> > >
> > > Sorry for a bit late response. I have two concerns:
> > >
> > > 1. Priority
> > >
> > > I would propose to stretch priorities that we are using to
> differentiate
> > > between things that must be fixed for given release:
> > >
> > > BLOCKER - drop anything you are doing, this issue must be fixed right
> now
> > > CRITICAL - release can not happen without fixing it, but can be fixed a
> > > bit later (for example without context switching and dropping whatever
> > I’m
> > > doing right now)
> > > MAJOR - default, nice to have
> > > Anything below - meh
> > >
> > > We were already using this semantic for tracking test instabilities
> > during
> > > the 1.11 release cycle. Good examples:
> > >
> > > BLOCKER - master branch not compiling, very frequent test failures (for
> > > example almost every build affected), …
> > > CRITICAL - performance regression/bug that we introduced in some
> feature,
> > > but which is not affecting other developers as much
> > > MAJOR - freshly discovered test instability with unknown
> impact/frequency
> > > (could be happening once a year),
> > >
> > > 2. Affects version
> > >
> > > If bug is only on the master branch, does it affect an unreleased
> > version?
> > >
> > > So far I was assuming that it doesn’t - unreleased bugs would have
> empty
> > > “affects version” field. My reasoning was that this field should be
> used
> > > for Flink users, to check which RELEASED Flink versions are affected by
> > > some bug, that user is searching for. Otherwise it might be a bit
> > confusing
> > > if there are lots of bugs with both affects version and fix version set
> > to
> > > the same value.
> > >
> > > Piotrek
> > >
> > > > On 25 May 2020, at 16:40, Robert Metzger <[hidden email]>
> wrote:
> > > >
> > > > Hi all,
> > > > thanks a lot for the feedback. The majority of responses are very
> > > positive
> > > > to my proposal.
> > > >
> > > > I have put my proposal into our wiki:
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=154995514
> > > >
> > > > Regarding the comments so far:
> > > > @Jark: I clarified this in the wiki.
> > > >
> > > > @Israel: I have not considered build changing all 3000 resolved
> tickets
> > > to
> > > > closed yet, but after consideration I don't think it is necessary. If
> > > > others in the community would like to change them, please speak up in
> > > this
> > > > thread :)
> > > >
> > > > @Flavio: I agree that we can not ask new or infrequent users to fully
> > > > adhere to these definitions. I added a note in the Wiki.
> > > > Using the resolved state for indicating "PR available" is problematic
> > > > because there are plenty of cases where PRs are stale (and this
> ticket
> > > > would then appear as a "resolved"). The Apache tools are adding a
> link
> > to
> > > > the PR, and some contributors are setting the ticket to "In
> Progress".
> > I
> > > > don't see a problem that we need to solve here.
> > > >
> > > > @Yun: Thank you for your comment. I added an example clarifying how I
> > > would
> > > > handle such a case. It is slightly different from your proposal: You
> > > > suggested using x.y.0 versions, I used "the next supported,
> unreleased
> > > > version", because that's how we've done it so far (and I don't want
> to
> > > > change things, I just want to document how the majority of the core
> > > > contributors are using JIRA).
> > > >
> > > > Here are all the changes (in green, blue are just formatting
> changes) I
> > > > made compared to my initial proposal:
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=154995514&selectedPageVersions=4&selectedPageVersions=1
> > > >
> > > >
> > > >
> > > > On Mon, May 25, 2020 at 2:28 PM Congxian Qiu <[hidden email]
> >
> > > wrote:
> > > >
> > > >> @[hidden email] <[hidden email]>  Thanks for the
> confirmation
> > > >>
> > > >> Best,
> > > >> Congxian
> > > >>
> > > >>
> > > >> Zhu Zhu <[hidden email]> 于2020年5月25日周一 下午4:13写道：
> > > >>
> > > >>> This is very helpful!
> > > >>> +1
> > > >>>
> > > >>> Thanks,
> > > >>> Zhu Zhu
> > > >>>
> > > >>> Yang Wang <[hidden email]> 于2020年5月25日周一 下午4:04写道：
> > > >>>
> > > >>>> +1 from this useful proposal.
> > > >>>>
> > > >>>> This makes me clearer about "Resolve" and "Close" since I used to
> be
> > > >>>> confused by this two button.
> > > >>>>
> > > >>>> Best,
> > > >>>> Yang
> > > >>>>
> > > >>>> Jingsong Li <[hidden email]> 于2020年5月25日周一 下午3:10写道：
> > > >>>>
> > > >>>>> +1 for the proposal.
> > > >>>>> It makes me clearer.
> > > >>>>>
> > > >>>>> Best,
> > > >>>>> Jingsong Lee
> > > >>>>>
> > > >>>>> On Mon, May 25, 2020 at 2:51 PM Zhijiang <
> > [hidden email]
> > > >>>>> .invalid>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> Thanks for launching this discussion and giving so detailed
> infos,
> > > >>>>>> Robert!  +1 on my side for the proposal.
> > > >>>>>>
> > > >>>>>> For "Affects Version", I previously thought it was only for the
> > > >>> already
> > > >>>>>> released versions, so it can give a reminder that the fix should
> > > >> also
> > > >>>>> pick
> > > >>>>>> into the related released branches for future minor versions.
> > > >>>>>> I saw that Jark had somehow similar concerns for this field in
> > > >> below
> > > >>>>>> replies.  Either way makes sense for me as long as we give a
> > > >>> determined
> > > >>>>>> rule in Wiki.
> > > >>>>>>
> > > >>>>>> Re Flavio' s comments, I agree that the Jira reporter can leave
> > > >> most
> > > >>> of
> > > >>>>>> the fields empty if not confirmed of them, then the respective
> > > >>>> component
> > > >>>>>> maintainer or committer can update them accordingly later.
> > > >>>>>> But the state of Jira should not be marked as "resolved" when
> the
> > > >> PR
> > > >>> is
> > > >>>>>> detected, that is not fitting into the resolved semantic I
> guess.
> > > >> If
> > > >>>>>> possible, the Jira can be updated as "in progress" automatically
> > if
> > > >>>>>> the respective PR is ready, then it will save some time to stat
> > > >>>> progress
> > > >>>>>> of related issues during release process.
> > > >>>>>>
> > > >>>>>> Best,
> > > >>>>>> Zhijiang
> > > >>>>>>
> ------------------------------------------------------------------
> > > >>>>>> From:Congxian Qiu <[hidden email]>
> > > >>>>>> Send Time:2020年5月25日(星期一) 13:57
> > > >>>>>> To:[hidden email] <[hidden email]>
> > > >>>>>> Subject:Re: [DISCUSS] Semantics of our JIRA fields
> > > >>>>>>
> > > >>>>>> Hi
> > > >>>>>>
> > > >>>>>> Currently, when I'm going to create an issue for
> Project-website.
> > > >> I'm
> > > >>>> not
> > > >>>>>> very sure what the "Affect Version/s" should be set. The problem
> > is
> > > >>>> that
> > > >>>>>> the current Dockfile[1] in flink-web is broken because of the
> EOL
> > > >> of
> > > >>>>> Ubuntu
> > > >>>>>> 18.10[2], the project-web does not affect any release of Flink,
> it
> > > >>> does
> > > >>>>>> affect the process to build website, so what's the version
> should
> > I
> > > >>> set
> > > >>>>> to?
> > > >>>>>>
> > > >>>>>> [1]
> > > >>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> https://github.com/apache/flink-web/blob/bc66f0f0f463ab62a22e81df7d7efd301b76a6b4/docker/Dockerfile#L17
> > > >>>>>> [2] https://wiki.ubuntu.com/Releases
> > > >>>>>>
> > > >>>>>> Best,
> > > >>>>>> Congxian
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Flavio Pompermaier <[hidden email]> 于2020年5月24日周日
> 下午1:23写道：
> > > >>>>>>
> > > >>>>>>> In my experience it's quite complicated for a normal reporter
> to
> > > >> be
> > > >>>>> able
> > > >>>>>> to
> > > >>>>>>> fill all the fields correctly (especially for new users).
> > > >>>>>>> Usually you just wanto to report a problem, remember to add a
> new
> > > >>>>> feature
> > > >>>>>>> or improve code/documentation but you can't really give a
> > > >> priority,
> > > >>>>>> assign
> > > >>>>>>> the correct label or decide which releases will benefit of the
> > > >>>> fix/new
> > > >>>>>>> feature. This is something that only core developers could
> decide
> > > >>>>> (IMHO).
> > > >>>>>>>
> > > >>>>>>> My experiece says that it's better if normal users could just
> > > >> open
> > > >>>>>> tickets
> > > >>>>>>> with some default (or mark ticket as new) and leave them in
> such
> > > >> a
> > > >>>>> state
> > > >>>>>>> until an experienced user, one that can assign tickets, have
> the
> > > >>> time
> > > >>>>> to
> > > >>>>>>> read it and immediately reject the ticket or accept it and
> > > >> properly
> > > >>>>>> assign
> > > >>>>>>> priorities, fix version, etc.
> > > >>>>>>>
> > > >>>>>>> With respect to resolve/close I think that a good practice
> could
> > > >> be
> > > >>>> to
> > > >>>>>> mark
> > > >>>>>>> automatically a ticket as resolved once that a PR is detected
> for
> > > >>>> that
> > > >>>>>>> ticket, while marking it as closed should be done by the
> commiter
> > > >>> who
> > > >>>>>> merge
> > > >>>>>>> the PR.
> > > >>>>>>>
> > > >>>>>>> Probably this process would slightly increase the work of a
> > > >>> committer
> > > >>>>> but
> > > >>>>>>> this would make things a lot cleaner and will bring the benefit
> > > >> of
> > > >>>>>> having a
> > > >>>>>>> reliable and semantically sound JIRA state.
> > > >>>>>>>
> > > >>>>>>> Cheers,
> > > >>>>>>> Flavio
> > > >>>>>>>
> > > >>>>>>> Il Dom 24 Mag 2020, 05:05 Israel Ekpo <[hidden email]>
> ha
> > > >>>>> scritto:
> > > >>>>>>>
> > > >>>>>>>> +1 for the proposal
> > > >>>>>>>>
> > > >>>>>>>> This will bring some consistency to the process
> > > >>>>>>>>
> > > >>>>>>>> Regarding Closed vs Resolved, should we go back and switch all
> > > >>> the
> > > >>>>>>> Resolved
> > > >>>>>>>> issues to Closed so that is is not confusing to new people to
> > > >> the
> > > >>>>>> project
> > > >>>>>>>> in the future that may not have seen this discussion?
> > > >>>>>>>>
> > > >>>>>>>> I would recommend changing it to Closed just to be consistent
> > > >>> since
> > > >>>>>> that
> > > >>>>>>> is
> > > >>>>>>>> the majority and the new process will be using Closed going
> > > >>> forward
> > > >>>>>>>>
> > > >>>>>>>> Those are my thoughts for now
> > > >>>>>>>>
> > > >>>>>>>> On Sat, May 23, 2020 at 7:48 AM Congxian Qiu <
> > > >>>> [hidden email]
> > > >>>>>>
> > > >>>>>>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> +1 for the proposal. It's good to have a unified description
> > > >>> and
> > > >>>>>> write
> > > >>>>>>> it
> > > >>>>>>>>> down in the wiki, so that every contributor has the same
> > > >>>>>> understanding
> > > >>>>>>> of
> > > >>>>>>>>> all the fields.
> > > >>>>>>>>>
> > > >>>>>>>>> Best,
> > > >>>>>>>>> Congxian
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> Till Rohrmann <[hidden email]> 于2020年5月23日周六
> > > >> 上午12:04写道：
> > > >>>>>>>>>
> > > >>>>>>>>>> Thanks for drafting this proposal Robert. +1 for the
> > > >>> proposal.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Cheers,
> > > >>>>>>>>>> Till
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Fri, May 22, 2020 at 5:39 PM Leonard Xu <
> > > >>> [hidden email]>
> > > >>>>>>> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>> Thanks bringing up this topic @Robert,  +1 to the
> > > >> proposal.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> It clarifies the JIRA fields well and should be a rule to
> > > >>>>> follow.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Best,
> > > >>>>>>>>>>> Leonard Xu
> > > >>>>>>>>>>>> 在 2020年5月22日，20:24，Aljoscha Krettek <
> > > >> [hidden email]
> > > >>>>
> > > >>>>> 写道：
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> +1 That's also how I think of the semantics of the
> > > >>> fields.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Aljoscha
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On 22.05.20 08:07, Robert Metzger wrote:
> > > >>>>>>>>>>>>> Hi all,
> > > >>>>>>>>>>>>> I have the feeling that the semantics of some of our
> > > >>> JIRA
> > > >>>>>> fields
> > > >>>>>>>>>> (mostly
> > > >>>>>>>>>>>>> "affects versions", "fix versions" and resolve /
> > > >> close)
> > > >>>> are
> > > >>>>>> not
> > > >>>>>>>>>> defined
> > > >>>>>>>>>>> in
> > > >>>>>>>>>>>>> the same way by all the core Flink contributors, which
> > > >>>> leads
> > > >>>>>> to
> > > >>>>>>>>> cases
> > > >>>>>>>>>>> where
> > > >>>>>>>>>>>>> I spend quite some time on filling the fields
> > > >> correctly
> > > >>>> (at
> > > >>>>>>> least
> > > >>>>>>>>>> what I
> > > >>>>>>>>>>>>> consider correctly), and then others changing them
> > > >> again
> > > >>>> to
> > > >>>>>>> match
> > > >>>>>>>>>> their
> > > >>>>>>>>>>>>> semantics.
> > > >>>>>>>>>>>>> In an effort to increase our efficiency, and since I'm
> > > >>>>>> creating
> > > >>>>>>> a
> > > >>>>>>>>> lot
> > > >>>>>>>>>> of
> > > >>>>>>>>>>>>> (test instability-related) tickets these days, I would
> > > >>>> like
> > > >>>>> to
> > > >>>>>>>>> discuss
> > > >>>>>>>>>>> the
> > > >>>>>>>>>>>>> semantics, come to a conclusion and document this in
> > > >> our
> > > >>>>> Wiki.
> > > >>>>>>>>>>>>> *Proposal:*
> > > >>>>>>>>>>>>> *Priority:*
> > > >>>>>>>>>>>>> "Blocker": needs to be resolved before a release
> > > >>> (matched
> > > >>>>>> based
> > > >>>>>>> on
> > > >>>>>>>>> fix
> > > >>>>>>>>>>>>> versions)
> > > >>>>>>>>>>>>> "Critical": strongly considered before a release
> > > >>>>>>>>>>>>> other priorities have no practical meaning in Flink.
> > > >>>>>>>>>>>>> *Component/s:*
> > > >>>>>>>>>>>>> Primary component relevant for this feature / fix.
> > > >>>>>>>>>>>>> For test-related issues, add the component the test
> > > >>>> belongs
> > > >>>>> to
> > > >>>>>>>> (for
> > > >>>>>>>>>>> example
> > > >>>>>>>>>>>>> "Connectors / Kafka" for Kafka test failures) +
> > > >> "Test".
> > > >>>>>>>>>>>>> The same applies for documentation tickets. For
> > > >> example,
> > > >>>> if
> > > >>>>>>>> there's
> > > >>>>>>>>>>>>> something wrong with the DataStream API, add it to the
> > > >>>> "API
> > > >>>>> /
> > > >>>>>>>>>>> DataStream"
> > > >>>>>>>>>>>>> and "Documentation" components.
> > > >>>>>>>>>>>>> *Affects Version/s:*Only for Bug / Task-type tickets:
> > > >> We
> > > >>>>> list
> > > >>>>>>> all
> > > >>>>>>>>>>> currently
> > > >>>>>>>>>>>>> supported and unreleased Flink versions known to be
> > > >>>> affected
> > > >>>>>> by
> > > >>>>>>>>> this.
> > > >>>>>>>>>>>>> Example: If I see a test failure that happens on
> > > >>> "master"
> > > >>>>> and
> > > >>>>>>>>>>>>> "release-1.11", I set "affects version" to "1.12.0"
> > > >> and
> > > >>>>>>> "1.11.0".
> > > >>>>>>>>>>>>> *Fix Version/s:*
> > > >>>>>>>>>>>>> For closed/resolved tickets, this field lists the
> > > >>> released
> > > >>>>>> Flink
> > > >>>>>>>>>>> versions
> > > >>>>>>>>>>>>> that contain a fix or feature for the first time.
> > > >>>>>>>>>>>>> For open tickets, it indicates that a fix / feature
> > > >>> should
> > > >>>>> be
> > > >>>>>>>>>> contained
> > > >>>>>>>>>>> in
> > > >>>>>>>>>>>>> the listed versions. Only blocker issues can block a
> > > >>>>> release,
> > > >>>>>>> all
> > > >>>>>>>>>> other
> > > >>>>>>>>>>>>> tickets which have "fix version/s" set at the time of
> > > >> a
> > > >>>>>> release
> > > >>>>>>>> and
> > > >>>>>>>>>> are
> > > >>>>>>>>>>>>> unresolved will be moved to the next version.
> > > >>>>>>>>>>>>> *Assignee:*
> > > >>>>>>>>>>>>> Person currently working on the ticket. Assigned after
> > > >>>>>>> conclusion
> > > >>>>>>>> on
> > > >>>>>>>>>>>>> approach by a committer.
> > > >>>>>>>>>>>>> Often, fixes are obvious and committers self-assign
> > > >> w/o
> > > >>>>>>>> discussion.
> > > >>>>>>>>>>>>> *Resolve / Close:*
> > > >>>>>>>>>>>>> You can either Resolve or Close a ticket once it is
> > > >> done
> > > >>>>>> (fixed,
> > > >>>>>>>>>>> rejected,
> > > >>>>>>>>>>>>> invalid, ...).
> > > >>>>>>>>>>>>> As a rule, we Close tickets instead of Resolving them
> > > >>> when
> > > >>>>>> they
> > > >>>>>>>> are
> > > >>>>>>>>>>> done.
> > > >>>>>>>>>>>>> Background: There are semantic differences for Resolve
> > > >>> and
> > > >>>>>> Close
> > > >>>>>>>>>>>>> (implementor vs reporter considers it done), but I
> > > >> don't
> > > >>>> see
> > > >>>>>> how
> > > >>>>>>>>> they
> > > >>>>>>>>>>>>> practically apply to the Flink project. Looking at the
> > > >>>>>> numbers,
> > > >>>>>>>>> Flink
> > > >>>>>>>>>>> has
> > > >>>>>>>>>>>>> 11066 closed tickets, and 3372 resolved tickets
> > > >> (that's
> > > >>>> why
> > > >>>>> I
> > > >>>>>>>>> propose
> > > >>>>>>>>>> to
> > > >>>>>>>>>>>>> close instead of resolve)
> > > >>>>>>>>>>>>> *Labels:*
> > > >>>>>>>>>>>>> "test-stability" for all test instabilities
> > > >>>>>>>>>>>>> "starter" for tickets suitable for new contributors
> > > >>>>>>>>>>>>> *Release Note:*
> > > >>>>>>>>>>>>> Small notes that will be included into the release
> > > >> notes
> > > >>>>>>> published
> > > >>>>>>>>>> with
> > > >>>>>>>>>>> the
> > > >>>>>>>>>>>>> release.
> > > >>>>>>>>>>>>> *All other fields are not used not used on a regular
> > > >>>> basis.*
> > > >>>>>>>>>>>>> Please +1 my proposal if you want it to be published
> > > >> in
> > > >>>> our
> > > >>>>>> Wiki
> > > >>>>>>>>> like
> > > >>>>>>>>>>> that
> > > >>>>>>>>>>>>> or let me know if I got something wrong here.
> > > >>>>>>>>>>>>> Best,
> > > >>>>>>>>>>>>> Robert
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>> --
> > > >>>>> Best, Jingsong Lee
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
>

[Piotr Nowojski-3]

> On 12 Jun 2020, at 15:44, Robert Metzger <[hidden email]> wrote:
>
> Piotrek, do you agree with my "affects version" explanation? I would like
> to bring this discussion to a conclusion.
>

+0 for this semantic from my side.

> On Tue, May 26, 2020 at 4:51 PM Till Rohrmann <[hidden email]> wrote:
>
>> If we change the meaning of the priority levels, then I would suggest to
>> have a dedicated discussion for it. This would also be more visible than
>> compared to being hidden in some lengthy discussion thread. I think the
>> proposed definitions of priority levels differ slightly from how the
>> community worked in the past.
>>
>> Cheers,
>> Till
>>
>> On Tue, May 26, 2020 at 4:30 PM Robert Metzger <[hidden email]>
>> wrote:
>>
>>> Hi,
>>>
>>> 1. I'm okay with updating the definition of the priorities for the reason
>>> you've mentioned.
>>>
>>> 2. "Affects version"
>>>
>>> The reason why like to mark affects version on unreleased versions is to
>>> clearly indicate which branch is affected by a bug. Given the current
>> Flink
>>> release status, if there's a bug only in "release-1.11", but not in
>>> "master", there is no way of figuring that out, if we only allow released
>>> versions for "affects version" (In my proposal, you would set "affects
>>> version" to '1.11.0', '1.12.0' to indicate that).
>>>
>>> What we could do is introduce "1.12-SNAPSHOT" as version to mark issues
>> on
>>> unreleased versions. (But then people might accidentally set the "fix
>>> version" to a "-SNAPSHOT" version.)
>>>
>>> I'm still in favor of my proposal. I have never heard a report from a
>>> confused user about our Jira fields (I guess they usually check bugs for
>>> released versions only)
>>>
>>>
>>> On Tue, May 26, 2020 at 12:39 PM Piotr Nowojski <[hidden email]>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Sorry for a bit late response. I have two concerns:
>>>>
>>>> 1. Priority
>>>>
>>>> I would propose to stretch priorities that we are using to
>> differentiate
>>>> between things that must be fixed for given release:
>>>>
>>>> BLOCKER - drop anything you are doing, this issue must be fixed right
>> now
>>>> CRITICAL - release can not happen without fixing it, but can be fixed a
>>>> bit later (for example without context switching and dropping whatever
>>> I’m
>>>> doing right now)
>>>> MAJOR - default, nice to have
>>>> Anything below - meh
>>>>
>>>> We were already using this semantic for tracking test instabilities
>>> during
>>>> the 1.11 release cycle. Good examples:
>>>>
>>>> BLOCKER - master branch not compiling, very frequent test failures (for
>>>> example almost every build affected), …
>>>> CRITICAL - performance regression/bug that we introduced in some
>> feature,
>>>> but which is not affecting other developers as much
>>>> MAJOR - freshly discovered test instability with unknown
>> impact/frequency
>>>> (could be happening once a year),
>>>>
>>>> 2. Affects version
>>>>
>>>> If bug is only on the master branch, does it affect an unreleased
>>> version?
>>>>
>>>> So far I was assuming that it doesn’t - unreleased bugs would have
>> empty
>>>> “affects version” field. My reasoning was that this field should be
>> used
>>>> for Flink users, to check which RELEASED Flink versions are affected by
>>>> some bug, that user is searching for. Otherwise it might be a bit
>>> confusing
>>>> if there are lots of bugs with both affects version and fix version set
>>> to
>>>> the same value.
>>>>
>>>> Piotrek
>>>>
>>>>> On 25 May 2020, at 16:40, Robert Metzger <[hidden email]>
>> wrote:
>>>>>
>>>>> Hi all,
>>>>> thanks a lot for the feedback. The majority of responses are very
>>>> positive
>>>>> to my proposal.
>>>>>
>>>>> I have put my proposal into our wiki:
>>>>>
>>>>
>>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=154995514
>>>>>
>>>>> Regarding the comments so far:
>>>>> @Jark: I clarified this in the wiki.
>>>>>
>>>>> @Israel: I have not considered build changing all 3000 resolved
>> tickets
>>>> to
>>>>> closed yet, but after consideration I don't think it is necessary. If
>>>>> others in the community would like to change them, please speak up in
>>>> this
>>>>> thread :)
>>>>>
>>>>> @Flavio: I agree that we can not ask new or infrequent users to fully
>>>>> adhere to these definitions. I added a note in the Wiki.
>>>>> Using the resolved state for indicating "PR available" is problematic
>>>>> because there are plenty of cases where PRs are stale (and this
>> ticket
>>>>> would then appear as a "resolved"). The Apache tools are adding a
>> link
>>> to
>>>>> the PR, and some contributors are setting the ticket to "In
>> Progress".
>>> I
>>>>> don't see a problem that we need to solve here.
>>>>>
>>>>> @Yun: Thank you for your comment. I added an example clarifying how I
>>>> would
>>>>> handle such a case. It is slightly different from your proposal: You
>>>>> suggested using x.y.0 versions, I used "the next supported,
>> unreleased
>>>>> version", because that's how we've done it so far (and I don't want
>> to
>>>>> change things, I just want to document how the majority of the core
>>>>> contributors are using JIRA).
>>>>>
>>>>> Here are all the changes (in green, blue are just formatting
>> changes) I
>>>>> made compared to my initial proposal:
>>>>>
>>>>
>>>
>> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=154995514&selectedPageVersions=4&selectedPageVersions=1
>>>>>
>>>>>
>>>>>
>>>>> On Mon, May 25, 2020 at 2:28 PM Congxian Qiu <[hidden email]
>>>
>>>> wrote:
>>>>>
>>>>>> @[hidden email] <[hidden email]>  Thanks for the
>> confirmation
>>>>>>
>>>>>> Best,
>>>>>> Congxian
>>>>>>
>>>>>>
>>>>>> Zhu Zhu <[hidden email]> 于2020年5月25日周一 下午4:13写道：
>>>>>>
>>>>>>> This is very helpful!
>>>>>>> +1
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Zhu Zhu
>>>>>>>
>>>>>>> Yang Wang <[hidden email]> 于2020年5月25日周一 下午4:04写道：
>>>>>>>
>>>>>>>> +1 from this useful proposal.
>>>>>>>>
>>>>>>>> This makes me clearer about "Resolve" and "Close" since I used to
>> be
>>>>>>>> confused by this two button.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Yang
>>>>>>>>
>>>>>>>> Jingsong Li <[hidden email]> 于2020年5月25日周一 下午3:10写道：
>>>>>>>>
>>>>>>>>> +1 for the proposal.
>>>>>>>>> It makes me clearer.
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Jingsong Lee
>>>>>>>>>
>>>>>>>>> On Mon, May 25, 2020 at 2:51 PM Zhijiang <
>>> [hidden email]
>>>>>>>>> .invalid>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Thanks for launching this discussion and giving so detailed
>> infos,
>>>>>>>>>> Robert!  +1 on my side for the proposal.
>>>>>>>>>>
>>>>>>>>>> For "Affects Version", I previously thought it was only for the
>>>>>>> already
>>>>>>>>>> released versions, so it can give a reminder that the fix should
>>>>>> also
>>>>>>>>> pick
>>>>>>>>>> into the related released branches for future minor versions.
>>>>>>>>>> I saw that Jark had somehow similar concerns for this field in
>>>>>> below
>>>>>>>>>> replies.  Either way makes sense for me as long as we give a
>>>>>>> determined
>>>>>>>>>> rule in Wiki.
>>>>>>>>>>
>>>>>>>>>> Re Flavio' s comments, I agree that the Jira reporter can leave
>>>>>> most
>>>>>>> of
>>>>>>>>>> the fields empty if not confirmed of them, then the respective
>>>>>>>> component
>>>>>>>>>> maintainer or committer can update them accordingly later.
>>>>>>>>>> But the state of Jira should not be marked as "resolved" when
>> the
>>>>>> PR
>>>>>>> is
>>>>>>>>>> detected, that is not fitting into the resolved semantic I
>> guess.
>>>>>> If
>>>>>>>>>> possible, the Jira can be updated as "in progress" automatically
>>> if
>>>>>>>>>> the respective PR is ready, then it will save some time to stat
>>>>>>>> progress
>>>>>>>>>> of related issues during release process.
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>> Zhijiang
>>>>>>>>>>
>> ------------------------------------------------------------------
>>>>>>>>>> From:Congxian Qiu <[hidden email]>
>>>>>>>>>> Send Time:2020年5月25日(星期一) 13:57
>>>>>>>>>> To:[hidden email] <[hidden email]>
>>>>>>>>>> Subject:Re: [DISCUSS] Semantics of our JIRA fields
>>>>>>>>>>
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> Currently, when I'm going to create an issue for
>> Project-website.
>>>>>> I'm
>>>>>>>> not
>>>>>>>>>> very sure what the "Affect Version/s" should be set. The problem
>>> is
>>>>>>>> that
>>>>>>>>>> the current Dockfile[1] in flink-web is broken because of the
>> EOL
>>>>>> of
>>>>>>>>> Ubuntu
>>>>>>>>>> 18.10[2], the project-web does not affect any release of Flink,
>> it
>>>>>>> does
>>>>>>>>>> affect the process to build website, so what's the version
>> should
>>> I
>>>>>>> set
>>>>>>>>> to?
>>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>> https://github.com/apache/flink-web/blob/bc66f0f0f463ab62a22e81df7d7efd301b76a6b4/docker/Dockerfile#L17
>>>>>>>>>> [2] https://wiki.ubuntu.com/Releases
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>> Congxian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Flavio Pompermaier <[hidden email]> 于2020年5月24日周日
>> 下午1:23写道：
>>>>>>>>>>
>>>>>>>>>>> In my experience it's quite complicated for a normal reporter
>> to
>>>>>> be
>>>>>>>>> able
>>>>>>>>>> to
>>>>>>>>>>> fill all the fields correctly (especially for new users).
>>>>>>>>>>> Usually you just wanto to report a problem, remember to add a
>> new
>>>>>>>>> feature
>>>>>>>>>>> or improve code/documentation but you can't really give a
>>>>>> priority,
>>>>>>>>>> assign
>>>>>>>>>>> the correct label or decide which releases will benefit of the
>>>>>>>> fix/new
>>>>>>>>>>> feature. This is something that only core developers could
>> decide
>>>>>>>>> (IMHO).
>>>>>>>>>>>
>>>>>>>>>>> My experiece says that it's better if normal users could just
>>>>>> open
>>>>>>>>>> tickets
>>>>>>>>>>> with some default (or mark ticket as new) and leave them in
>> such
>>>>>> a
>>>>>>>>> state
>>>>>>>>>>> until an experienced user, one that can assign tickets, have
>> the
>>>>>>> time
>>>>>>>>> to
>>>>>>>>>>> read it and immediately reject the ticket or accept it and
>>>>>> properly
>>>>>>>>>> assign
>>>>>>>>>>> priorities, fix version, etc.
>>>>>>>>>>>
>>>>>>>>>>> With respect to resolve/close I think that a good practice
>> could
>>>>>> be
>>>>>>>> to
>>>>>>>>>> mark
>>>>>>>>>>> automatically a ticket as resolved once that a PR is detected
>> for
>>>>>>>> that
>>>>>>>>>>> ticket, while marking it as closed should be done by the
>> commiter
>>>>>>> who
>>>>>>>>>> merge
>>>>>>>>>>> the PR.
>>>>>>>>>>>
>>>>>>>>>>> Probably this process would slightly increase the work of a
>>>>>>> committer
>>>>>>>>> but
>>>>>>>>>>> this would make things a lot cleaner and will bring the benefit
>>>>>> of
>>>>>>>>>> having a
>>>>>>>>>>> reliable and semantically sound JIRA state.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Flavio
>>>>>>>>>>>
>>>>>>>>>>> Il Dom 24 Mag 2020, 05:05 Israel Ekpo <[hidden email]>
>> ha
>>>>>>>>> scritto:
>>>>>>>>>>>
>>>>>>>>>>>> +1 for the proposal
>>>>>>>>>>>>
>>>>>>>>>>>> This will bring some consistency to the process
>>>>>>>>>>>>
>>>>>>>>>>>> Regarding Closed vs Resolved, should we go back and switch all
>>>>>>> the
>>>>>>>>>>> Resolved
>>>>>>>>>>>> issues to Closed so that is is not confusing to new people to
>>>>>> the
>>>>>>>>>> project
>>>>>>>>>>>> in the future that may not have seen this discussion?
>>>>>>>>>>>>
>>>>>>>>>>>> I would recommend changing it to Closed just to be consistent
>>>>>>> since
>>>>>>>>>> that
>>>>>>>>>>> is
>>>>>>>>>>>> the majority and the new process will be using Closed going
>>>>>>> forward
>>>>>>>>>>>>
>>>>>>>>>>>> Those are my thoughts for now
>>>>>>>>>>>>
>>>>>>>>>>>> On Sat, May 23, 2020 at 7:48 AM Congxian Qiu <
>>>>>>>> [hidden email]
>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> +1 for the proposal. It's good to have a unified description
>>>>>>> and
>>>>>>>>>> write
>>>>>>>>>>> it
>>>>>>>>>>>>> down in the wiki, so that every contributor has the same
>>>>>>>>>> understanding
>>>>>>>>>>> of
>>>>>>>>>>>>> all the fields.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best,
>>>>>>>>>>>>> Congxian
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Till Rohrmann <[hidden email]> 于2020年5月23日周六
>>>>>> 上午12:04写道：
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for drafting this proposal Robert. +1 for the
>>>>>>> proposal.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> Till
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, May 22, 2020 at 5:39 PM Leonard Xu <
>>>>>>> [hidden email]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks bringing up this topic @Robert,  +1 to the
>>>>>> proposal.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It clarifies the JIRA fields well and should be a rule to
>>>>>>>>> follow.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>> Leonard Xu
>>>>>>>>>>>>>>>> 在 2020年5月22日，20:24，Aljoscha Krettek <
>>>>>> [hidden email]
>>>>>>>>
>>>>>>>>> 写道：
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> +1 That's also how I think of the semantics of the
>>>>>>> fields.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Aljoscha
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 22.05.20 08:07, Robert Metzger wrote:
>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>> I have the feeling that the semantics of some of our
>>>>>>> JIRA
>>>>>>>>>> fields
>>>>>>>>>>>>>> (mostly
>>>>>>>>>>>>>>>>> "affects versions", "fix versions" and resolve /
>>>>>> close)
>>>>>>>> are
>>>>>>>>>> not
>>>>>>>>>>>>>> defined
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>> the same way by all the core Flink contributors, which
>>>>>>>> leads
>>>>>>>>>> to
>>>>>>>>>>>>> cases
>>>>>>>>>>>>>>> where
>>>>>>>>>>>>>>>>> I spend quite some time on filling the fields
>>>>>> correctly
>>>>>>>> (at
>>>>>>>>>>> least
>>>>>>>>>>>>>> what I
>>>>>>>>>>>>>>>>> consider correctly), and then others changing them
>>>>>> again
>>>>>>>> to
>>>>>>>>>>> match
>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>>>> semantics.
>>>>>>>>>>>>>>>>> In an effort to increase our efficiency, and since I'm
>>>>>>>>>> creating
>>>>>>>>>>> a
>>>>>>>>>>>>> lot
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> (test instability-related) tickets these days, I would
>>>>>>>> like
>>>>>>>>> to
>>>>>>>>>>>>> discuss
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> semantics, come to a conclusion and document this in
>>>>>> our
>>>>>>>>> Wiki.
>>>>>>>>>>>>>>>>> *Proposal:*
>>>>>>>>>>>>>>>>> *Priority:*
>>>>>>>>>>>>>>>>> "Blocker": needs to be resolved before a release
>>>>>>> (matched
>>>>>>>>>> based
>>>>>>>>>>> on
>>>>>>>>>>>>> fix
>>>>>>>>>>>>>>>>> versions)
>>>>>>>>>>>>>>>>> "Critical": strongly considered before a release
>>>>>>>>>>>>>>>>> other priorities have no practical meaning in Flink.
>>>>>>>>>>>>>>>>> *Component/s:*
>>>>>>>>>>>>>>>>> Primary component relevant for this feature / fix.
>>>>>>>>>>>>>>>>> For test-related issues, add the component the test
>>>>>>>> belongs
>>>>>>>>> to
>>>>>>>>>>>> (for
>>>>>>>>>>>>>>> example
>>>>>>>>>>>>>>>>> "Connectors / Kafka" for Kafka test failures) +
>>>>>> "Test".
>>>>>>>>>>>>>>>>> The same applies for documentation tickets. For
>>>>>> example,
>>>>>>>> if
>>>>>>>>>>>> there's
>>>>>>>>>>>>>>>>> something wrong with the DataStream API, add it to the
>>>>>>>> "API
>>>>>>>>> /
>>>>>>>>>>>>>>> DataStream"
>>>>>>>>>>>>>>>>> and "Documentation" components.
>>>>>>>>>>>>>>>>> *Affects Version/s:*Only for Bug / Task-type tickets:
>>>>>> We
>>>>>>>>> list
>>>>>>>>>>> all
>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>> supported and unreleased Flink versions known to be
>>>>>>>> affected
>>>>>>>>>> by
>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>>> Example: If I see a test failure that happens on
>>>>>>> "master"
>>>>>>>>> and
>>>>>>>>>>>>>>>>> "release-1.11", I set "affects version" to "1.12.0"
>>>>>> and
>>>>>>>>>>> "1.11.0".
>>>>>>>>>>>>>>>>> *Fix Version/s:*
>>>>>>>>>>>>>>>>> For closed/resolved tickets, this field lists the
>>>>>>> released
>>>>>>>>>> Flink
>>>>>>>>>>>>>>> versions
>>>>>>>>>>>>>>>>> that contain a fix or feature for the first time.
>>>>>>>>>>>>>>>>> For open tickets, it indicates that a fix / feature
>>>>>>> should
>>>>>>>>> be
>>>>>>>>>>>>>> contained
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>> the listed versions. Only blocker issues can block a
>>>>>>>>> release,
>>>>>>>>>>> all
>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>> tickets which have "fix version/s" set at the time of
>>>>>> a
>>>>>>>>>> release
>>>>>>>>>>>> and
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>> unresolved will be moved to the next version.
>>>>>>>>>>>>>>>>> *Assignee:*
>>>>>>>>>>>>>>>>> Person currently working on the ticket. Assigned after
>>>>>>>>>>> conclusion
>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>> approach by a committer.
>>>>>>>>>>>>>>>>> Often, fixes are obvious and committers self-assign
>>>>>> w/o
>>>>>>>>>>>> discussion.
>>>>>>>>>>>>>>>>> *Resolve / Close:*
>>>>>>>>>>>>>>>>> You can either Resolve or Close a ticket once it is
>>>>>> done
>>>>>>>>>> (fixed,
>>>>>>>>>>>>>>> rejected,
>>>>>>>>>>>>>>>>> invalid, ...).
>>>>>>>>>>>>>>>>> As a rule, we Close tickets instead of Resolving them
>>>>>>> when
>>>>>>>>>> they
>>>>>>>>>>>> are
>>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>>>> Background: There are semantic differences for Resolve
>>>>>>> and
>>>>>>>>>> Close
>>>>>>>>>>>>>>>>> (implementor vs reporter considers it done), but I
>>>>>> don't
>>>>>>>> see
>>>>>>>>>> how
>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>> practically apply to the Flink project. Looking at the
>>>>>>>>>> numbers,
>>>>>>>>>>>>> Flink
>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>> 11066 closed tickets, and 3372 resolved tickets
>>>>>> (that's
>>>>>>>> why
>>>>>>>>> I
>>>>>>>>>>>>> propose
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> close instead of resolve)
>>>>>>>>>>>>>>>>> *Labels:*
>>>>>>>>>>>>>>>>> "test-stability" for all test instabilities
>>>>>>>>>>>>>>>>> "starter" for tickets suitable for new contributors
>>>>>>>>>>>>>>>>> *Release Note:*
>>>>>>>>>>>>>>>>> Small notes that will be included into the release
>>>>>> notes
>>>>>>>>>>> published
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>> *All other fields are not used not used on a regular
>>>>>>>> basis.*
>>>>>>>>>>>>>>>>> Please +1 my proposal if you want it to be published
>>>>>> in
>>>>>>>> our
>>>>>>>>>> Wiki
>>>>>>>>>>>>> like
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>> or let me know if I got something wrong here.
>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Best, Jingsong Lee
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>

[Robert Metzger]

Since there were no further comments on this discussion, I removed the
"draft" label from the Wiki page and I consider the Jira semantics proposal
agreed upon.

On Mon, Jun 15, 2020 at 9:49 AM Piotr Nowojski <[hidden email]> wrote:

>
> > On 12 Jun 2020, at 15:44, Robert Metzger <[hidden email]> wrote:
> >
> > Piotrek, do you agree with my "affects version" explanation? I would like
> > to bring this discussion to a conclusion.
> >
>
> +0 for this semantic from my side.
>
> > On Tue, May 26, 2020 at 4:51 PM Till Rohrmann <[hidden email]>
> wrote:
> >
> >> If we change the meaning of the priority levels, then I would suggest to
> >> have a dedicated discussion for it. This would also be more visible than
> >> compared to being hidden in some lengthy discussion thread. I think the
> >> proposed definitions of priority levels differ slightly from how the
> >> community worked in the past.
> >>
> >> Cheers,
> >> Till
> >>
> >> On Tue, May 26, 2020 at 4:30 PM Robert Metzger <[hidden email]>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> 1. I'm okay with updating the definition of the priorities for the
> reason
> >>> you've mentioned.
> >>>
> >>> 2. "Affects version"
> >>>
> >>> The reason why like to mark affects version on unreleased versions is
> to
> >>> clearly indicate which branch is affected by a bug. Given the current
> >> Flink
> >>> release status, if there's a bug only in "release-1.11", but not in
> >>> "master", there is no way of figuring that out, if we only allow
> released
> >>> versions for "affects version" (In my proposal, you would set "affects
> >>> version" to '1.11.0', '1.12.0' to indicate that).
> >>>
> >>> What we could do is introduce "1.12-SNAPSHOT" as version to mark issues
> >> on
> >>> unreleased versions. (But then people might accidentally set the "fix
> >>> version" to a "-SNAPSHOT" version.)
> >>>
> >>> I'm still in favor of my proposal. I have never heard a report from a
> >>> confused user about our Jira fields (I guess they usually check bugs
> for
> >>> released versions only)
> >>>
> >>>
> >>> On Tue, May 26, 2020 at 12:39 PM Piotr Nowojski <[hidden email]>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Sorry for a bit late response. I have two concerns:
> >>>>
> >>>> 1. Priority
> >>>>
> >>>> I would propose to stretch priorities that we are using to
> >> differentiate
> >>>> between things that must be fixed for given release:
> >>>>
> >>>> BLOCKER - drop anything you are doing, this issue must be fixed right
> >> now
> >>>> CRITICAL - release can not happen without fixing it, but can be fixed
> a
> >>>> bit later (for example without context switching and dropping whatever
> >>> I’m
> >>>> doing right now)
> >>>> MAJOR - default, nice to have
> >>>> Anything below - meh
> >>>>
> >>>> We were already using this semantic for tracking test instabilities
> >>> during
> >>>> the 1.11 release cycle. Good examples:
> >>>>
> >>>> BLOCKER - master branch not compiling, very frequent test failures
> (for
> >>>> example almost every build affected), …
> >>>> CRITICAL - performance regression/bug that we introduced in some
> >> feature,
> >>>> but which is not affecting other developers as much
> >>>> MAJOR - freshly discovered test instability with unknown
> >> impact/frequency
> >>>> (could be happening once a year),
> >>>>
> >>>> 2. Affects version
> >>>>
> >>>> If bug is only on the master branch, does it affect an unreleased
> >>> version?
> >>>>
> >>>> So far I was assuming that it doesn’t - unreleased bugs would have
> >> empty
> >>>> “affects version” field. My reasoning was that this field should be
> >> used
> >>>> for Flink users, to check which RELEASED Flink versions are affected
> by
> >>>> some bug, that user is searching for. Otherwise it might be a bit
> >>> confusing
> >>>> if there are lots of bugs with both affects version and fix version
> set
> >>> to
> >>>> the same value.
> >>>>
> >>>> Piotrek
> >>>>
> >>>>> On 25 May 2020, at 16:40, Robert Metzger <[hidden email]>
> >> wrote:
> >>>>>
> >>>>> Hi all,
> >>>>> thanks a lot for the feedback. The majority of responses are very
> >>>> positive
> >>>>> to my proposal.
> >>>>>
> >>>>> I have put my proposal into our wiki:
> >>>>>
> >>>>
> >>>
> >>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=154995514
> >>>>>
> >>>>> Regarding the comments so far:
> >>>>> @Jark: I clarified this in the wiki.
> >>>>>
> >>>>> @Israel: I have not considered build changing all 3000 resolved
> >> tickets
> >>>> to
> >>>>> closed yet, but after consideration I don't think it is necessary. If
> >>>>> others in the community would like to change them, please speak up in
> >>>> this
> >>>>> thread :)
> >>>>>
> >>>>> @Flavio: I agree that we can not ask new or infrequent users to fully
> >>>>> adhere to these definitions. I added a note in the Wiki.
> >>>>> Using the resolved state for indicating "PR available" is problematic
> >>>>> because there are plenty of cases where PRs are stale (and this
> >> ticket
> >>>>> would then appear as a "resolved"). The Apache tools are adding a
> >> link
> >>> to
> >>>>> the PR, and some contributors are setting the ticket to "In
> >> Progress".
> >>> I
> >>>>> don't see a problem that we need to solve here.
> >>>>>
> >>>>> @Yun: Thank you for your comment. I added an example clarifying how I
> >>>> would
> >>>>> handle such a case. It is slightly different from your proposal: You
> >>>>> suggested using x.y.0 versions, I used "the next supported,
> >> unreleased
> >>>>> version", because that's how we've done it so far (and I don't want
> >> to
> >>>>> change things, I just want to document how the majority of the core
> >>>>> contributors are using JIRA).
> >>>>>
> >>>>> Here are all the changes (in green, blue are just formatting
> >> changes) I
> >>>>> made compared to my initial proposal:
> >>>>>
> >>>>
> >>>
> >>
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=154995514&selectedPageVersions=4&selectedPageVersions=1
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, May 25, 2020 at 2:28 PM Congxian Qiu <[hidden email]
> >>>
> >>>> wrote:
> >>>>>
> >>>>>> @[hidden email] <[hidden email]>  Thanks for the
> >> confirmation
> >>>>>>
> >>>>>> Best,
> >>>>>> Congxian
> >>>>>>
> >>>>>>
> >>>>>> Zhu Zhu <[hidden email]> 于2020年5月25日周一 下午4:13写道：
> >>>>>>
> >>>>>>> This is very helpful!
> >>>>>>> +1
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Zhu Zhu
> >>>>>>>
> >>>>>>> Yang Wang <[hidden email]> 于2020年5月25日周一 下午4:04写道：
> >>>>>>>
> >>>>>>>> +1 from this useful proposal.
> >>>>>>>>
> >>>>>>>> This makes me clearer about "Resolve" and "Close" since I used to
> >> be
> >>>>>>>> confused by this two button.
> >>>>>>>>
> >>>>>>>> Best,
> >>>>>>>> Yang
> >>>>>>>>
> >>>>>>>> Jingsong Li <[hidden email]> 于2020年5月25日周一 下午3:10写道：
> >>>>>>>>
> >>>>>>>>> +1 for the proposal.
> >>>>>>>>> It makes me clearer.
> >>>>>>>>>
> >>>>>>>>> Best,
> >>>>>>>>> Jingsong Lee
> >>>>>>>>>
> >>>>>>>>> On Mon, May 25, 2020 at 2:51 PM Zhijiang <
> >>> [hidden email]
> >>>>>>>>> .invalid>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Thanks for launching this discussion and giving so detailed
> >> infos,
> >>>>>>>>>> Robert!  +1 on my side for the proposal.
> >>>>>>>>>>
> >>>>>>>>>> For "Affects Version", I previously thought it was only for the
> >>>>>>> already
> >>>>>>>>>> released versions, so it can give a reminder that the fix should
> >>>>>> also
> >>>>>>>>> pick
> >>>>>>>>>> into the related released branches for future minor versions.
> >>>>>>>>>> I saw that Jark had somehow similar concerns for this field in
> >>>>>> below
> >>>>>>>>>> replies.  Either way makes sense for me as long as we give a
> >>>>>>> determined
> >>>>>>>>>> rule in Wiki.
> >>>>>>>>>>
> >>>>>>>>>> Re Flavio' s comments, I agree that the Jira reporter can leave
> >>>>>> most
> >>>>>>> of
> >>>>>>>>>> the fields empty if not confirmed of them, then the respective
> >>>>>>>> component
> >>>>>>>>>> maintainer or committer can update them accordingly later.
> >>>>>>>>>> But the state of Jira should not be marked as "resolved" when
> >> the
> >>>>>> PR
> >>>>>>> is
> >>>>>>>>>> detected, that is not fitting into the resolved semantic I
> >> guess.
> >>>>>> If
> >>>>>>>>>> possible, the Jira can be updated as "in progress" automatically
> >>> if
> >>>>>>>>>> the respective PR is ready, then it will save some time to stat
> >>>>>>>> progress
> >>>>>>>>>> of related issues during release process.
> >>>>>>>>>>
> >>>>>>>>>> Best,
> >>>>>>>>>> Zhijiang
> >>>>>>>>>>
> >> ------------------------------------------------------------------
> >>>>>>>>>> From:Congxian Qiu <[hidden email]>
> >>>>>>>>>> Send Time:2020年5月25日(星期一) 13:57
> >>>>>>>>>> To:[hidden email] <[hidden email]>
> >>>>>>>>>> Subject:Re: [DISCUSS] Semantics of our JIRA fields
> >>>>>>>>>>
> >>>>>>>>>> Hi
> >>>>>>>>>>
> >>>>>>>>>> Currently, when I'm going to create an issue for
> >> Project-website.
> >>>>>> I'm
> >>>>>>>> not
> >>>>>>>>>> very sure what the "Affect Version/s" should be set. The problem
> >>> is
> >>>>>>>> that
> >>>>>>>>>> the current Dockfile[1] in flink-web is broken because of the
> >> EOL
> >>>>>> of
> >>>>>>>>> Ubuntu
> >>>>>>>>>> 18.10[2], the project-web does not affect any release of Flink,
> >> it
> >>>>>>> does
> >>>>>>>>>> affect the process to build website, so what's the version
> >> should
> >>> I
> >>>>>>> set
> >>>>>>>>> to?
> >>>>>>>>>>
> >>>>>>>>>> [1]
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>
> >>
> https://github.com/apache/flink-web/blob/bc66f0f0f463ab62a22e81df7d7efd301b76a6b4/docker/Dockerfile#L17
> >>>>>>>>>> [2] https://wiki.ubuntu.com/Releases
> >>>>>>>>>>
> >>>>>>>>>> Best,
> >>>>>>>>>> Congxian
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Flavio Pompermaier <[hidden email]> 于2020年5月24日周日
> >> 下午1:23写道：
> >>>>>>>>>>
> >>>>>>>>>>> In my experience it's quite complicated for a normal reporter
> >> to
> >>>>>> be
> >>>>>>>>> able
> >>>>>>>>>> to
> >>>>>>>>>>> fill all the fields correctly (especially for new users).
> >>>>>>>>>>> Usually you just wanto to report a problem, remember to add a
> >> new
> >>>>>>>>> feature
> >>>>>>>>>>> or improve code/documentation but you can't really give a
> >>>>>> priority,
> >>>>>>>>>> assign
> >>>>>>>>>>> the correct label or decide which releases will benefit of the
> >>>>>>>> fix/new
> >>>>>>>>>>> feature. This is something that only core developers could
> >> decide
> >>>>>>>>> (IMHO).
> >>>>>>>>>>>
> >>>>>>>>>>> My experiece says that it's better if normal users could just
> >>>>>> open
> >>>>>>>>>> tickets
> >>>>>>>>>>> with some default (or mark ticket as new) and leave them in
> >> such
> >>>>>> a
> >>>>>>>>> state
> >>>>>>>>>>> until an experienced user, one that can assign tickets, have
> >> the
> >>>>>>> time
> >>>>>>>>> to
> >>>>>>>>>>> read it and immediately reject the ticket or accept it and
> >>>>>> properly
> >>>>>>>>>> assign
> >>>>>>>>>>> priorities, fix version, etc.
> >>>>>>>>>>>
> >>>>>>>>>>> With respect to resolve/close I think that a good practice
> >> could
> >>>>>> be
> >>>>>>>> to
> >>>>>>>>>> mark
> >>>>>>>>>>> automatically a ticket as resolved once that a PR is detected
> >> for
> >>>>>>>> that
> >>>>>>>>>>> ticket, while marking it as closed should be done by the
> >> commiter
> >>>>>>> who
> >>>>>>>>>> merge
> >>>>>>>>>>> the PR.
> >>>>>>>>>>>
> >>>>>>>>>>> Probably this process would slightly increase the work of a
> >>>>>>> committer
> >>>>>>>>> but
> >>>>>>>>>>> this would make things a lot cleaner and will bring the benefit
> >>>>>> of
> >>>>>>>>>> having a
> >>>>>>>>>>> reliable and semantically sound JIRA state.
> >>>>>>>>>>>
> >>>>>>>>>>> Cheers,
> >>>>>>>>>>> Flavio
> >>>>>>>>>>>
> >>>>>>>>>>> Il Dom 24 Mag 2020, 05:05 Israel Ekpo <[hidden email]>
> >> ha
> >>>>>>>>> scritto:
> >>>>>>>>>>>
> >>>>>>>>>>>> +1 for the proposal
> >>>>>>>>>>>>
> >>>>>>>>>>>> This will bring some consistency to the process
> >>>>>>>>>>>>
> >>>>>>>>>>>> Regarding Closed vs Resolved, should we go back and switch all
> >>>>>>> the
> >>>>>>>>>>> Resolved
> >>>>>>>>>>>> issues to Closed so that is is not confusing to new people to
> >>>>>> the
> >>>>>>>>>> project
> >>>>>>>>>>>> in the future that may not have seen this discussion?
> >>>>>>>>>>>>
> >>>>>>>>>>>> I would recommend changing it to Closed just to be consistent
> >>>>>>> since
> >>>>>>>>>> that
> >>>>>>>>>>> is
> >>>>>>>>>>>> the majority and the new process will be using Closed going
> >>>>>>> forward
> >>>>>>>>>>>>
> >>>>>>>>>>>> Those are my thoughts for now
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Sat, May 23, 2020 at 7:48 AM Congxian Qiu <
> >>>>>>>> [hidden email]
> >>>>>>>>>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> +1 for the proposal. It's good to have a unified description
> >>>>>>> and
> >>>>>>>>>> write
> >>>>>>>>>>> it
> >>>>>>>>>>>>> down in the wiki, so that every contributor has the same
> >>>>>>>>>> understanding
> >>>>>>>>>>> of
> >>>>>>>>>>>>> all the fields.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Best,
> >>>>>>>>>>>>> Congxian
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Till Rohrmann <[hidden email]> 于2020年5月23日周六
> >>>>>> 上午12:04写道：
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks for drafting this proposal Robert. +1 for the
> >>>>>>> proposal.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>>> Till
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Fri, May 22, 2020 at 5:39 PM Leonard Xu <
> >>>>>>> [hidden email]>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thanks bringing up this topic @Robert,  +1 to the
> >>>>>> proposal.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It clarifies the JIRA fields well and should be a rule to
> >>>>>>>>> follow.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Best,
> >>>>>>>>>>>>>>> Leonard Xu
> >>>>>>>>>>>>>>>> 在 2020年5月22日，20:24，Aljoscha Krettek <
> >>>>>> [hidden email]
> >>>>>>>>
> >>>>>>>>> 写道：
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> +1 That's also how I think of the semantics of the
> >>>>>>> fields.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Aljoscha
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 22.05.20 08:07, Robert Metzger wrote:
> >>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>> I have the feeling that the semantics of some of our
> >>>>>>> JIRA
> >>>>>>>>>> fields
> >>>>>>>>>>>>>> (mostly
> >>>>>>>>>>>>>>>>> "affects versions", "fix versions" and resolve /
> >>>>>> close)
> >>>>>>>> are
> >>>>>>>>>> not
> >>>>>>>>>>>>>> defined
> >>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>> the same way by all the core Flink contributors, which
> >>>>>>>> leads
> >>>>>>>>>> to
> >>>>>>>>>>>>> cases
> >>>>>>>>>>>>>>> where
> >>>>>>>>>>>>>>>>> I spend quite some time on filling the fields
> >>>>>> correctly
> >>>>>>>> (at
> >>>>>>>>>>> least
> >>>>>>>>>>>>>> what I
> >>>>>>>>>>>>>>>>> consider correctly), and then others changing them
> >>>>>> again
> >>>>>>>> to
> >>>>>>>>>>> match
> >>>>>>>>>>>>>> their
> >>>>>>>>>>>>>>>>> semantics.
> >>>>>>>>>>>>>>>>> In an effort to increase our efficiency, and since I'm
> >>>>>>>>>> creating
> >>>>>>>>>>> a
> >>>>>>>>>>>>> lot
> >>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>> (test instability-related) tickets these days, I would
> >>>>>>>> like
> >>>>>>>>> to
> >>>>>>>>>>>>> discuss
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> semantics, come to a conclusion and document this in
> >>>>>> our
> >>>>>>>>> Wiki.
> >>>>>>>>>>>>>>>>> *Proposal:*
> >>>>>>>>>>>>>>>>> *Priority:*
> >>>>>>>>>>>>>>>>> "Blocker": needs to be resolved before a release
> >>>>>>> (matched
> >>>>>>>>>> based
> >>>>>>>>>>> on
> >>>>>>>>>>>>> fix
> >>>>>>>>>>>>>>>>> versions)
> >>>>>>>>>>>>>>>>> "Critical": strongly considered before a release
> >>>>>>>>>>>>>>>>> other priorities have no practical meaning in Flink.
> >>>>>>>>>>>>>>>>> *Component/s:*
> >>>>>>>>>>>>>>>>> Primary component relevant for this feature / fix.
> >>>>>>>>>>>>>>>>> For test-related issues, add the component the test
> >>>>>>>> belongs
> >>>>>>>>> to
> >>>>>>>>>>>> (for
> >>>>>>>>>>>>>>> example
> >>>>>>>>>>>>>>>>> "Connectors / Kafka" for Kafka test failures) +
> >>>>>> "Test".
> >>>>>>>>>>>>>>>>> The same applies for documentation tickets. For
> >>>>>> example,
> >>>>>>>> if
> >>>>>>>>>>>> there's
> >>>>>>>>>>>>>>>>> something wrong with the DataStream API, add it to the
> >>>>>>>> "API
> >>>>>>>>> /
> >>>>>>>>>>>>>>> DataStream"
> >>>>>>>>>>>>>>>>> and "Documentation" components.
> >>>>>>>>>>>>>>>>> *Affects Version/s:*Only for Bug / Task-type tickets:
> >>>>>> We
> >>>>>>>>> list
> >>>>>>>>>>> all
> >>>>>>>>>>>>>>> currently
> >>>>>>>>>>>>>>>>> supported and unreleased Flink versions known to be
> >>>>>>>> affected
> >>>>>>>>>> by
> >>>>>>>>>>>>> this.
> >>>>>>>>>>>>>>>>> Example: If I see a test failure that happens on
> >>>>>>> "master"
> >>>>>>>>> and
> >>>>>>>>>>>>>>>>> "release-1.11", I set "affects version" to "1.12.0"
> >>>>>> and
> >>>>>>>>>>> "1.11.0".
> >>>>>>>>>>>>>>>>> *Fix Version/s:*
> >>>>>>>>>>>>>>>>> For closed/resolved tickets, this field lists the
> >>>>>>> released
> >>>>>>>>>> Flink
> >>>>>>>>>>>>>>> versions
> >>>>>>>>>>>>>>>>> that contain a fix or feature for the first time.
> >>>>>>>>>>>>>>>>> For open tickets, it indicates that a fix / feature
> >>>>>>> should
> >>>>>>>>> be
> >>>>>>>>>>>>>> contained
> >>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>> the listed versions. Only blocker issues can block a
> >>>>>>>>> release,
> >>>>>>>>>>> all
> >>>>>>>>>>>>>> other
> >>>>>>>>>>>>>>>>> tickets which have "fix version/s" set at the time of
> >>>>>> a
> >>>>>>>>>> release
> >>>>>>>>>>>> and
> >>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>> unresolved will be moved to the next version.
> >>>>>>>>>>>>>>>>> *Assignee:*
> >>>>>>>>>>>>>>>>> Person currently working on the ticket. Assigned after
> >>>>>>>>>>> conclusion
> >>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>> approach by a committer.
> >>>>>>>>>>>>>>>>> Often, fixes are obvious and committers self-assign
> >>>>>> w/o
> >>>>>>>>>>>> discussion.
> >>>>>>>>>>>>>>>>> *Resolve / Close:*
> >>>>>>>>>>>>>>>>> You can either Resolve or Close a ticket once it is
> >>>>>> done
> >>>>>>>>>> (fixed,
> >>>>>>>>>>>>>>> rejected,
> >>>>>>>>>>>>>>>>> invalid, ...).
> >>>>>>>>>>>>>>>>> As a rule, we Close tickets instead of Resolving them
> >>>>>>> when
> >>>>>>>>>> they
> >>>>>>>>>>>> are
> >>>>>>>>>>>>>>> done.
> >>>>>>>>>>>>>>>>> Background: There are semantic differences for Resolve
> >>>>>>> and
> >>>>>>>>>> Close
> >>>>>>>>>>>>>>>>> (implementor vs reporter considers it done), but I
> >>>>>> don't
> >>>>>>>> see
> >>>>>>>>>> how
> >>>>>>>>>>>>> they
> >>>>>>>>>>>>>>>>> practically apply to the Flink project. Looking at the
> >>>>>>>>>> numbers,
> >>>>>>>>>>>>> Flink
> >>>>>>>>>>>>>>> has
> >>>>>>>>>>>>>>>>> 11066 closed tickets, and 3372 resolved tickets
> >>>>>> (that's
> >>>>>>>> why
> >>>>>>>>> I
> >>>>>>>>>>>>> propose
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> close instead of resolve)
> >>>>>>>>>>>>>>>>> *Labels:*
> >>>>>>>>>>>>>>>>> "test-stability" for all test instabilities
> >>>>>>>>>>>>>>>>> "starter" for tickets suitable for new contributors
> >>>>>>>>>>>>>>>>> *Release Note:*
> >>>>>>>>>>>>>>>>> Small notes that will be included into the release
> >>>>>> notes
> >>>>>>>>>>> published
> >>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>> *All other fields are not used not used on a regular
> >>>>>>>> basis.*
> >>>>>>>>>>>>>>>>> Please +1 my proposal if you want it to be published
> >>>>>> in
> >>>>>>>> our
> >>>>>>>>>> Wiki
> >>>>>>>>>>>>> like
> >>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>> or let me know if I got something wrong here.
> >>>>>>>>>>>>>>>>> Best,
> >>>>>>>>>>>>>>>>> Robert
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Best, Jingsong Lee
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
>
>