Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <454643C8.50401@sbcglobal.net>
Date: Mon, 30 Oct 2006 10:26:16 -0800
From: Mike Matrigali <mikem_app@sbcglobal.net>
Reply-To: mikem_app@sbcglobal.net
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Clarification needed bout filing JIRA issues - Fix vs Affects
 Versions
References: <9f40b500610301007h6d2f2898s9479433530d2ef76@mail.gmail.com>
In-Reply-To: <9f40b500610301007h6d2f2898s9479433530d2ef76@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


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