>>>>>
> >>>>>> Best,
> >>>>>> Congxian
> >>>>>>
> >>>>>>
> >>>>>> Zhu Zhu 于2020年5月25日周一 下午4:13写道：
> >>>>>>
> >>>>>>> This
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
>&
Yang
> > > >>>>
> > > >>>> Jingsong Li 于2020年5月25日周一 下午3:10写道：
> > > >>>>
> > > >>>>> +1 for the proposal.
> > > >>>>> It makes me clearer.
> > > >>>>>
&
gt;>>
> > >>>>>> Thanks for launching this discussion and giving so detailed infos,
> > >>>>>> Robert! +1 on my side for the proposal.
> > >>>>>>
> > >>>>>> For "Affects Version", I previ
;, 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.
> >>>>>>
gt;> 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 c
s 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 res
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
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
> p
ogress" 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@f
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
&g
ache.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
nt: 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
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
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
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
+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
+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.
>
>
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
> > 在
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
+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
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,
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
+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
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
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
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
>
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
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
29 matches
Mail list logo
