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