You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-commits@db.apache.org by Apache Wiki <wi...@apache.org> on 2006/08/25 00:03:31 UTC
[Db-derby Wiki] Update of "TenTwoRelease" by MikeMatrigali
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.
== 10.2 Documentation Issues ==
Re: Marking issues as "resolved" ( was Re: [Db-derby Wiki] Update of
"TenTwoRelease" by MikeMatrigali)
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Jean,
This seems fine to me. Thanks for keeping JIRA honest.
Regards,
-Rick
Jean T. Anderson wrote:
>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
>
>
>
Re: Marking issues as "resolved" ( was Re: [Db-derby Wiki] Update
of "TenTwoRelease" by MikeMatrigali)
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
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
Marking issues as "resolved" ( was Re: [Db-derby Wiki] Update of
"TenTwoRelease" by MikeMatrigali)
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
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?
happy to oblige ....
-jean