db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Use of Jira "Fix In"
Date Mon, 30 Nov 2009 16:13:07 GMT
Thanks for raising this topic, Dag. I don't think we have a clear 
policy, as evidenced by the fact that we re-open some version of this 
conversation every couple months. Here's what we've got for our branches 
today:


Branch   LastOfficialRelease   VersionOnBranch    HighestJiraVersion

10.1     10.1.3.1              10.1.3.3           10.1.4.0

10.2     10.2.2.0              10.2.2.1           10.2.3.0

10.3     10.3.3.0              10.3.3.1           10.3.4.0

10.4     10.4.2.0              10.4.2.1           10.4.3.0

10.5     10.5.3.0              10.5.3.1           10.5.4.0

trunk    n/a                   10.6.0.0           10.6.0.0

For all of the branches, we have a JIRA id for LastOfficialRelease, 
VersionOnBranch, and HighestJiraVersion. Given the community's current 
processes, I don't see a reason for JIRA to maintain both 
VersionOnBranch and HighestJiraVersion. What we do now is record the 
fact that a bug has been fixed at the head of the branch 
(VersionOnBranch). The release manager bulk-updates the fixed-in-version 
when producing a real release candidate.

I would support eliminating all of the HighestJiraVersion tags and 
merging those issues down to the corresponding VersionOnBranch.

My $0.02,
-Rick


Knut Anders Hatlen wrote:
> Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:
>
>   
>> Kristian Waagan <Kristian.Waagan@Sun.COM> writes:
>>
>>     
>>> I believe we are supposed to set the fix version to the version shown
>>> by sysinfo. On the 10.5 branch it currently shows 10.5.3.1.
>>> Further I thought that when / if we decide to produce a 10.5.4.X, Jira
>>> is used to bulk update all issues with fix version set to 10.5.3.1
>>> such that they will have 10.5.4.0 set instead. Finally, wouldn't we
>>> remove 10.5.3.1 from the list of versions in Jira, by merging it with
>>> 10.5.4.0?
>>>       
>
> I think the above is actually a single step: Merge 10.5.3.1 into
> 10.5.4.0. This will make all the issues marked as fixed in 10.5.3.1 show
> up as fixed in 10.5.4.0, and no bulk update is needed up front.
>
>   
>> This makes sense, really. But then, why have we added 10.5.4.0 to JIRA
>> already? 
>>     
>
> To have the possibility to flag that an issue is intended to be fixed in
> the next update release. But since the current policy is to set the
> fixed-in only after the issue has actually been fixed, I don't think
> having that version tag available adds much value, and I'm +1 to
> removing it in order to keep the list of version tags shorter and less
> confusing.
>
>   
>> Several of us have marked issue for fix in 10.5.4.0 already; should we
>> go over those and clear that field, do you think? (as well as making
>> sure 10.5.3.1 is set - and similarly for older branches..)
>>     
>
> It would make the bug database more consistent, so feel free... :)
>
>   
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&fixfor=12314154&sorter/field=issuekey&sorter/order=DESC
>>     
>
> In this list, at least three issues (DERBY-4081, DERBY-4092, DERBY-4213)
> were originally marked as fixed in 10.5.3.1 (this can be seen by picking
> the "All" tab). For some reason, the fix version says 10.5.4.0. All of
> these issues were fixed after the 10.5.3.0 release was produced and
> before it was actually released, so I'd guess something went wrong in
> the process of merging version tags into 10.5.3.0.
>
>   


Mime
View raw message