Clarification needed bout filing JIRA issues - Fix vs Affects Versions

[Laura Stewart <sc...@gmail.com>]

When you create a new JIRA issue, you must specify information about
the "Affects Versions" and "Fix Versions".  I looked at all of the
Derby information about filing new issues but am still confused about
what to specify for the "Affects Versions" and "Fix Versions" fields.

In the documentation provided on the Derby site (Community tab, BUGS section)
http://db.apache.org/derby/DerbyBugGuidelines.html
there is a link to a PDF document "ApacheDerby Issues in Jira".

In that document, it describes the "Affects Version/s is the version/s
that was being used when it was detected."    That is fairly clear.
If I am working on version 10.2.1.6, then I select that version in the
"Affects versions" field when I create the JIRA issue.

However there is nothing to indicate what to select (if anything) for
the "Fix Versions" field.  And I have see many different approaches.
When someone creates a new issue, should they:

1) Leave the Fix Versions field blank?  Then when the patch is ready
to be committed, then someone (the originator of the issue, or the
committer?) can specify which versions to apply the fix to.

2) Specify the version that the originator would like to see the issue
fixed in?  For example if it is an urgent issue, specify the next
minor release. For example if the current release is 10.2.1.6,specify
the next release is 10.2.2.  If the issue in not urgent, then specify
the next major release.  For example if the current release is
10.1.2.6, specify 10.3.

3) Specify all of the previous and future releases that the issue
should be fixed in?  Is there any point to specifying previous
releases?  Is there any point in specify more than one future release?
 Won't issues resolved in 10.2.2 be picked up in 10.3?

Please clarify what the appropriate action is.

-- 
Laura Stewart

Re: Re: Clarification needed bout filing JIRA issues - Fix vs Affects Versions

[Andrew McIntyre <mc...@gmail.com>]

On 10/30/06, Mike Matrigali <mi...@sbcglobal.net> wrote:
>
> I think it is best to leave fix in version blank.  For the last release
> rick and kathy were using fix in to indicate what release it "would be
> nice" to get a particular fix in.  I think this use becomes very
> confusing, especially once a patch goes in.  Does it now mean that the
> fix is actually in that version or not?  Even more confusing if there
> are multiple fix in set.  I do think it is nice to generate reports with
> candidate bugs for a special release, but I don't have an alternate
> suggestion.  We are definitely overloading a field here, it would be
> nice if there were an "actually fixed in field" and a "target fix in
> field".

I think that if a bug is Resolved, then its Fix In should reflect the
versions where code changes were made that resulted in the issue being
fixed. If the bug is Open/Reopened then I take the Fix In field to
mean that is the target release(s) for which the issue should be
fixed.

A problem arises when the issue has been fixed in one release (e.g.
whatever the trunk version is currently) but it remains open because
the fix should be ported to another release (some close-to-release
branch). It can be hard to tell in that case what is really going on
in that case, but I've been relying on scanning the Subversion changes
view in JIRA to determine if the fix has been applied to all the
versions in the Fix In list if there are multiple versions there.

my 2 cents,
andrew

Re: Clarification needed bout filing JIRA issues - Fix vs Affects Versions

[Mike Matrigali <mi...@sbcglobal.net>]

Laura Stewart wrote:
> When you create a new JIRA issue, you must specify information about
> the "Affects Versions" and "Fix Versions".  I looked at all of the
> Derby information about filing new issues but am still confused about
> what to specify for the "Affects Versions" and "Fix Versions" fields.
> 
> In the documentation provided on the Derby site (Community tab, BUGS 
> section)
> http://db.apache.org/derby/DerbyBugGuidelines.html
> there is a link to a PDF document "ApacheDerby Issues in Jira".
> 
> In that document, it describes the "Affects Version/s is the version/s
> that was being used when it was detected."    That is fairly clear.
> If I am working on version 10.2.1.6, then I select that version in the
> "Affects versions" field when I create the JIRA issue.
> 
> However there is nothing to indicate what to select (if anything) for
> the "Fix Versions" field.  And I have see many different approaches.
> When someone creates a new issue, should they:
> 
> 1) Leave the Fix Versions field blank?  Then when the patch is ready
> to be committed, then someone (the originator of the issue, or the
> committer?) can specify which versions to apply the fix to.

I think it is best to leave fix in version blank.  For the last release
rick and kathy were using fix in to indicate what release it "would be 
nice" to get a particular fix in.  I think this use becomes very 
confusing, especially once a patch goes in.  Does it now mean that the
fix is actually in that version or not?  Even more confusing if there
are multiple fix in set.  I do think it is nice to generate reports with
candidate bugs for a special release, but I don't have an alternate
suggestion.  We are definitely overloading a field here, it would be 
nice if there were an "actually fixed in field" and a "target fix in
field".

Any power jira users out there who could suggest an alternate way of
generating a report on a set of JIRA bugs?
> 
> 2) Specify the version that the originator would like to see the issue
> fixed in?  For example if it is an urgent issue, specify the next
> minor release. For example if the current release is 10.2.1.6,specify
> the next release is 10.2.2.  If the issue in not urgent, then specify
> the next major release.  For example if the current release is
> 10.1.2.6, specify 10.3.
> 
> 3) Specify all of the previous and future releases that the issue
> should be fixed in?  Is there any point to specifying previous
> releases?  Is there any point in specify more than one future release?
> Won't issues resolved in 10.2.2 be picked up in 10.3?
> 
> Please clarify what the appropriate action is.
>