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