flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maximilian Michels <...@apache.org>
Subject Re: Marking affected and fixed versions in JIRA
Date Fri, 27 Mar 2015 13:52:39 GMT
Hmm. In my eyes, "Closed" is for one-time issues that are not likely to
occur again. "Resolved" is to mark the issue as resolved with possible
issues coming up in the course of usage or testing. I would say, "Closed"
is more from an end-user perspective, whereas "Resolved" marks the
developer's result of fixing the issue.

On Fri, Mar 27, 2015 at 2:41 PM, Robert Metzger <rmetzger@apache.org> wrote:

> @Vasia: I don't know. I use "Closed" for issues which are invalid or won't
> fix.
> Resolved for those that were implemented.
>
> On Wed, Mar 18, 2015 at 2:57 PM, Vasiliki Kalavri <
> vasilikikalavri@gmail.com
> > wrote:
>
> > Thanks for this Robert! I updated the gelly-related closed issues.
> > BTW, what's the difference between closed and resolved? Any case where we
> > should use one over the other?
> >
> > -Vasia.
> >
> > On 18 March 2015 at 10:34, Robert Metzger <rmetzger@apache.org> wrote:
> >
> > > I would appreciate if everyone who is merging pull requests is properly
> > > setting the "fix version" in JIRA.
> > >
> > > So in most cases, the "fix version" is the next major release,
> currently
> > > 0.9.
> > > If we're not setting this, the issue will not appear in the changelog
> of
> > > the release. Also, I think that users may find JIRAs via Google, then
> > this
> > > information helps them to know when the feature will be available.
> > > Also, the fancy marketing metric (XY issues resolved) is suffering ;)
> > >
> > >
> > > By the way, does anybody know why we can not set the "fix version" for
> > > "Closed" JIRAs (instead of "Resolved")? In the "Resolved" case, we can
> > > still change that.
> > >
> > >
> > > On Thu, Oct 9, 2014 at 9:46 AM, Fabian Hueske <fhueske@apache.org>
> > wrote:
> > >
> > > > Yes, I think more discipline with JIRA issues would be definitely
> good
> > > and
> > > > ease the management of releases.
> > > >
> > > > I'd say the affected version should be initially the version (or
> > > versions)
> > > > where the issue was identified.
> > > > We than should check which other versions are affected and add these
> to
> > > the
> > > > JIRA.
> > > > Only the latest minor of each major release is relevant, e.g., 0.6.1
> is
> > > > sufficient for all 0.6 releases.
> > > >
> > > >
> > > > 2014-10-08 21:50 GMT+02:00 Ufuk Celebi <uce@apache.org>:
> > > >
> > > > > Hey all,
> > > > >
> > > > > I was wondering what the policy is for marking issues with affected
> > and
> > > > > fix versions. I know that we suggested a couple of times (in
> > different
> > > > > email threads) that it would be desirable in order to get an
> > automatic
> > > > > changelog for releases etc.
> > > > >
> > > > > I think the fixed versions tag is clear: you mark the version for
> > which
> > > > it
> > > > > was fixed.
> > > > >
> > > > > Example: if I fix something in the current master (assuming current
> > > > master
> > > > > has not been branched off for 0.7-incubating) and I do a back port
> > for
> > > > > 0.6.1: then I mark the fix for the unreleased 0.7-incubating
> version
> > > and
> > > > > add the new release tag 0.6.2, right?
> > > > >
> > > > > What about the affected versions tag? Just the latest unreleased
> > > version,
> > > > > which is affected? Or all versions, where it should be fixed
> > (released
> > > > and
> > > > > unreleased) as well?
> > > > >
> > > > > – Ufuk
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message