db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean T. Anderson" <...@bristowhill.com>
Subject Re: Marking issues as "resolved" ( was Re: [Db-derby Wiki] Update of "TenTwoRelease" by MikeMatrigali)
Date Thu, 24 Aug 2006 22:33:51 GMT
Jean T. Anderson wrote:
> Apache Wiki wrote:
> 
>>Dear Wiki user,
>>
>>You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change
notification.
>>
>>The following page has been changed by MikeMatrigali:
>>http://wiki.apache.org/db-derby/TenTwoRelease
>>
>>------------------------------------------------------------------------------
>>  The following work flow can help ensure fixes get committed efficiently.
>>   1. Pick a bug you want to fix and fix it in the trunk.
>>   1. Submit your patch for the trunk.
>>-  1. Mark the issue resolved only after the fix is in the trunk. The fixin fields
should be marked as 10.2.1.0.
>>+  1. Mark the issue resolved only after the fix is in the trunk, and has been merged
into the 10.2 branch. The fixin fields should be marked as 10.3 and 10.2.1.
> 
> 
> on the docs I've been marking issues "resolved" after the last patch for
> the issue has been committed to the trunk, then marking the issue as
> closed when merged to 10.2.
> 
> Also, I've been noting the fix version as 10.3 then updating the fix
> version to include 10.2 when merged.
> 
> bad idea? Should I change what I'm doing for docs?
> 

thinking about this, here's what I'm actually doing:

1) After last patch for issue committed
   + uncheck patch available flag
   + set fixed version to 10.3
   + mark issue as resolved

2) After merge to 10.2 trunk
   + add 10.2 to fixed version
   + close issue (actually I haven't been closing, have let the owner or
doc writer close)

As I mentioned before, I'm happy to modify what I'm doing.

 -jean


Mime
View raw message