(DEPRECATED) Apache Flink Mailing List archive.

[DISCUSS] Semantics of our JIRA fields

Classic

List

Threaded

29 messages Options

Robert Metzger

[DISCUSS] Semantics of our JIRA fields

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

Xintong Song

Re: [DISCUSS] Semantics of our JIRA fields

Thanks for bringing this up, Robert.

+1 from my side on your proposal.

Additionally, there's one question that I would appreciate if someone can
clarify them.

When talking about "all currently supported and unreleased Flink
versions", *which
versions are supported and which are not? *I've heard different versions of
stories about this. One version say that the Flink community only supports
the most recent 2 releases, which means currently (before 1.11.0 is
released) only 1.10.x & 1.9.x are supported. Another say the most recent 3
releases. However, I don't really find this information from any
formal/credible sources, e.g. the project website. Maybe there is such
information that I overlooked? If not, I would suggest to add it to our
website.

Thank you~

Xintong Song

On Fri, May 22, 2020 at 2:07 PM Robert Metzger <[hidden email]> 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
>

Robert Metzger

Re: [DISCUSS] Semantics of our JIRA fields

Thanks for your response!

The information about supported Flink releases is quite hidden, but it is
on the downloads page in the "Update Policy for old releases" section, and
it states:

As of March 2017, the Flink community decided
> <http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Time-based-releases-in-Flink-tp15386p15394.html> to
> support the current and previous minor release with bugfixes. If 1.2.x is
> the current release, 1.1.y is the previous minor supported release. Both
> versions will receive bugfixes for critical issues.

On Fri, May 22, 2020 at 9:19 AM Xintong Song <[hidden email]> wrote:

> Thanks for bringing this up, Robert.
>
> +1 from my side on your proposal.
>
> Additionally, there's one question that I would appreciate if someone can
> clarify them.
>
> When talking about "all currently supported and unreleased Flink
> versions", *which
> versions are supported and which are not? *I've heard different versions of
> stories about this. One version say that the Flink community only supports
> the most recent 2 releases, which means currently (before 1.11.0 is
> released) only 1.10.x & 1.9.x are supported. Another say the most recent 3
> releases. However, I don't really find this information from any
> formal/credible sources, e.g. the project website. Maybe there is such
> information that I overlooked? If not, I would suggest to add it to our
> website.
>
> Thank you~
>
> Xintong Song
>
>
>
> On Fri, May 22, 2020 at 2:07 PM Robert Metzger <[hidden email]>
> 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
> >
>

Xintong Song

Re: [DISCUSS] Semantics of our JIRA fields

Thanks for the pointer. That's clear enough for me.

Thank you~

Xintong Song

On Fri, May 22, 2020 at 3:32 PM Robert Metzger <[hidden email]> wrote:

> Thanks for your response!
>
> The information about supported Flink releases is quite hidden, but it is
> on the downloads page in the "Update Policy for old releases" section, and
> it states:
>
> As of March 2017, the Flink community decided
> > <
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Time-based-releases-in-Flink-tp15386p15394.html>
> to
> > support the current and previous minor release with bugfixes. If 1.2.x is
> > the current release, 1.1.y is the previous minor supported release. Both
> > versions will receive bugfixes for critical issues.
>
>
> On Fri, May 22, 2020 at 9:19 AM Xintong Song <[hidden email]>
> wrote:
>
> > Thanks for bringing this up, Robert.
> >
> > +1 from my side on your proposal.
> >
> > Additionally, there's one question that I would appreciate if someone can
> > clarify them.
> >
> > When talking about "all currently supported and unreleased Flink
> > versions", *which
> > versions are supported and which are not? *I've heard different versions
> of
> > stories about this. One version say that the Flink community only
> supports
> > the most recent 2 releases, which means currently (before 1.11.0 is
> > released) only 1.10.x & 1.9.x are supported. Another say the most recent
> 3
> > releases. However, I don't really find this information from any
> > formal/credible sources, e.g. the project website. Maybe there is such
> > information that I overlooked? If not, I would suggest to add it to our
> > website.
> >
> > Thank you~
> >
> > Xintong Song
> >
> >
> >
> > On Fri, May 22, 2020 at 2:07 PM Robert Metzger <[hidden email]>
> > 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
> > >
> >
>

Yangze Guo

Re: [DISCUSS] Semantics of our JIRA fields

In reply to this post by Robert Metzger

Thanks for driving this discussion, Robert.

+1 for the proposal.

Best,
Yangze Guo

On Fri, May 22, 2020 at 3:32 PM Robert Metzger <[hidden email]> wrote:

>
> Thanks for your response!
>
> The information about supported Flink releases is quite hidden, but it is
> on the downloads page in the "Update Policy for old releases" section, and
> it states:
>
> As of March 2017, the Flink community decided
> > <http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Time-based-releases-in-Flink-tp15386p15394.html> to
> > support the current and previous minor release with bugfixes. If 1.2.x is
> > the current release, 1.1.y is the previous minor supported release. Both
> > versions will receive bugfixes for critical issues.
>
>
> On Fri, May 22, 2020 at 9:19 AM Xintong Song <[hidden email]> wrote:
>
> > Thanks for bringing this up, Robert.
> >
> > +1 from my side on your proposal.
> >
> > Additionally, there's one question that I would appreciate if someone can
> > clarify them.
> >
> > When talking about "all currently supported and unreleased Flink
> > versions", *which
> > versions are supported and which are not? *I've heard different versions of
> > stories about this. One version say that the Flink community only supports
> > the most recent 2 releases, which means currently (before 1.11.0 is
> > released) only 1.10.x & 1.9.x are supported. Another say the most recent 3
> > releases. However, I don't really find this information from any
> > formal/credible sources, e.g. the project website. Maybe there is such
> > information that I overlooked? If not, I would suggest to add it to our
> > website.
> >
> > Thank you~
> >
> > Xintong Song
> >
> >
> >
> > On Fri, May 22, 2020 at 2:07 PM Robert Metzger <[hidden email]>
> > 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
> > >
> >

curcur

Re: [DISCUSS] Semantics of our JIRA fields

In reply to this post by Robert Metzger

+1
Thanks Robert for these detailed explanations!
It is definitely useful to have a clear standard to avoid confusion when
creating Jira, especially for starters.

Thanks for the efforts!

Best,
Yuan

On Fri, May 22, 2020 at 2:07 PM Robert Metzger <[hidden email]> wrote:

Jark Wu-2

Re: [DISCUSS] Semantics of our JIRA fields

Thanks Robert for bringing up this. +1 to the proposal.

From my perspective, I would like we can clearify one more thing about "fix
version/s" in this wiki.
IIRC, if a fix is targeted to be fixed in "1.11.0", then it obviously is
fixed in "1.12.0", so such a bug fix should only set "1.11.0", not both
"1.11.0, 1.12.0".
This rule doesn't apply to 1.11.x where x >= 1. This problem happens
frequently during release and such information is quite hidden.

Best,
Jark

On Fri, 22 May 2020 at 17:12, Yuan Mei <[hidden email]> wrote:

> +1
> Thanks Robert for these detailed explanations!
> It is definitely useful to have a clear standard to avoid confusion when
> creating Jira, especially for starters.
>
> Thanks for the efforts!
>
> Best,
> Yuan
>
>
> On Fri, May 22, 2020 at 2:07 PM Robert Metzger <[hidden email]>
> 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
> >
>

Dian Fu-2

Re: [DISCUSS] Semantics of our JIRA fields

Thanks for bringing up this discussion, Robert. +1 to the proposal, it's very clear.

> 在 2020年5月22日，下午7:50，Jark Wu <[hidden email]> 写道：
>
> Thanks Robert for bringing up this. +1 to the proposal.
>
> From my perspective, I would like we can clearify one more thing about "fix
> version/s" in this wiki.
> IIRC, if a fix is targeted to be fixed in "1.11.0", then it obviously is
> fixed in "1.12.0", so such a bug fix should only set "1.11.0", not both
> "1.11.0, 1.12.0".
> This rule doesn't apply to 1.11.x where x >= 1. This problem happens
> frequently during release and such information is quite hidden.
>
> Best,
> Jark
>
> On Fri, 22 May 2020 at 17:12, Yuan Mei <[hidden email]> wrote:
>
>> +1
>> Thanks Robert for these detailed explanations!
>> It is definitely useful to have a clear standard to avoid confusion when
>> creating Jira, especially for starters.
>>
>> Thanks for the efforts!
>>
>> Best,
>> Yuan
>>
>>
>> On Fri, May 22, 2020 at 2:07 PM Robert Metzger <[hidden email]>
>> 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
>>>
>>

Aljoscha Krettek-2

Re: [DISCUSS] Semantics of our JIRA fields

In reply to this post by Robert Metzger

+1 That's also how I think of the semantics of the fields.

Aljoscha

On 22.05.20 08:07, Robert Metzger wrote:

Leonard Xu

Re: [DISCUSS] Semantics of our JIRA fields

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
>

Till Rohrmann

Re: [DISCUSS] Semantics of our JIRA fields

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
> >
>
>

Congxian Qiu

Re: [DISCUSS] Semantics of our JIRA fields

+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
> > >
> >
> >
>

Israel Ekpo

Re: [DISCUSS] Semantics of our JIRA fields

+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
> > > >
> > >
> > >
> >
>

Flavio Pompermaier

Re: [DISCUSS] Semantics of our JIRA fields

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
> > > > >
> > > >
> > > >
> > >
> >
>

Congxian Qiu

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
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Chesnay Schepler-3

Re: [DISCUSS] Semantics of our JIRA fields

flink-web is independent from any release, so there should be no
affects/fix version.

On 25/05/2020 07:56, Congxian Qiu wrote:

> 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
>>>>>>

Yun Tang

Re: [DISCUSS] Semantics of our JIRA fields

Hi

I like the idea to give clear description of JIRA fields in Flink community when creating tickets.

After reading from Robert's explanation, I found my previous understanding differs from the field at "Affect Version/s",
and is close to general understanding as JIRA official guide said[1]: Affects version is the version in which a bug or problem was found.

If the bug is introduced and found in Flink-1.8.1 and still existing in current release-1.11 branch. I would like to fill in the first version and
next major versions, eg. Flink-1.8.1, Flink-1.9.0, Flink-1.10.0 and Flink-1.11.0. Integrated with Robert's explanation, I think a better choice might be
filling in the version which brought in and all currently supported and unreleased Flink versions known to be affected by this.

I think it's okay to give different explanations on the same field for different communities.
If so, I think we should provide this notice in the official web-site, JIRA template or any other place instead of just dev mail list to reach developer/users.

[1] https://www.atlassian.com/agile/tutorials/versions

Best
Yun Tang

________________________________
From: Chesnay Schepler <[hidden email]>
Sent: Monday, May 25, 2020 14:36
To: [hidden email] <[hidden email]>; Congxian Qiu <[hidden email]>
Subject: Re: [DISCUSS] Semantics of our JIRA fields

flink-web is independent from any release, so there should be no
affects/fix version.

On 25/05/2020 07:56, Congxian Qiu wrote:

Zhijiang(wangzhijiang999)

Re: [DISCUSS] Semantics of our JIRA fields

In reply to this post by Congxian Qiu

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写道：

Jingsong Li

Re: [DISCUSS] Semantics of our JIRA fields

+1 for the proposal.
It makes me clearer.

Best,
Jingsong Lee

On Mon, May 25, 2020 at 2:51 PM Zhijiang <[hidden email]>
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

Yang Wang

Re: [DISCUSS] Semantics of our JIRA fields

+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
>