+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
