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