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

Reply via email to