> On 12 Jun 2020, at 15:44, Robert Metzger <rmetz...@apache.org> wrote: > > Piotrek, do you agree with my "affects version" explanation? I would like > to bring this discussion to a conclusion. >
+0 for this semantic from my side. > On Tue, May 26, 2020 at 4:51 PM Till Rohrmann <trohrm...@apache.org> wrote: > >> If we change the meaning of the priority levels, then I would suggest to >> have a dedicated discussion for it. This would also be more visible than >> compared to being hidden in some lengthy discussion thread. I think the >> proposed definitions of priority levels differ slightly from how the >> community worked in the past. >> >> Cheers, >> Till >> >> On Tue, May 26, 2020 at 4:30 PM Robert Metzger <rmetz...@apache.org> >> wrote: >> >>> Hi, >>> >>> 1. I'm okay with updating the definition of the priorities for the reason >>> you've mentioned. >>> >>> 2. "Affects version" >>> >>> The reason why like to mark affects version on unreleased versions is to >>> clearly indicate which branch is affected by a bug. Given the current >> Flink >>> release status, if there's a bug only in "release-1.11", but not in >>> "master", there is no way of figuring that out, if we only allow released >>> versions for "affects version" (In my proposal, you would set "affects >>> version" to '1.11.0', '1.12.0' to indicate that). >>> >>> What we could do is introduce "1.12-SNAPSHOT" as version to mark issues >> on >>> unreleased versions. (But then people might accidentally set the "fix >>> version" to a "-SNAPSHOT" version.) >>> >>> I'm still in favor of my proposal. I have never heard a report from a >>> confused user about our Jira fields (I guess they usually check bugs for >>> released versions only) >>> >>> >>> On Tue, May 26, 2020 at 12:39 PM Piotr Nowojski <pi...@ververica.com> >>> wrote: >>> >>>> Hi, >>>> >>>> Sorry for a bit late response. I have two concerns: >>>> >>>> 1. Priority >>>> >>>> I would propose to stretch priorities that we are using to >> differentiate >>>> between things that must be fixed for given release: >>>> >>>> BLOCKER - drop anything you are doing, this issue must be fixed right >> now >>>> CRITICAL - release can not happen without fixing it, but can be fixed a >>>> bit later (for example without context switching and dropping whatever >>> I’m >>>> doing right now) >>>> MAJOR - default, nice to have >>>> Anything below - meh >>>> >>>> We were already using this semantic for tracking test instabilities >>> during >>>> the 1.11 release cycle. Good examples: >>>> >>>> BLOCKER - master branch not compiling, very frequent test failures (for >>>> example almost every build affected), … >>>> CRITICAL - performance regression/bug that we introduced in some >> feature, >>>> but which is not affecting other developers as much >>>> MAJOR - freshly discovered test instability with unknown >> impact/frequency >>>> (could be happening once a year), >>>> >>>> 2. Affects version >>>> >>>> If bug is only on the master branch, does it affect an unreleased >>> version? >>>> >>>> So far I was assuming that it doesn’t - unreleased bugs would have >> empty >>>> “affects version” field. My reasoning was that this field should be >> used >>>> for Flink users, to check which RELEASED Flink versions are affected by >>>> some bug, that user is searching for. Otherwise it might be a bit >>> confusing >>>> if there are lots of bugs with both affects version and fix version set >>> to >>>> the same value. >>>> >>>> Piotrek >>>> >>>>> On 25 May 2020, at 16:40, Robert Metzger <rmetz...@apache.org> >> wrote: >>>>> >>>>> Hi all, >>>>> thanks a lot for the feedback. The majority of responses are very >>>> positive >>>>> to my proposal. >>>>> >>>>> I have put my proposal into our wiki: >>>>> >>>> >>> >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=154995514 >>>>> >>>>> Regarding the comments so far: >>>>> @Jark: I clarified this in the wiki. >>>>> >>>>> @Israel: I have not considered build changing all 3000 resolved >> tickets >>>> to >>>>> closed yet, but after consideration I don't think it is necessary. If >>>>> others in the community would like to change them, please speak up in >>>> this >>>>> thread :) >>>>> >>>>> @Flavio: I agree that we can not ask new or infrequent users to fully >>>>> adhere to these definitions. I added a note in the Wiki. >>>>> Using the resolved state for indicating "PR available" is problematic >>>>> because there are plenty of cases where PRs are stale (and this >> ticket >>>>> would then appear as a "resolved"). The Apache tools are adding a >> link >>> to >>>>> the PR, and some contributors are setting the ticket to "In >> Progress". >>> I >>>>> don't see a problem that we need to solve here. >>>>> >>>>> @Yun: Thank you for your comment. I added an example clarifying how I >>>> would >>>>> handle such a case. It is slightly different from your proposal: You >>>>> suggested using x.y.0 versions, I used "the next supported, >> unreleased >>>>> version", because that's how we've done it so far (and I don't want >> to >>>>> change things, I just want to document how the majority of the core >>>>> contributors are using JIRA). >>>>> >>>>> Here are all the changes (in green, blue are just formatting >> changes) I >>>>> made compared to my initial proposal: >>>>> >>>> >>> >> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=154995514&selectedPageVersions=4&selectedPageVersions=1 >>>>> >>>>> >>>>> >>>>> On Mon, May 25, 2020 at 2:28 PM Congxian Qiu <qcx978132...@gmail.com >>> >>>> wrote: >>>>> >>>>>> @ches...@apache.org <ches...@apache.org> Thanks for the >> confirmation >>>>>> >>>>>> Best, >>>>>> Congxian >>>>>> >>>>>> >>>>>> Zhu Zhu <reed...@gmail.com> 于2020年5月25日周一 下午4:13写道： >>>>>> >>>>>>> This is very helpful! >>>>>>> +1 >>>>>>> >>>>>>> Thanks, >>>>>>> Zhu Zhu >>>>>>> >>>>>>> Yang Wang <danrtsey...@gmail.com> 于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 <jingsongl...@gmail.com> 于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 <qcx978132...@gmail.com> >>>>>>>>>> Send Time:2020年5月25日(星期一) 13:57 >>>>>>>>>> To:dev@flink.apache.org <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 <pomperma...@okkam.it> 于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 <israele...@gmail.com> >> 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 < >>>>>>>> qcx978132...@gmail.com >>>>>>>>>> >>>>>>>>>>>> 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 <trohrm...@apache.org> 于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 < >>>>>>> xbjt...@gmail.com> >>>>>>>>>>> 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 < >>>>>> aljos...@apache.org >>>>>>>> >>>>>>>>> 写道： >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> +1 That's also how I think of the semantics of the >>>>>>> fields. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Aljoscha >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 22.05.20 08:07, Robert Metzger wrote: >>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>> I have the feeling that the semantics of some of our >>>>>>> JIRA >>>>>>>>>> fields >>>>>>>>>>>>>> (mostly >>>>>>>>>>>>>>>>> "affects versions", "fix versions" and resolve / >>>>>> close) >>>>>>>> are >>>>>>>>>> not >>>>>>>>>>>>>> defined >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>> the same way by all the core Flink contributors, which >>>>>>>> leads >>>>>>>>>> to >>>>>>>>>>>>> cases >>>>>>>>>>>>>>> where >>>>>>>>>>>>>>>>> I spend quite some time on filling the fields >>>>>> correctly >>>>>>>> (at >>>>>>>>>>> least >>>>>>>>>>>>>> what I >>>>>>>>>>>>>>>>> consider correctly), and then others changing them >>>>>> again >>>>>>>> to >>>>>>>>>>> match >>>>>>>>>>>>>> their >>>>>>>>>>>>>>>>> semantics. >>>>>>>>>>>>>>>>> In an effort to increase our efficiency, and since I'm >>>>>>>>>> creating >>>>>>>>>>> a >>>>>>>>>>>>> lot >>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>> (test instability-related) tickets these days, I would >>>>>>>> like >>>>>>>>> to >>>>>>>>>>>>> discuss >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> semantics, come to a conclusion and document this in >>>>>> our >>>>>>>>> Wiki. >>>>>>>>>>>>>>>>> *Proposal:* >>>>>>>>>>>>>>>>> *Priority:* >>>>>>>>>>>>>>>>> "Blocker": needs to be resolved before a release >>>>>>> (matched >>>>>>>>>> based >>>>>>>>>>> on >>>>>>>>>>>>> fix >>>>>>>>>>>>>>>>> versions) >>>>>>>>>>>>>>>>> "Critical": strongly considered before a release >>>>>>>>>>>>>>>>> other priorities have no practical meaning in Flink. >>>>>>>>>>>>>>>>> *Component/s:* >>>>>>>>>>>>>>>>> Primary component relevant for this feature / fix. >>>>>>>>>>>>>>>>> For test-related issues, add the component the test >>>>>>>> belongs >>>>>>>>> to >>>>>>>>>>>> (for >>>>>>>>>>>>>>> example >>>>>>>>>>>>>>>>> "Connectors / Kafka" for Kafka test failures) + >>>>>> "Test". >>>>>>>>>>>>>>>>> The same applies for documentation tickets. For >>>>>> example, >>>>>>>> if >>>>>>>>>>>> there's >>>>>>>>>>>>>>>>> something wrong with the DataStream API, add it to the >>>>>>>> "API >>>>>>>>> / >>>>>>>>>>>>>>> DataStream" >>>>>>>>>>>>>>>>> and "Documentation" components. >>>>>>>>>>>>>>>>> *Affects Version/s:*Only for Bug / Task-type tickets: >>>>>> We >>>>>>>>> list >>>>>>>>>>> all >>>>>>>>>>>>>>> currently >>>>>>>>>>>>>>>>> supported and unreleased Flink versions known to be >>>>>>>> affected >>>>>>>>>> by >>>>>>>>>>>>> this. >>>>>>>>>>>>>>>>> Example: If I see a test failure that happens on >>>>>>> "master" >>>>>>>>> and >>>>>>>>>>>>>>>>> "release-1.11", I set "affects version" to "1.12.0" >>>>>> and >>>>>>>>>>> "1.11.0". >>>>>>>>>>>>>>>>> *Fix Version/s:* >>>>>>>>>>>>>>>>> For closed/resolved tickets, this field lists the >>>>>>> released >>>>>>>>>> Flink >>>>>>>>>>>>>>> versions >>>>>>>>>>>>>>>>> that contain a fix or feature for the first time. >>>>>>>>>>>>>>>>> For open tickets, it indicates that a fix / feature >>>>>>> should >>>>>>>>> be >>>>>>>>>>>>>> contained >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>> the listed versions. Only blocker issues can block a >>>>>>>>> release, >>>>>>>>>>> all >>>>>>>>>>>>>> other >>>>>>>>>>>>>>>>> tickets which have "fix version/s" set at the time of >>>>>> a >>>>>>>>>> release >>>>>>>>>>>> and >>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>> unresolved will be moved to the next version. >>>>>>>>>>>>>>>>> *Assignee:* >>>>>>>>>>>>>>>>> Person currently working on the ticket. Assigned after >>>>>>>>>>> conclusion >>>>>>>>>>>> on >>>>>>>>>>>>>>>>> approach by a committer. >>>>>>>>>>>>>>>>> Often, fixes are obvious and committers self-assign >>>>>> w/o >>>>>>>>>>>> discussion. >>>>>>>>>>>>>>>>> *Resolve / Close:* >>>>>>>>>>>>>>>>> You can either Resolve or Close a ticket once it is >>>>>> done >>>>>>>>>> (fixed, >>>>>>>>>>>>>>> rejected, >>>>>>>>>>>>>>>>> invalid, ...). >>>>>>>>>>>>>>>>> As a rule, we Close tickets instead of Resolving them >>>>>>> when >>>>>>>>>> they >>>>>>>>>>>> are >>>>>>>>>>>>>>> done. >>>>>>>>>>>>>>>>> Background: There are semantic differences for Resolve >>>>>>> and >>>>>>>>>> Close >>>>>>>>>>>>>>>>> (implementor vs reporter considers it done), but I >>>>>> don't >>>>>>>> see >>>>>>>>>> how >>>>>>>>>>>>> they >>>>>>>>>>>>>>>>> practically apply to the Flink project. Looking at the >>>>>>>>>> numbers, >>>>>>>>>>>>> Flink >>>>>>>>>>>>>>> has >>>>>>>>>>>>>>>>> 11066 closed tickets, and 3372 resolved tickets >>>>>> (that's >>>>>>>> why >>>>>>>>> I >>>>>>>>>>>>> propose >>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>> close instead of resolve) >>>>>>>>>>>>>>>>> *Labels:* >>>>>>>>>>>>>>>>> "test-stability" for all test instabilities >>>>>>>>>>>>>>>>> "starter" for tickets suitable for new contributors >>>>>>>>>>>>>>>>> *Release Note:* >>>>>>>>>>>>>>>>> Small notes that will be included into the release >>>>>> notes >>>>>>>>>>> published >>>>>>>>>>>>>> with >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> release. >>>>>>>>>>>>>>>>> *All other fields are not used not used on a regular >>>>>>>> basis.* >>>>>>>>>>>>>>>>> Please +1 my proposal if you want it to be published >>>>>> in >>>>>>>> our >>>>>>>>>> Wiki >>>>>>>>>>>>> like >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>> or let me know if I got something wrong here. >>>>>>>>>>>>>>>>> Best, >>>>>>>>>>>>>>>>> Robert >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Best, Jingsong Lee >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>>> >>> >>
