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