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