Re: [DISCUSS] Semantics of our JIRA fields

[Robert Metzger]

n and fix version
> set
> >>> to
> >>>> the same value.
> >>>>
> >>>> Piotrek
> >>>>
> >>>>> On 25 May 2020, at 16:40, Robert Metzger 
> >> wrote:
> >>>>>
> >>>>> Hi all,
> >>>>> thanks a lot for the feedback. The majority of responses are very
> >>>> positive
> >>>>> to my proposal.
> >>>>>
> >>>>> I have put my proposal into our wiki:
> >>>>>
> >>>>
> >>>
> >>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=154995514
> >>>>>
> >>>>> Regarding the comments so far:
> >>>>> @Jark: I clarified this in the wiki.
> >>>>>
> >>>>> @Israel: I have not considered build changing all 3000 resolved
> >> tickets
> >>>> to
> >>>>> closed yet, but after consideration I don't think it is necessary. If
> >>>>> others in the community would like to change them, please speak up in
> >>>> this
> >>>>> thread :)
> >>>>>
> >>>>> @Flavio: I agree that we can not ask new or infrequent users to fully
> >>>>> adhere to these definitions. I added a note in the Wiki.
> >>>>> Using the resolved state for indicating "PR available" is problematic
> >>>>> because there are plenty of cases where PRs are stale (and this
> >> ticket
> >>>>> would then appear as a "resolved"). The Apache tools are adding a
> >> link
> >>> to
> >>>>> the PR, and some contributors are setting the ticket to "In
> >> Progress".
> >>> I
> >>>>> don't see a problem that we need to solve here.
> >>>>>
> >>>>> @Yun: Thank you for your comment. I added an example clarifying how I
> >>>> would
> >>>>> handle such a case. It is slightly different from your proposal: You
> >>>>> suggested using x.y.0 versions, I used "the next supported,
> >> unreleased
> >>>>> version", because that's how we've done it so far (and I don't want
> >> to
> >>>>> change things, I just want to document how the majority of the core
> >>>>> contributors are using JIRA).
> >>>>>
> >>>>> Here are all the changes (in green, blue are just formatting
> >> changes) I
> >>>>> made compared to my initial proposal:
> >>>>>
> >>>>
> >>>
> >>
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=154995514=4=1
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, May 25, 2020 at 2:28 PM Congxian Qiu  >>>
> >>>> wrote:
> >>>>>
> >>>>>> @ches...@apache.org   Thanks for the
> >> confirmation
> >>>>>>
> >>>>>> Best,
> >>>>>> Congxian
> >>>>>>
> >>>>>>
> >>>>>> Zhu Zhu  于2020年5月25日周一 下午4:13写道：
> >>>>>>
> >>>>>>> This is very helpful!
> >>>>>>> +1
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Zhu Zhu
> >>>>>>>
> >>>>>>> Yang Wang  于2020年5月25日周一 下午4:04写道：
> >>>>>>>
> >>>>>>>> +1 from this useful proposal.
> >>>>>>>>
> >>>>>>>> This makes me clearer about "Resolve" and "Close" since I used to
> >> be
> >>>>>>>> confused by this two button.
> >>>>>>>>
> >>>>>>>> Best,
> >>>>>>>> Yang
> >>>>>>>>
> >>>>>>>> Jingsong Li  于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 <
> >>> wangzh

Re: [DISCUSS] Semantics of our JIRA fields

[Piotr Nowojski]

@Jark: I clarified this in the wiki.
>>>>> 
>>>>> @Israel: I have not considered build changing all 3000 resolved
>> tickets
>>>> to
>>>>> closed yet, but after consideration I don't think it is necessary. If
>>>>> others in the community would like to change them, please speak up in
>>>> this
>>>>> thread :)
>>>>> 
>>>>> @Flavio: I agree that we can not ask new or infrequent users to fully
>>>>> adhere to these definitions. I added a note in the Wiki.
>>>>> Using the resolved state for indicating "PR available" is problematic
>>>>> because there are plenty of cases where PRs are stale (and this
>> ticket
>>>>> would then appear as a "resolved"). The Apache tools are adding a
>> link
>>> to
>>>>> the PR, and some contributors are setting the ticket to "In
>> Progress".
>>> I
>>>>> don't see a problem that we need to solve here.
>>>>> 
>>>>> @Yun: Thank you for your comment. I added an example clarifying how I
>>>> would
>>>>> handle such a case. It is slightly different from your proposal: You
>>>>> suggested using x.y.0 versions, I used "the next supported,
>> unreleased
>>>>> version", because that's how we've done it so far (and I don't want
>> to
>>>>> change things, I just want to document how the majority of the core
>>>>> contributors are using JIRA).
>>>>> 
>>>>> Here are all the changes (in green, blue are just formatting
>> changes) I
>>>>> made compared to my initial proposal:
>>>>> 
>>>> 
>>> 
>> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=154995514=4=1
>>>>> 
>>>>> 
>>>>> 
>>>>> On Mon, May 25, 2020 at 2:28 PM Congxian Qiu >> 
>>>> wrote:
>>>>> 
>>>>>> @ches...@apache.org   Thanks for the
>> confirmation
>>>>>> 
>>>>>> Best,
>>>>>> Congxian
>>>>>> 
>>>>>> 
>>>>>> Zhu Zhu  于2020年5月25日周一 下午4:13写道：
>>>>>> 
>>>>>>> This is very helpful!
>>>>>>> +1
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Zhu Zhu
>>>>>>> 
>>>>>>> Yang Wang  于2020年5月25日周一 下午4:04写道：
>>>>>>> 
>>>>>>>> +1 from this useful proposal.
>>>>>>>> 
>>>>>>>> This makes me clearer about "Resolve" and "Close" since I used to
>> be
>>>>>>>> confused by this two button.
>>>>>>>> 
>>>>>>>> Best,
>>>>>>>> Yang
>>>>>>>> 
>>>>>>>> Jingsong Li  于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 <
>>> wangzhijiang...@aliyun.com
>>>>>>>>> .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: [DISCUSS] Semantics of our JIRA fields

[Robert Metzger]

 them, please speak up in
> > > this
> > > > thread :)
> > > >
> > > > @Flavio: I agree that we can not ask new or infrequent users to fully
> > > > adhere to these definitions. I added a note in the Wiki.
> > > > Using the resolved state for indicating "PR available" is problematic
> > > > because there are plenty of cases where PRs are stale (and this
> ticket
> > > > would then appear as a "resolved"). The Apache tools are adding a
> link
> > to
> > > > the PR, and some contributors are setting the ticket to "In
> Progress".
> > I
> > > > don't see a problem that we need to solve here.
> > > >
> > > > @Yun: Thank you for your comment. I added an example clarifying how I
> > > would
> > > > handle such a case. It is slightly different from your proposal: You
> > > > suggested using x.y.0 versions, I used "the next supported,
> unreleased
> > > > version", because that's how we've done it so far (and I don't want
> to
> > > > change things, I just want to document how the majority of the core
> > > > contributors are using JIRA).
> > > >
> > > > Here are all the changes (in green, blue are just formatting
> changes) I
> > > > made compared to my initial proposal:
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=154995514=4=1
> > > >
> > > >
> > > >
> > > > On Mon, May 25, 2020 at 2:28 PM Congxian Qiu  >
> > > wrote:
> > > >
> > > >> @ches...@apache.org   Thanks for the
> confirmation
> > > >>
> > > >> Best,
> > > >> Congxian
> > > >>
> > > >>
> > > >> Zhu Zhu  于2020年5月25日周一 下午4:13写道：
> > > >>
> > > >>> This is very helpful!
> > > >>> +1
> > > >>>
> > > >>> Thanks,
> > > >>> Zhu Zhu
> > > >>>
> > > >>> Yang Wang  于2020年5月25日周一 下午4:04写道：
> > > >>>
> > > >>>> +1 from this useful proposal.
> > > >>>>
> > > >>>> This makes me clearer about "Resolve" and "Close" since I used to
> be
> > > >>>> confused by this two button.
> > > >>>>
> > > >>>> Best,
> > > >>>> Yang
> > > >>>>
> > > >>>> Jingsong Li  于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 <
> > wangzhijiang...@aliyun.com
> > > >>>>> .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 "resol

Re: [DISCUSS] Semantics of our JIRA fields

[Till Rohrmann]

 is slightly different from your proposal: You
> > > suggested using x.y.0 versions, I used "the next supported, unreleased
> > > version", because that's how we've done it so far (and I don't want to
> > > change things, I just want to document how the majority of the core
> > > contributors are using JIRA).
> > >
> > > Here are all the changes (in green, blue are just formatting changes) I
> > > made compared to my initial proposal:
> > >
> >
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=154995514=4=1
> > >
> > >
> > >
> > > On Mon, May 25, 2020 at 2:28 PM Congxian Qiu 
> > wrote:
> > >
> > >> @ches...@apache.org   Thanks for the confirmation
> > >>
> > >> Best,
> > >> Congxian
> > >>
> > >>
> > >> Zhu Zhu  于2020年5月25日周一 下午4:13写道：
> > >>
> > >>> This is very helpful!
> > >>> +1
> > >>>
> > >>> Thanks,
> > >>> Zhu Zhu
> > >>>
> > >>> Yang Wang  于2020年5月25日周一 下午4:04写道：
> > >>>
> > >>>> +1 from this useful proposal.
> > >>>>
> > >>>> This makes me clearer about "Resolve" and "Close" since I used to be
> > >>>> confused by this two button.
> > >>>>
> > >>>> Best,
> > >>>> Yang
> > >>>>
> > >>>> Jingsong Li  于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 <
> wangzhijiang...@aliyun.com
> > >>>>> .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 
> > >>>>>> Send Time:2020年5月25日(星期一) 13:57
> > >>>>>> To:dev@flink.apache.org 
> > >>>>>> 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.

Re: [DISCUSS] Semantics of our JIRA fields

[Robert Metzger]

t; >>
> >>> This is very helpful!
> >>> +1
> >>>
> >>> Thanks,
> >>> Zhu Zhu
> >>>
> >>> Yang Wang  于2020年5月25日周一 下午4:04写道：
> >>>
> >>>> +1 from this useful proposal.
> >>>>
> >>>> This makes me clearer about "Resolve" and "Close" since I used to be
> >>>> confused by this two button.
> >>>>
> >>>> Best,
> >>>> Yang
> >>>>
> >>>> Jingsong Li  于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  >>>>> .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 
> >>>>>> Send Time:2020年5月25日(星期一) 13:57
> >>>>>> To:dev@flink.apache.org 
> >>>>>> 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  于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 wan

Re: [DISCUSS] Semantics of our JIRA fields

[Piotr Nowojski]

 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 
>>>>>> Send Time:2020年5月25日(星期一) 13:57
>>>>>> To:dev@flink.apache.org 
>>>>>> 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  于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 JI

Re: [DISCUSS] Semantics of our JIRA fields

[Robert Metzger]

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

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

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

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

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

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

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



On Mon, May 25, 2020 at 2:28 PM Congxian Qiu  wrote:

> @ches...@apache.org   Thanks for the confirmation
>
> Best,
> Congxian
>
>
> Zhu Zhu  于2020年5月25日周一 下午4:13写道：
>
> > This is very helpful!
> > +1
> >
> > Thanks,
> > Zhu Zhu
> >
> > Yang Wang  于2020年5月25日周一 下午4:04写道：
> >
> > > +1 from this useful proposal.
> > >
> > > This makes me clearer about "Resolve" and "Close" since I used to be
> > > confused by this two button.
> > >
> > > Best,
> > > Yang
> > >
> > > Jingsong Li  于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  > > > .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 
> > > > > Send Time:2020年5月25日(星期一) 13:57
> > > > > To:dev@flink.apache.org 
> > > > > 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 Do

Re: [DISCUSS] Semantics of our JIRA fields

[Congxian Qiu]

@ches...@apache.org   Thanks for the confirmation

Best,
Congxian


Zhu Zhu  于2020年5月25日周一 下午4:13写道：

> This is very helpful!
> +1
>
> Thanks,
> Zhu Zhu
>
> Yang Wang  于2020年5月25日周一 下午4:04写道：
>
> > +1 from this useful proposal.
> >
> > This makes me clearer about "Resolve" and "Close" since I used to be
> > confused by this two button.
> >
> > Best,
> > Yang
> >
> > Jingsong Li  于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  > > .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 
> > > > Send Time:2020年5月25日(星期一) 13:57
> > > > To:dev@flink.apache.org 
> > > > 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  于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 

Re: [DISCUSS] Semantics of our JIRA fields

[Zhu Zhu]

This is very helpful!
+1

Thanks,
Zhu Zhu

Yang Wang  于2020年5月25日周一 下午4:04写道：

> +1 from this useful proposal.
>
> This makes me clearer about "Resolve" and "Close" since I used to be
> confused by this two button.
>
> Best,
> Yang
>
> Jingsong Li  于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  > .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 
> > > Send Time:2020年5月25日(星期一) 13:57
> > > To:dev@flink.apache.org 
> > > 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  于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
> > >

Re: [DISCUSS] Semantics of our JIRA fields

[Yang Wang]

+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  于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  .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 
> > Send Time:2020年5月25日(星期一) 13:57
> > To:dev@flink.apache.org 
> > 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  于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  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
>

Re: [DISCUSS] Semantics of our JIRA fields

[Jingsong Li]

+1 for the proposal.
It makes me clearer.

Best,
Jingsong Lee

On Mon, May 25, 2020 at 2:51 PM Zhijiang 
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 
> Send Time:2020年5月25日(星期一) 13:57
> To:dev@flink.apache.org 
> 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  于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  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 
> > > 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  于2020年5月23日周六 上午12:04写道：
> > > >
> > > > > Thanks for drafting this proposal 

Re: [DISCUSS] Semantics of our JIRA fields

[Zhijiang]

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 
Send Time:2020年5月25日(星期一) 13:57
To:dev@flink.apache.org 
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  于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  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 
> > 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  于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 
> 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  写道：
> > > > > >
> > > > > > +1 That's also how I think

Re: [DISCUSS] Semantics of our JIRA fields

[Yun Tang]

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 
Sent: Monday, May 25, 2020 14:36
To: dev@flink.apache.org ; Congxian Qiu 

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:
> 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  于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  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 
>>> 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  于2020年5月23日周六 上午12:04写道：
>>>>
>>>>> Thanks for drafting this proposal Robert. +1 for the proposal.
>>>>>
>>>>> Cheers,
>>>>> Till
>>>>>
>>>>> On Fri, May 22, 2020 a

Re: [DISCUSS] Semantics of our JIRA fields

[Chesnay Schepler]

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

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

+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

Re: [DISCUSS] Semantics of our JIRA fields

[Congxian Qiu]

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

Re: [DISCUSS] Semantics of our JIRA fields

[Flavio Pompermaier]

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  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 
> 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  于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  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  写道：
> > > > >
> > > > > +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.
> > > > 

Re: [DISCUSS] Semantics of our JIRA fields

[Israel Ekpo]

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

Re: [DISCUSS] Semantics of our JIRA fields

[Congxian Qiu]

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

Re: [DISCUSS] Semantics of our JIRA fields

[Till Rohrmann]

Thanks for drafting this proposal Robert. +1 for the proposal.

Cheers,
Till

On Fri, May 22, 2020 at 5:39 PM Leonard Xu  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  写道：
> >
> > +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
> >
>
>

Re: [DISCUSS] Semantics of our JIRA fields

[Leonard Xu]

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

Re: [DISCUSS] Semantics of our JIRA fields

[Aljoscha Krettek]

+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

Re: [DISCUSS] Semantics of our JIRA fields

[Dian Fu]

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

> 在 2020年5月22日，下午7:50，Jark Wu  写道：
> 
> 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  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 
>> 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
>>> 
>> 

Re: [DISCUSS] Semantics of our JIRA fields

[Jark Wu]

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

Re: [DISCUSS] Semantics of our JIRA fields

[Yuan Mei]

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

Re: [DISCUSS] Semantics of our JIRA fields

[Xintong Song]

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

Re: [DISCUSS] Semantics of our JIRA fields

[Yangze Guo]

Thanks for driving this discussion, Robert.

+1 for the proposal.

Best,
Yangze Guo


On Fri, May 22, 2020 at 3:32 PM Robert Metzger  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
> > 
> >  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  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 
> > 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.*
> > >
> > > 

Re: [DISCUSS] Semantics of our JIRA fields

[Robert Metzger]

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

Re: [DISCUSS] Semantics of our JIRA fields

[Xintong Song]

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

[DISCUSS] Semantics of our JIRA fields

[Robert Metzger]

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