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