Thanks for bringing up this discussion, Robert. +1 to the proposal, it's very clear.
> 在 2020年5月22日，下午7:50，Jark Wu <imj...@gmail.com> 写道： > > Thanks Robert for bringing up this. +1 to the proposal. > > From my perspective, I would like we can clearify one more thing about "fix > version/s" in this wiki. > IIRC, if a fix is targeted to be fixed in "1.11.0", then it obviously is > fixed in "1.12.0", so such a bug fix should only set "1.11.0", not both > "1.11.0, 1.12.0". > This rule doesn't apply to 1.11.x where x >= 1. This problem happens > frequently during release and such information is quite hidden. > > Best, > Jark > > On Fri, 22 May 2020 at 17:12, Yuan Mei <yuanmei.w...@gmail.com> wrote: > >> +1 >> Thanks Robert for these detailed explanations! >> It is definitely useful to have a clear standard to avoid confusion when >> creating Jira, especially for starters. >> >> Thanks for the efforts! >> >> Best, >> Yuan >> >> >> On Fri, May 22, 2020 at 2:07 PM Robert Metzger <rmetz...@apache.org> >> 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 >>> >>
