Cytoscape Wiki|
Size: 2411
Comment:
|
← Revision 7 as of 2017-09-26 17:17:24
Size: 2806
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 13: | Line 13: |
| * possibly assigned target release | |
| Line 15: | Line 14: |
| * (NOT assigned a target release ... that happens only when STATE <= ACCEPTED) | |
| Line 17: | Line 17: |
| * reviewer sets target release | * reviewer sets target release (as next release, not a future release) |
| Line 30: | Line 30: |
| * set "assignee" field to reviewer (Note: the "reviewer" field doesn't notify the reviewer via e-mail, so we don't use it) | |
| Line 35: | Line 36: |
| * set "assignee" field to original developer | |
| Line 38: | Line 40: |
|
*** Note that a target version should be assigned iff STATE == ACCEPTED or beyond. Otherwise STATE should be TRIAGED. *** |
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
STATE <= TRIAGED
(NOT assigned a target release ... that happens only when STATE <= ACCEPTED)
- Bug gets preliminary review by some group member
- if it is judged eligible for fixing:
- reviewer sets target release (as next release, not a future 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 development branch
- Assigned developer reassigns issue to a reviewer
STATE <= IN REVIEW
- set "assignee" field to reviewer (Note: the "reviewer" field doesn't notify the reviewer via e-mail, so we don't use it)
- Reviewer checks code and reassigns to original developer
- check code out from development branch
- for features, use Quality Circles document to verify code meets requirements and fulfills quality aspects ... document findings in Quality Circles table
if good: STATE <= REVIEWED ... if the change is for the current release, developer cherry picks it into the current hotfix branch
if more work needed: STATE <= ACCEPTED and return to developer ... developer and reviewer can agree to withdraw checkin from development branch
- set "assignee" field to original developer
Assigned developer sets STATE <= CLOSED
- As part of release planning:
- coordinate testing
*** Note that a target version should be assigned iff STATE == ACCEPTED or beyond. Otherwise STATE should be TRIAGED. ***
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