Cytoscape Wiki|
← Revision 1 as of 2015-01-16 00:27:23
Size: 959
Comment:
|
← Revision 2 as of 2015-01-16 02:33:37 →
Size: 2056
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
|
This article describes developer activities and how they are tracked through Redmine. The Redmine state is represented as STATE, which can take on the following values: {NEW, TRIAGED, ACCEPTED, IN PROGRESS, IN REVIEW, REVIEWED, CLOSED, FEEDBACK, RESOLVED, REJECTED}. A typical state sequencing would be NEW -> TRIAGED -> ACCEPTED -> IN PROGRESS -> IN REVIEW -> REVIEWED -> CLOSED as described below: |
|
| Line 4: | Line 10: |
| * STATE <= NEW | |
| Line 6: | Line 13: |
|
* assigned target release 1. Assigned developer fully assess work and manages estimates for: |
* possibly assigned target release * STATE <= TRIAGED 1. Bug gets preliminary review by some group member * if it is judged eligible for fixing: * reviewer sets target release * reviewer verifies or changes lead developer * reviewer assigns provisional risk profile and testing requirements * STATE <= ACCEPTED 1. When STATE == ACCEPTED, assigned developer fully assess work and manages estimates for: |
| Line 11: | Line 25: |
| 1. Assigned developer implements fix |
* STATE <= IN PROGRESS 1. Assigned developer implements fix |
| Line 13: | Line 28: |
| 1. Assigned developer reassigns issue to a reviewer and marks it as “Review” |
1. Assigned developer reassigns issue to a reviewer * STATE <= IN REVIEW |
| Line 15: | Line 31: |
|
* if good: then mark as “Closed" * if more work needed: then mark as “Open”. Repeat fix and review steps |
* if good: STATE <= REVIEWED * if more work needed: STATE <= ACCEPTED and return to developer 1. Assigned developer sets STATE <= CLOSED |
| Line 27: | Line 44: |
|
== Other Redmine States == FEEDBACK = waiting for user reply ... could follow TRIAGED or ACCEPTED, and could precede ACCEPTED, CLOSED, or REJECTED RESOLVED = unknown function REJECTED = closed and not fixed |
Bug Review Process
This article describes developer activities and how they are tracked through Redmine.
The Redmine state is represented as STATE, which can take on the following values: {NEW, TRIAGED, ACCEPTED, IN PROGRESS, IN REVIEW, REVIEWED, CLOSED, FEEDBACK, RESOLVED, REJECTED}.
A typical state sequencing would be NEW -> TRIAGED -> ACCEPTED -> IN PROGRESS -> IN REVIEW -> REVIEWED -> CLOSED as described below:
- Bug is reported (by core dev or external user)
STATE <= NEW
- Bug is triaged (during weekly meeting, if not earlier)
- assigned lead developer
- possibly assigned target release
STATE <= TRIAGED
- Bug gets preliminary review by some group member
- if it is judged eligible for fixing:
- reviewer sets target release
- reviewer verifies or changes lead developer
- reviewer assigns provisional risk profile and testing requirements
STATE <= ACCEPTED
- if it is judged eligible for fixing:
- When STATE == ACCEPTED, assigned developer fully assess work and manages estimates for:
- timing and difficulty
- target release
- risk profile and testing requirements
STATE <= IN PROGRESS
- Assigned developer implements fix
- code is checked in to current hot fix branch
- Assigned developer reassigns issue to a reviewer
STATE <= IN REVIEW
- Reviewer checks code and reassigns to original developer
if good: STATE <= REVIEWED
if more work needed: STATE <= ACCEPTED and return to developer
Assigned developer sets STATE <= CLOSED
- As part of release planning:
- coordinate testing
- cherry pick code into trunk
Cherry picking
git checkout FIX-BRANCH git cherry-pick -x DEV-COMMIT-HASH-CODE
Other Redmine States
FEEDBACK = waiting for user reply ... could follow TRIAGED or ACCEPTED, and could precede ACCEPTED, CLOSED, or REJECTED
RESOLVED = unknown function
REJECTED = closed and not fixed