+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
